Wednesday June 27 2001

Practical Considerations In Implementing Web Services

Fighting vendor lock-in with Java standards

Romin Irani

Web Services are the new Holy Grail of programming. There has been lot of activity recently from different application server vendors who have announced widespread support for Web Services in their products. Those who have not yet announced support will surely do so in the near future.

This article attempts to take a look at existing issues in implementing Web Services into your application. We shall not go into the details of what Web Services are or how to go about writing them. Instead what we shall attempt to discover are the issues that could arise in implementing applications which incorporate Web Services. The article concentrates particularly on Java enterprise applications, but there are more broadly applicable lessons here.

In the context of this article, we are talking about Web Services as meaning software components that can be accessed from anywhere on the Internet. They are built on top of emerging standards like UDDI, WSDL and SOAP. In short, Web Services are published and located via the UDDI, they are described using WSDL and are invoked most probably via SOAP over HTTP.

Web Service Implementation/Integration Scenarios

Let us say that you have an existing enterprise application and have decided to implement Web Services in your application. Listed below are 3 scenarios that involve implementing/integrating Web Services:

• Expose existing functionality via a Web Service

  For your existing application, you need to determine what functionality you want to expose as a Web Service. The functionality that you want to expose to as Web Service could be for internal use by other applications within the enterprise or it could be exposed to the outside world by publishing it to public UDDI registries.

• Integrate Web Services from other vendors or business partners

  In several situations, it makes sense to buy a Web Service rather than build a component from scratch. In these situations you would need to integrate other Web Services to complete/enhance your application.

  As your application progresses, you may discover Web Services built and exposed by other vendors, which you could incorporate into your application. Alternatively you may have business partners who have exposed functionality as Web Services which your application can use.

• Implement new Web Services

  As time goes on, you may decide that new functionality would be best written explicitly to be exposed as a Web Service, as an explicit architectural strategy.

Current Approaches To Implementation/Integration Scenarios

We shall take a look at the scenarios described in the previous section and take a look at the mechanisms to achieve each of them within the context of some current Java enterprise vendor offerings.

• Expose existing functionality via a Web Service

  In the context of an existing J2EE (Java 2 Platform, Enterprise Edition) application, we first need to make a decision what functionality we want to expose as a Web Service. In the case of applications that are architected according to the J2EE blueprints and best practices, we should find this functionality implemented as Enterprise JavaBeans (EJB). In other situations, we might have Java Classes that are not necessarily EJB?s, but rather plain Java classes containing some functionality that we have identified as suitable for exposing as a Web Service.

  What we need in the above situations is for existing tools, which would enable us to generate wrappers around these existing Java objects. These tools would take as input the Java classes and generate WSDL wrappers describing this service. These tools would also need to provide support for translating the Web Service invocations (typically SOAP requests arriving over HTTP) into the appropriate Java method call on the bean.

  IBM provides the WSTK (Web Services Tool Kit) to help you jumpstart converting your existing Java classes and Enterprise JavaBeans into Web Services. CapeConnect Two from Cape Clear Software goes a step further by providing a whole Web Services platform. Other Application Server vendors like Silverstream Software and BEA have announced support in their current versions to do the same.

• Integrate Web Services from other vendors or business partners

  As we mentioned before, it makes perfect sense for an organization to buy and integrate a Web Service exposed by a vendor. Also, in collaborative commerce, an application needs to be integrated with other applications of business partners. The preferred approach is to lookup/locate the Web Service from a public (or semi-private) UDDI registry, and dissect the discovered WSDL document to interpret what operations the service supports along with the parameters for each operation. Once we have that information, we could use SOAP over HTTP to invoke the vendors Web Service or integrate with a business partners Web Service.

  To accomplish this, you can use something as direct as the Apache SOAP API to invoke the Web Service if its location and URN (Unique Resource Name) are known. The Cape Connect Two Platform from CapeConnect Software provides you with an abstracted SOAP API called SOAPDirect which makes it easier to do the same. IBM's Web Services Tool Kit also contains libraries for programmatically accessing and searching UDDI repositories, and their extended Web Services Development Environment provides a complete set of tools for developing code to access Web Services discovered via UDDI.

