Hands-On: 7 Keys To Building a Better Web Service
For developers looking to unlock the secrets to a successful web services project, Kirby Turner, a Solution Developer with developer services and integration firm Avanade Inc. offers a keen insight: A web service, he says, is "simply a programmable application logic accessed by using standard Internet protocols." Turner uses this core idea as a basis for his "7 keys to building successful web services." In these tips, Turner touches on many questions, ranging from using registries, setting security, and even the vexing debate over how much XML hand-coding does a developer really need to know.
Web services, as their standards and tools mature, are becoming an increasing popular model for building quick and cost-effective distributed applications. But for developers, this can be a boon to their effectiveness -- and careers. This is because web services hide a very appealing underlying simplicity -- for the CEO, the IT manager and even the developer stuck at the lower rungs.
This article presents 7 keys that will help just about any professional enterprise developer unlock the secret to how they can best upgrade their skills to embrace the new possibilities (and lurking hazards) of building a web service.
(We've even included 4 things your boss/CEO should know about web services. These are meant to help you make sure you get assigned a project that really is "do-able" with today's tools.)
To capture the power of web services (and protect themselves from some of the risks inherent in any new technology), developers should keep in mind that what the industry calls a "web service" is simply this: "A programmable application logic accessed by using standard Internet protocols." Java, ASP and developers familiar with Internet technologies such as HTTP have been doing some flavor of this type of programming for years now -- building to APIs, pages and common protocols.
If my fellow developers have trouble believing this, it's OK to be skeptical. In the next few minutes, I hope to show you just how simple the transition can be, and what "keys" you need to stay focused on to survive -- and thrive -- in a web services world.
With a web service, application logic is more easily exposed, and made accessible across independent, heterogeneous systems. And, with the right preparation, these legacy assets can be accessed from just about anyone from anywhere -- be it a business partner, a remote division of your enterprise, or the co-worker down the corridor.
The difference between web services and traditional development with Java, ASP, C, etc, is that developers now need to pay attention to how applications and transactions handle end-to-end trips through different nodes of the enterprise. What follows are the 7 keys to avoid stepping into the potential traps you can walk into.
Key #1 -- Know your audience
The first step before building a web service is to ask a simple question: Who will be using this web service? In other words: Will the web service being considered be used across departments within the company? By business partners? By the public (heaven forbid!)?
The answer will determine the level of interoperability needed with your web service.
Web services are thought of as a simple, interoperable web models for clients other than browsers. In practice, however, interoperability between web services has been difficult. Web services do not necessarily communicate in the same dialect. Some use a SOAP data model while others are based on XML Schema (XSD).
If your web service is going to be consumed within your organization only and your company has standardized on a single development environment, you need not concern yourself with this interoperability issue.
But, interoperability can become a real drag on a smooth and time-efficient rollout if your web service is to be made available to business partners or the public, or there is a mix of development environments within your organization. Standards for B2B web services authentication and authorization are still a ways off. But, there are options that can help.
Key #2 -- Explore "Private" UDDIs To Provide Interoperabilty
Numerous discussions on UDDI (Universal Description, Discovery and
Integration) are taking place throughout the industry. But, for today, many agree that a "yellow page" approach to searching public UDDI registry is simply not yet practical.
But, even though the "public UDDI registry" is a while off, there are "private UDDI registries" that are already proving valuable to companies. For example, a private UDDI registry is the basis of the Web Services Library in Accenture's new Web Services Platform (http://www.accenture.com/xd/xd.asp?it=enWeb&xd=servicessese_ws_platform.xml). [That example was built by Avanade.]
With a private UDDI, you have control over the entries stored in the registry. And with that confidence in the validity of the registry, using UDDI becomes more practical. Private UDDI provides a way for developers across the enterprise to discovery available web services. Internal applications as well as business partner applications can leverage private UDDI for discovery of web services at run-time. This dynamic discovery through UDDI will add to the reliability of the applications consuming your web service.
For example a Web service can be deployed in two locations, one serving as the primary site and the other as a secondary or fail-over site. Should the primary site become unavailable for any reason, an application using dynamic discovery could switch to the secondary site. From the end user's prospective, the application will continue to operate without interruption.
Key #3 -- Lock It Down: Security, Security
A top concern for developers is how to secure the web service. While there are many methods to secure your web service, the industry as a whole has yet to adopt a de-facto standard for securing web services. So this leaves developers with the question: "Should we go with a standards-based or proprietary approach for securing our web services?"
Here's how to gauge the situation:
With a proprietary solution, you typically would include authentication credentials as a parameter to the web service, or this information would be included in the SOAP message header. On the server side, you will validate the credentials and either allow the call or return an error. This has the benefit of being fairly trivial code to implement, but there are disadvantages. For one, all applications that use your web service will need to implement to your proprietary mechanism. Moreover, incorporating stronger authentication other than user/password can prove to be difficult.
When looking for a standards-based approach, there are a few options available. You can use HTTP security features provided by your web server such as basic or certificate-based authentication for stronger results.
The emerging WS-Security standard, with its multi-vendor support (proposed by IBM, Microsoft, Versign and now endorsed by Sun Microsystems and others), can be a good choice for those wanting a standards-based, transport-independent mechanism for securing the web service. However, be warned that the specifications for WS-Security is still in flux and implementation would involve a lot of work for your developers.
Key # 4 -- Consider Enlisting "Web Service Network Providers"
There is no need to go it alone, even if you're on a tight budget. In fact, getting outside help might save you time, money and headaches.
Even though many development teams may elect to begin building modest web services with 100% in-house talent, the smart and select use of "web services network providers" can help companies get the most from their in-house developers.
With standards shifting and some toolsets incomplete, web service networks can save time, money and headaches. They can provide tools that not only help secure your web service, transactional support, non-repudiation, guaranteed message delivery, centralized logging and monitoring, and more. Such providers use a combination of standards-base and proprietary techniques for providing a rich, robust execution environment for your web service.
Though a "web services network provider" can help jump-start your development effort, that speed-to-market may come at some cost, especially in terms of flexibility. For example, the use of a particular provider might require that your business partners utilize that same network to consume your web service. Proprietary plug-ins may be required on both end points to fully use the network. Be sure you do your homework prior to selecting a web services network provider.
Key #5 -- Get Intimate with Standards
The reliance by web services on standards such as SOAP, XML, and WSDL holds the promise of offering benefits over other distributed, component-based models such as COM and CORBA. However, for now, gaps in the web services model exist, especially around security and transactional integrity.
Industry leaders such as Microsoft and IBM have stepped up to the plate to help close these gaps, forming consortium groups such as WS-I. Standards such as WS-Security and WS-Routing have been proposed. For its part, Sun Microsystems offers alternative standards options, which may (or may not) be fully compatible with Microsoft and IBM initiatives.
Meanwhile, groups like OASIS, the W3C and IEFT (among others) are doing their best to provide a forum for vendors to pursue compatibility. But, as the game of standards development can be a moving target of both technology and politics, it pays to keep tabs on these groups and the related standards efforts. Such homework, while it may seem like useless homework, will help you save critical development time.
Over the next few years, we will see numerous advances in commercialized implementations of web services standards. This will come in the form of developer tools and server-based services. Being aware of these industry efforts will help you make the right decisions about your web services being implemented today.
Key #6 -- Eat and Breathe XML
While a growing number of development environments and IDEs do a good job of hiding the technologies that make web services work, developers wishing to exploit the power of web services will need to work with the underlining XML technologies. This might even require some hands-on work with the SOAP protocol and definition languages such as WSDL.
To get under the hood, developers will need a working knowledge of XML that goes beyond the popular auto-generator technologies. With this detailed XML knowledge, a developer can implement advanced features by manipulating incoming and outgoing SOAP messages and provide more meaningful and reusable WSDL documents. Understanding web services at the XML level will also aid in resolving interoperability issues that may crop up.
Key #7 -- Know Your Host; a Key SLA Partner
While web sites and web services rely on similar technologies such as HTTP as the network transport protocol. But deployment and hosting of a web service is more complex than deploying or hosting a typical website.
The demands and expectations of web services are higher than that of your average website; for example, a user is satisfied with web pages that take no more than 3 to 5 seconds to display within the browser. But an application using a web service will demand much faster response times.
As more applications depend on the web service, availability and reliability become much more important. As a result, Service Level Agreements (SLA) for hosting web services will typically have higher demands on the quality of service as compared to websites and web applications.
Also when deploying a new version of your web service, you must make sure you do not disable or change the interface for the previous version. Other applications may rely on the previous version and replacing an older web service with a newer version could potentially break those applications.
Over time several of these aspects of web services will become more transparent, and development and consumption of web services easier. But until such time, this basic set of items for consideration should help you get on your way to building useful and robust web services.
Tips for What To Tell Your Boss
Now that you know a bit more about how to survive a web services project, here is a shorter list of four (4) things your CEO should know about Web services:
1. Web services are not new. (The standards to build them are new). To those familiar with "eBusiness" trends of the last ten years, this observation may seem a bit obtuse. Nevertheless, it's surprisingly easy to get caught in the current web services hype and lose sight of the real developments.
2. Web services are not a substitute for a business model. Again, this may seem like a "no-brainer" to some, but the propensity for business leaders to embrace trends as business models did not die with the dot-coms. Web services are an enabler - a means to an end, but not the end in and of itself.
3. The most logical place to deploy web services now is behind the firewall. Some CEOs might "get it" too well when it comes to web services and want to use them for everything. Decelerate this thinking by offering to develop a realistic road map - models abound at analyst firms such as IDC, AMR, and Meta.
4. Web services are an alternative to "rip and replace" - don't advocate it. This one should go over well with the bottom-line minding CEO (and who doesn't have one of those these days.) Remind your CEO that you're not asking to start over; you're looking to connect and automate what you've already got using new standards.
Kirby Turner is a Solution Developer at Avanade Inc., a technology integrator focused on delivering solutions based on the Microsoft .NET enterprise platform. Over the years, he has been responsible for architecting and implementing distributed enterprise solutions for businesses ranging from start-ups to Fortune 50 companies.