Getting Started on Developing Web Services
August 17, 2001

by Carla King

The concept of Web services is the latest in the evolution of ever more modular and distributed computing. The industry as a whole has embraced it as the next big thing despite its technical immaturity. What does this mean to developers? It means that, without risk of investing in a technology that might lose steam and disappear, you can become an early adopter, hone your skills, and contribute to its evolution. This article addresses the topic in the following segments:

• What Are Web Services?
• Web Services Standards
• Implementing Web Services
• What You Need to Know About Today's Web Services Paradigm
• Are You Ready to Develop Web Services?
• Development Tips
• Conclusion

What Are Web Services?

Web services constitute a distributed computer architecture made up of many different computers trying to communicate over the network to form one system. They consist of a set of standards that allow developers to implement distributed applications -- using radically different tools provided by many different vendors -- to create applications that use a combination of software modules called from systems in disparate departments or from other companies.

It must be noted that Sun -- unlike Microsoft, which is starting a whole new application paradigm called .NET -- is promoting the Sun Open Net Environment (Sun ONE), an open framework that supports "smart" Web services, and in which the Java 2 Platform, Enterprise Edition (J2EE) platform plays a fundamental role. This means that in the world of Sun developers, Web services will be built using servlets, JSP pages, EJB architecture, and all the other standards that are entwined with J2EE technology.

Web Services Standards

Web services are registered and announced using the following services and protocols. Many of these and other standards are being worked out now by the UDDI project, a group of industry leaders that is spearheading the early creation and design efforts.

• UDDI (Universal Description, Discovery, and Integration) is a protocol for describing available Web services components. This standard allows businesses to register with an Internet directory that will help them advertise their services, so companies can find one another and conduct transactions over the Web. The online yellow pages directory that UDDI provides is a key part of how Web services plans such as Sun ONE and Microsoft .NET will work together. This registration and lookup task is done using XML and HTTP(S)-based mechanisms. The UDDI project is working to provide a common access method for the metadata needed to determine if a piece of previously developed code will suffice and, if so, how to access it.
  
  
• SOAP (Simple Object Access Protocol) is a protocol for initiating conversations with a UDDI service. SOAP makes object access simple by allowing applications to invoke object methods, or functions, residing on remote servers. A SOAP application creates a request block in XML, supplying the data needed by the remote method as well as the location of the remote object itself.
  
  
• WSDL (Web Service Description Language), the proposed standard for how a Web service is described, is an XML-based service IDL (Interface Definition Language) that defines the service interface and its implementation characteristics. WSDL is referenced by UDDI entries and describes the SOAP messages that define a particular Web service.
  
  
• ebXML (e-business XML) defines core components, business processes, registry and repository, messaging services, trading partner agreements, and security.

Implementing Web Services

Before proceeding with development issues, here's a brief step-by-step on how a Web service is implemented, with links to Dot-Com Builder's technical overviews. The figure below provides a diagram of a simple Web services implementation.

Figure 1: Model for Web services implementation (Click image to enlarge.)

1. A service provider creates a Web service. (Development tips are provided later in this article.)
   
   
2. The service provider uses WSDL to describe the service (to a UDDI registry).
   
   
3. The service provider registers the service (in a UDDI registry and/or ebXML registry/repository).
   
   
4. Another service or user locates and requests the registered service by querying UDDI and/or ebXML registry(ies).
   
   
5. The requesting service or user writes an application to bind the registered service using SOAP (in the case of UDDI) and/or ebXML.
   
   
6. Data and messages are exchanged as XML over HTTP.

What You Need to Know About Today's Web Services Paradigm

If you're going to develop Web services now, you'll find yourself creating applications before the Web services infrastructure and protocols have been set. So ignore the marketing hype, and don't set your expectations too high. Here's a reality check on the state of today's Web services paradigm (or rather, non-paradigm).

The technology hasn't yet caught up to the business vision. Most software is less than six months old, and a lot of it isn't going to work as well or as solidly as your existing distributed systems software.

Even though Web services are built on existing infrastructure, a lot of the infrastructure needed to perform wide-area collaboration hasn't even been built yet.

This is the first time a set of independent organizations is evolving a technology space in parallel. The core architectural foundation of Web services -- XML, XML name spaces, and XML schema -- enables the distributed evolution of the Web services specifications.

Web services are a supply-side phenomenon where the vendors, not the customers, are pushing the technology and setting standards. UDDI, SOAP, WSDL, and security standards are being developed in parallel by different vendors, and it will be some time before they will be able to converge and agree on a final set of standards. In the meantime, you'll need to use your programming and network knowledge, along with today's barely developed tools and your own creativity, to find your own solutions.

