Two distinct initiatives have come to the forefront as means
by which applications can be presented as Web-based services:
Microsoft's .NET and the J2EE platform. Application servers
and toolsets are beginning to tailor themselves to the Web
services paradigm as the concept matures. One such product
is Cape Clear's CapeConnect Two for J2EE.

CapeConnect provides an environment in which Java and
J2EE components may be presented as Web services
accessible via SOAP calls, defined by WSDL, and
cataloged by UDDI. Figure 1 illustrates
CapeConnect's architecture. SOAP clients access
the CapeConnect Web Services Platform, which
routes requests to the appropriate enterprise component.
This provides the capability to leverage the existing
investment in enterprise technologies with minimal
modifications to those systems.

Components of CapeConnect
CapeConnect consists of three major components:

The CapeConnect Gateway, essentially the message broker,
receives all SOAP client requests and forwards the messages
to the XML engine.

The XML engine converts the incoming SOAP requests
into Java method calls, routes them to the appropriate
enterprise components, and converts the results back into
SOAP messages.
Exceptions are handled through SOAP faults.

The J2EE engine is a fully-compliant Enterprise Java
container that may be used to serve EJBs. Alternatively, CapeConnect fully integrates with BEA's WebLogic 5.1 and 6.0 application servers, which may be used in place of the provided container. Future versions of CapeConnect will include integration with the iPlanet family of application servers and IBM's WebSphere.

Working With CapeConnect
Installation and Configuration
The installation process for CapeConnect is simple. I've installed it on a Windows 2000 Pentium III machine with 256Mb of RAM; versions are also available for Linux and Solaris. At install time, the choice between using the provided J2EE engine and integrating with WebLogic for serving EJBs is presented. Integrating with WebLogic requires a few simple steps to establish communication between the servers prior to creating services. Once installed, CapeConnect is ready for use with example applications and for deploying custom components. For this review, I've elected to use the WebLogic integration option.

Supporting Web Services
CapeConnect Two for J2EE exposes stateless session EJBs and standard Java classes as services available through SOAP calls. To do so, the developer deploys Java classes and Enterprise beans with CapeConnect either in lieu of a separate application server if the provided container is being used, or, if integrated with WebLogic, as a supplement to the normal deployment process. CapeConnect then generates the stubs and XML translations required to handle requests. Optionally, the developer may generate a WSDL profile for the object being deployed.

Two formats of SOAP action fields are supported by a proprietary format recommended for clients that exclusively access CapeConnect services, or a custom-defined format providing flexibility to clients communicating with multiple server environments. If the custom format is used, CapeConnect requires that WSDL be generated for the components deployed.

Creating Web Services
I've created a simple movie management system using EJBs deployed on WebLogic 6.1. It allows users to create and update a catalog of their personal collections of movies and videos. The system contains a single stateless session EJB to provide the external interface and a BMP entity bean to manage data persistence.

Once the beans are deployed on WebLogic, CapeConnect must be configured to route SOAP requests to and from the stateless session EJB acting as the interface mechanism. The first requirement is the location of the application server that hosts the components. An XML configuration file manages the mappings between services and their containers. During installation, if integration with WebLogic was specified the connection to the server is already established in the configuration file. Additional instances may be added by editing the file manually. Once the location of the EJB container is specified, the CapeConnect console may be used to add the individual application object. The information provided in the entry for each service includes the service name, the JNDI name for the associated object in its container, the server on which it resides, and whether the service requires a secure connection from the client. If no WSDL is required, clients may begin requesting the deployed Web service. Otherwise, WSDL may be generated for deployed objects through a wizard.

SOAP Clients with Cape Clear SOAPDirect API
Although it supports custom SOAP messages, CapeConnect provides a proprietary API called SOAPDirect. The API is intended to simplify the development of Web services clients that communicate exclusively with services exposed by CapeConnect. It isolates the details of SOAP messages from developers to reduce the learning curve and time needed to create service clients.

Creating a SOAP Client
Creating SOAP clients with SOAPDirect is very straightforward. The first step in the process is to create a request object and add any associated parameters. The developer is required to have the URI for the desired service available in order to construct the request object. The URI includes the application name specified in the configuration console and the JNDI name of the object being requested. There are three mechanisms to handle parameters for a request.

• Simple parameters, such as Strings, Integers, etc., may be added to the request through overloaded add methods that support the various Java data types.
• Array parameters may also be passed to the request from additional overloaded methods that receive an array value of the various Java data types.
• Generic container classes handle more complex, custom structures. This container class holds field names and values for the custom object in the request, which is then mapped to the method signature of the called component.

For the movie example, the lookup method requires two parameters. The first is a primitive integer value that represents the unique number of the movie. This is set with the appropriate add method on the request. The second parameter is a custom user object specific to the movie manager system. In order to pass the user along in the request, an instance of SDComplexType is created. Each property of the user is added to the SDComplexType object, which in turn is appended to the request object.

When the request is invoked, the CapeConnect Gateway receives the request and sends it off to the XML engine where it's interpreted and sent to WebLogic 6.1 for processing. WebLogic's response is received, translated back into a SOAP reply, and sent through the gateway to the calling client as an SDReply object.

From the SDReply object, data values can be extracted via the accessor methods structured not unlike the accessor methods on a JDBC Resultset object. The reply object also provides an accessor to an SDComplexType object that maps any complex object returned from the EJB. In the case of the movie management system, a customized movie object was returned with all the properties of a movie. By providing the name of the desired property, the values may be retrieved and manipulated in subsequent processing.

Summary
CapeConnect Two for J2EE provides an effective solution for extending enterprise components including EJBs, CORBA objects, and standard Java classes to the outside world as Web services. It's a very simple package to install and administer. The provided SOAPDirect API has a reasonable learning curve that isolates developers from the intricacies of SOAP. It also provides the flexibility to work with any variant of SOAP and makes the creation of WSDL definitions extremely simple. With its integration into WebLogic, and future integrations with iPlanet and WebSphere, CapeConnect allows existing investments to be leveraged and extended with minimal impact.

• Figure 1