A guiding principle in the software business is that everything designed and developed today will eventually become a legacy system to-morrow. Just yesterday I was all excited about the new world of client/server. For a time, it was client/server this and client/ server that, accompanied by a plethora of buzzwords to fill the minds and résumés of professionals. Almost overnight, however, Internet application architecture involving Web browsers, Java application servers, etc. took over the scene. Client/server is now a legacy technology.

With this idea in mind I have come to wrestle with a new thought: distributed components, J2EE architecture, and others will eventually be considered legacy systems as well.

As I was looking over the new Web service capabilities packaged in BEA's 6.1 release of its WebLogic server, I realized the playing field was shifting again, especially since the major vendors are beginning to seriously move ahead in support of Web services. BEA's approach to implementing SOAP-based Web services moves us even closer.

BEA announced the general availability of WebLogic 6.1 on August 1, 2001. BEA has made substantial progress in support of Remote Procedural Call (RPC) and message-based service requests using the Simple Object Access Protocol (SOAP) and Web Service Description Language (WSDL) 1.1 specifications. Since these specifications only define the messaging protocol, vendors are still free to be creative in how they implement the interfaces. The approach taken by BEA is innovative, yet, depending on the complexity of your XML data structures, it may have a few drawbacks.

Overview
WebLogic 6.1 classifies a Web service as either RPC-based or message-based, depending on whether the service transaction is synchronous and requires an immediate response or is asynchronous and doesn't require an immediate response. All SOAP functionality in WebLogic is based on implementing one or the other. Now equate this class of service to an EJB component.

RPC services are handled by a stateless session bean and message-based services are handled by a message-driven session bean. This is how BEA implements SOAP-based Web services in its WebLogic server.

Once you have the underlying EJB component designed, coded, and tested, all you need to do is set up an XML-based build descriptor file to get your service up and running. WebLogic will automatically generate the SOAP interface and compile the WSDL description for you based on the EJB design. BEA has also done a nice job of bringing SOAP services into the J2EE fold.

You may be asking yourself what happens if the "legacy" application I am wrapping in a SOAP service is not based on EJB technology? The answer to that is that you'll still need to develop an EJB session and/or message bean to serve as an adapter to the legacy application.

Getting Ready
Here are a few things to keep in mind before developing a Web service in WebLogic. The 6.1 version of WebLogic is fully compliant with the SOAP 1.1 standard (plus attachments) and the 1.1 version of the WSDL document, although, according to BEA, Web services currently ignore the actual attachment of a "SOAP with Attachments" message.

Moreover, you're not required to have extensive knowledge of SOAP and WSDL to develop a Web service. As I alluded to earlier, the WebLogic 6.1 Web service interface is tightly coupled to the remote interface of a matching EJB component. As a consequence, if your application is not EJB-based, you'll need to develop an EJB component wrapper for it.

WebLogic provides all the necessary build tools to transform and deploy your EJB interface into an ebXML/SOAP-based interface. You can assemble your own deployment jar if the standard build does not fully handle what you have designed. You'll find the process well documented, with plenty of details to guide you in rolling your own deployment .jar file.

The build process pretty much does all the work, configuring and integrating the various libraries to interpret the SOAP request and reply messages, and generating the appropriate WSDL document describing the service. Again, you must know your way around EJB components to deploy a SOAP service.

Creating a Service
To begin developing your service, you'll need to analyze the characteristics of the application to which you are binding your service. Is the service best implemented using an RPC type of interface, or should it be message-based? The documentation provides some useful questions to guide you in the right decision. Next, once you have an idea of the class of service you're developing, you need to develop the appropriate interfaces using session or message-driven EJB components. If the application is using EJB components on a WLS platform, you can build upon already existing stateless session beans.

In the case of a message-driven, asynchronous Web service interface, you'll need to develop a message-driven bean and set up the various JMS messaging queues on the server. Explaining how to develop both types of beans in WebLogic is beyond the scope of this review. WebLogic provides you with some wonderful EJB code examples and plenty of documentation - perfect for self-learning.

The next step in developing a Web service is to deploy the EJB components on the WebLogic application server. This is primarily a compile and deployment process that can be done manually or automatically by a build process.

Next you'll need to write an XML-based file called build.xml that defines the service name and other "Ant" specific directives. This file, along with the EJB component .jar file, serve as inputs to the "WSGEN" build process.

The output of the "WSGEN" build is an Enterprise Archive file (.ear file) and contains everything necessary to run a Web service. Deploying the Web service is as easy as placing the file in the appropriate WebLogic directory.