• Implement new Web Services

  You have plenty of choices here. You will first write your Java Classes and/or Enterprise Java Beans which will contain the Web Service functionality. And then you could use some of the approaches defined in the above sections to expose your Web Services.

Why This Isn't Enough

As you go through the above approaches, one thing that will strike you is that there are plenty of choices available to organizations who have made the decision to go the Web Services way. However, any serious enterprise application implementation requires much more than a simple Invoke Web Service/Get Web Service Response kind of approach. What about transactions, application context, business process workflow, etc.? Lets look at some of these issues now:

• Application Server versions

  Let us say that an organization has an existing J2EE Application with its fair share of Enterprise Java Beans. These Enterprise Java Beans hold most of the core functionality of the company's enterprise applications, and the company wants to expose some of this existing functionality via Web Services. Consider that the organization had used, say BEA Weblogic 5.1, as its platform. The Application Server vendor has only just announced support for Web Services in the next version of the Application Server, it's not possible for the organization to deploy its enterprise functionality on early access software or early betas, so the organization needs to find another solution. There are tools from vendors like Cape Connect which provided support for integrating EJBs present in another application server, but this would come at the expense of having application servers from two different vendors present in the same application. This increased connectivity, not to mention administrative overhead, could lead to support issues in the future.

  This is not to say there is a problem in any specific vendors product/approach to Web Services. Instead we want to just highlight the decisions that any organization might have to make.

• Programming Model

  How does one go about implementing Web Services? By implementation here, we mean the actual code that we write to create Web Services. Is there any standard Web Service programming model available out there? How do we approach programming Web Services? Is there a Web Services programming specification like the EJB specification so that I can deploy my Web Services easily into other Application Servers just like I do with the EJB?s?

  The answer to the above questions is currently no. Every vendor provides their own scheme of things in implementing Web Services and currently it is very difficult to select any vendors implementation framework for Web Services and expect that everything will be fine, if I switch to another vendor. The lock-in which J2EE promised we could escape has returned, for the time being.

• Workflow, Transaction Contexts

  It is evident that the current Web Services that are available for integration into applications are services like credit card validation, user authentication services, etc. These kinds of Web Service are important to several applications but we all know that any true enterprise application needs much more than simple synchronous Web Services. We definitely need a Workflow Language that ties all different Web Services together to build a solid application. We also need a way to propagate transaction contexts through different Web Services.

Current implementations from vendors address all the above issues in different ways.

From the above points, it is clear that we are lacking a programming model and architecture for Web Services. Just as the EJB programming model has defined a distributed component model and has given companies choice of switching between Application Servers, we need a similar programming model for Web Services.

One interesting development is that there is a Java Specification request, JSR-109 (Implementing Enterprise Web Services) which intends to define a programming model and architecture for implementing Web Services in Java. This JSR will attempt to define a programming model on similar lines to the Servlet and EJB programming models. It will attempt to create equivalents of sessions contexts, transactions and provide a common API to implementing Web Services, with predictable lifecycles and multi-threaded behavior. The good part about this JSR is that it leverages other existing JSRs like JAXP, JAXM, JAX-RPC, and JAXR, which comprise the Web Services Pack soon to be released from Sun.

This will aid developers and implementers of Web Services to a great extent because not only will it provide a clear programming model for Web Services and it is hoped that this recommendation will be implemented by all the Application Server vendors.

Conclusion

This article has attempted to identify practical implementation issues that arise while defining the Web Services strategy for your enterprise application. It also stresses a need for a common programming model for Web Services in the J2EE realm. It is hoped that this common programming model would help fuel Web Services development in Java the same way as it did for Servlets and EJB. Web Services are definitely here to stay and they will help create completely unique solutions due to the fact that one can use other Web Services and provide a completely new value-added application. A common programming model will go a long way towards making it a reality.

Also by Romin on Web Services Architect: Part I - An Introduction to ebXML and Part II - ebXML and Web Services.

Romin Irani is a Senior Software Engineer at InSync Information Systems, Inc in Fremont, California. He is also the co-author of Professional Java Web Services from Wrox Press.