Specifications are not complete. Because of the lack of a solid set of standards, implementation details are left for individuals (that's you, or someone who may have made design decisions with which you may not agree) to make up as they go along.

Are You Ready to Develop Web Services?

Here's a list of skills that will make it easier for you to start designing Web services right now:

• Master the skill of non-attachment. Since many of the elements you'll need to develop Web services will be completely out of your control, you'll get plenty of practice.
  
  
• Apply your knowledge of large-scale enterprise system deployment. There are many complex nuances in enterprise systems that are not exclusive to the domain of Web services, such as high availability, high throughput, clustering, hardware management, and network topology. If you've deployed a large-scale enterprise system, you are probably as prepared as you're going to be to develop Web services.
  
  
• Use your knowledge of other kinds of distributed systems. The toolsets you'll use will be different, but if you have CORBA and EJB architecture training, you'll be able to transfer your existing design knowledge to Web services development.
  
  
• Draw upon your knowledge of servlets, JSP pages, EJB architecture, and other J2EE technologies. These skills will be extremely useful in Web services development.
  
  
• Learn XML programming skills. The simple fact is that XML is ubiquitous in Web services architecture because it is open, vendor-supported, and standardized. You can expose assets and services using WSDL and proxy-generation tools, which shield you from the underlying messages carried by XML packets in Web services. However, depending on how deeply you go into Web services, low-level XML programming skills may be important. Many tools aren't yet fully capable of shielding you from the details. So if you're developing complex systems, you may need to write programs that interact with the low-level XML.
  
  
• Study XML standards. Web services tools will eventually make XML transparent, but for now, it's essential that you become comfortable with XML standards based on SOAP, WSDL, UDDI, or ebXML.
  
  
• Learn the tools your organization has chosen for Web services development. Some of the tools available now are the Forte for Java IDE, Oracle JDeveloper, and WebGain Studio. The future will bring tool suites such as the J2EE Web Services Pack that will incorporate JavaServer Faces, a standard API for creating GUIs; Tomcat, for implementing JSP pages and servlet technologies; and the JAX Pack, a collection of XML-based Java APIs for XML processing registries, messaging, binding, and remote procedure calls (RPC).
  
  

Development Tips

Here's what you'll need to consider once you begin designing Web services:

• Requesting a service: Web services have all the same issues as those of distributed systems. If you've never developed distributed computing systems, you need to be aware that the service you've requested from a machine over the network may be a very heavyweight operation, even if it's represented by a single line of code. Keep in mind that a local operation is much cheaper than a distributed operation.
  
  
• Control issues: As a developer, you may think of an application as something to build and control -- and if it doesn't work, you can grab and modify it. However, with Web services you will be tapping into software modules that are not under your control. Most of the time, the data or service you request will be sent to you and everything will work fine. But you'll need to plan for the time when it doesn't work -- maybe the administrator for the system you're calling (that worked just fine for months) updated the system to a new version that doesn't work with your application. So make sure to program in a "Plan B."
  
  
• RPC-style architectures: If you've developed in CORBA, you're used to making a call to a subroutine and expecting a timely return. In Web services, you'll make the call, but don't expect to get an instant response. Web services support both asynchronous and synchronous RPC-style architectures as well as messaging, so that you can create a loosely coupled, asynchronous architecture that allows functions to continue without network response... up to a point. You won't be able to count on the reliability of many of the services you call because they aren't under your control. So you'll need to provide backup plans for important processes. This is another good opportunity to practice the skill of non-attachment.
  
  

Conclusion

Web services are here to stay, and the good news is that you can transfer a lot of your existing J2EE technology skills and knowledge of distributed systems to make the shift. There are plenty of challenging and creative opportunities as only a few development tools are available at this time. So you'll be working at the nuts and bolts level, as well as making independent decisions because few standards are solidly in place at this time. However, you can look forward to participating in the evolution of these standards and using tools with better integration and reliability as the industry grows.

Acknowledgments

Many thanks to James Kao, senior technology partner of The Middleware Company, and Rich Scheffer, director of marketing for Forte Tools. Kao developed the current course in Web services for The Middleware Company. Scheffer joined Sun as part of the company's 1999 acquisition of Forte.

Resources

Web Services and Java Technology
http://java.sun.com/j2ee/webservices/

JAX Pack:
http://java.sun.com/xml/jaxpack.html

Using Forte for Java to Develop and Deploy Web Services:
http://developer.java.sun.com/developer/technicalArticles/WebServices/Forte4Java/

Forte for Java Web Site:
http://www.sun.com/forte/ffj/