The "WSGEN" build process was built on top of Apache's Jakarta Project Ant (see Jakarta.apache.org/ant), a Java- and XML-based build utility. Ant is embedded in the WLS library, so it's not necessary to separately download the utility.

Developing a Client
The implementation goes further than helping you develop a service; it actually makes it easy to develop a client, too. There is support for Java clients and (surprise) Microsoft Visual Basic applications.

The WSDL is used by the logic resident in the client.jar file. This file contains everything necessary (and nothing more), enabling a client to access the service. The SOAP and WSDL interpretation, data binding, and so on are handled by the client.jar library, and for the most part it's transparent.

There are two approaches to designing a Java client: static and dynamic. The static approach requires the remote interface to be instantiated on the client while the dynamic approach uses a Web service proxy object to make the calls to the service. A dynamic client doesn't require the remote interface.

The client API calls are somewhat similar to remote EJB client calls but much more streamlined. For example, you still need to obtain an initial context to call a service, but instead of calling an EJB factory for it you'll be accessing it from a SOAP connection factory. Moreover, static calls to the service are made through a remote interface. This provides a simple but proprietary approach to performing SOAP service request calls. In a way, it makes the SOAP implementation transparent for both client and service. You are free, of course, to make a SOAP request any way you choose, as long as you follow the SOAP and WSDL specifications.

Pros and Cons
The WSDL and the client.jar files are available from the same Web application as the SOAP interface servlet. All a developer needs to do is download the WSDL and client.jar files from the service's Web site, design the client (the WSDL file is interpreted), and include the client.jar file in the CLASSPATH. The client.jar file is designed with a small footprint, therefore, supporting a thin client. WebLogic also provides the necessary .dll files for Visual Basic-based clients. The functionality for both Java and VB is the same: converting SOAP requests.

There are some limitations to WebLogic's approach in implementing a Web service. Complex XML data structures represented with XML schema can't easily be managed by the WLS 6.1 integration process. In other words, the binding between the SOAP interface and the legacy application is made strictly through an EJB interface, requiring complex structures to be represented through a one-dimensional Java bean structure. There are standards emerging in this area to help you navigate and bind the XML service parameters to the host application's interface points, but they are much more difficult to code compared to having your XML to Java bindings done automatically for you.

WebLogic 6.1 doesn't provide any testing utilities or automated tools. However, given that the SOAP interface is generated automatically by the WebLogic WSGEN process, automated regression testing of the SOAP service could instead be implemented at the EJB component level. This may make sense since there are more testing tools out there for EJB components than there are for SOAP-based Web service interfaces. Of course, any change to the EJB interface (and subsequently to the SOAP interface) would be flagged as an error. You may still want to extensively test the SOAP interface using a test client to make sure that the fundamental binding from EJB to SOAP request is correct.

Obtaining a Copy
WLS 6.1 can be downloaded from the BEA Web site. It comes with a 30-day free license. Be prepared to download a 73-meg file.

A Sound Implementation
With the WebLogic approach, you're really designing a SOAP service through an EJB component. The SOAP service is, in a sense, an extension of a stateless session bean for RPC services and message-driven beans for asynchronous, extended transaction types of services. Whether this approach is good or bad depends on your implementation. At this time, it is difficult to compare it with other products because of the limited number of vendors supporting SOAP. Moreover, the SOAP 1.1 standard doesn't specify how the interface is to be implemented, so we can't use that as a gauge either.

The BEA approach poses other questions as well. Is it easier to design a Web service starting with the SOAP interface and working through the integration issues from there? Or is it easier to design the EJB component, test it, and then have the service automatically generate the SOAP and WSDL XML? There are more EJB development and test tools out there, so deploying SOAP services as transparent extensions to an EJB component layer would, in my opinion, speed up the development process.

One particular downside to passing SOAP requests through the EJB interface is that it forces you to represent complex XML data types using a class structure (typically consisting of Java beans). This makes it awkward to use complex XML structures for parameter and return values, requiring you to implement a class representation that is mapped to the complex XML type during the WSGEN build process. Therefore, you may find it a little challenging to implement a WebLogic SOAP service that needs to dynamically navigate through a complex XML parameter and to be able to arbitrarily bind program variables to elements.

Overall, BEA's implementation is sound and the approach does make it easier for the average developer (yours truly included) to implement a SOAP service. As BEA and other leading vendors begin to adopt and implement the various Web service specifications, I can envision SOAP-based Web services bubbling up all over the Web in the not-too-distant future.

Author Bio:
Joe Mitchko is a senior consultant with Phase II, a leading consulting firm specializing in Internet and database-related architecture based in New Jersey. jmitchko@rcn.com