Wednesday October 31 2001

CapeConnect Three From Cape Clear Software

Early Release Assessment

Romin Irani

Printer-friendly version

When it comes to toolkits and frameworks, the major vendors such as IBM and Microsoft seem to be making all the noise. There are, though, smaller players who are quietly making the deployment of Web Services easier and quicker with their more innovative products. One such Web Services platform that is currently attracting a lot of attention is CapeConnect from Cape Clear Software (http://www.capeclear.com/). Cape Clear just recently announced the latest upgrade to their Web Services Platform with the release of CapeConnect Three.

In this article, we will take a look at what the CapeConnect Three platform can do for you. We shall look at the basic architecture of the platform along with the different features that CapeConnect Three provides. Finally we shall also take a brief look at CapeStudio, which is a complementary product from Cape Clear. The CapeStudio product is a RAD environment for developing Web Services.

We shall make an assumption here that readers are familiar with what a Web Service is and its core technologies like XML, SOAP, WSDL, and UDDI. This article is focused on how simple Web Services are realized and deployed through Cape Clear's products.

Senior executives from IONA Technologies founded Cape Clear (http://www.capeclear.com/) in 1999. It has two products: CapeConnect, which enables companies to expose back-end systems such as J2EE and CORBA to the Internet as Web Services and CapeStudio, which is a development environment for business analysts and software developers who need to rapidly compose and customize these Web Services as business applications.

CapeConnect Three

If you had to describe CapeConnect briefly, you could say it is a platform that provides a Web Services architecture (SOAP, WSDL, and UDDI) for extending your current Java, EJB, and CORBA systems, including interoperability with MS .NET. The new features in CapeConnect Three, combined with CapeStudio, allow Cape Clear to claim that it provides the best tools for building Web Services and the most comprehensive feature set available to date in the industry.

Current Requirements for a Web Services Platform

Before we analyze any Web Services platform, we need to first ask ourselves what we expect the platform to do for us. The last few months have seen a lot of Web Services activity from different vendors; some of whom have exaggerated their claims about what Web Services can do today. We will aim to cut through all that hype and focus on the current realities.

From all the papers and articles published, you would have noticed that the only feasible type of Web Service possible today is a basic Web Service. A basic Web Service is a simple extension of existing functionality present today in the form of a Java class, CORBA component, VB6 module, or indeed almost any language. The extension should be such that:

• You can invoke that functionality via SOAP clients.
• You can describe that functionality via WSDL files in a platform and language neutral fashion.
• You can publish and find that functionality via UDDI.

To put the above requirements in the right perspective, we have the following more detailed requirements. Note that since CapeConnect is focused principally on exposing J2EE components as Web Services, examples in this article will assume Java as the language of choice.

• An organization today can have its existing functionality in JAR files, EJB components, and so on that could be hosted within an application server environment like BEA WebLogic, IBM WebSphere, or iPlanet. A Web Services platform should be able to non-intrusively extend these components to a Web Services architecture. By non-intrusive extension, we mean that we should be able to wrap a Web Service interface around our component (EJB, CORBA component) and invoke this interface without any change to the component itself.
• A Web Services platform should be capable of providing a runtime environment for the above. In other words, it should be capable of receiving a SOAP request, interpreting the request, mapping it to the correct Java component, invoking the back-end component, packing the response back as a SOAP Response, and delivering this result back to the SOAP client. Until the industry sorts out interoperability issues, the Web Services platform must support multiple third-party SOAP clients, especially Microsoft SOAP Toolkit.
• A Web Services platform should support the latest specifications of SOAP, WSDL, UDDI, and the XML specifications like XML Schema, etc. that they are built on.
• A Web Services platform should be able to address security adequately.
• A Web Services platform should be scalable.

Given these basic requirements, let us look at how the CapeConnect platform measures up.

CapeConnect Three Architecture

Let us first take a look at the CapeConnect Three architecture, and understand how it works. We will start by identifying the different components that make up the design-time/run-time environment of CapeConnect, and how they work in unison to achieve our basic requirement of providing an infrastructure to non-intrusively extend existing functionality to a Web Services architecture.

The CapeConnect Three architecture is shown below:

Note that the EJB container could be any EJB container, including the CapeConnect application server.

Instead of just listing the components of the architecture, let us take a different route to understanding the platform, that is, describing the product by describing how it works. This can be better understood by looking at the activities at design time versus runtime. During design time, we are concerned with writing a Web Service and deploying it for consumption, writing SOAP clients to access the same, and so on. During runtime, we want to make sure that the SOAP request is routed to the correct component, which provides the required functionality, business process, or back-end logic.

With this in mind, let us first concentrate on the Design Time activities. Take a look at the bottom of the diagram; this represents existing functionality that is present in the form of Java classes packaged as JAR files, EJB components, or CORBA components. The first step normally would be to prepare these components for access via the Web Services technologies. That is where the CapeConnect Deployment Wizard is used. This component is responsible for taking as input JAR files, EJB interface definitions, or CORBA IDL, and generating the appropriate WSDL file that lists all the operations, data types, and so on supported by that component. CapeConnect can handle complex types such as arrays of arrays, which means that existing functionality does not have to be rewritten. Also, CapeConnect can also generate Microsoft's proprietary WSML (Web Services Meta Language), as part of Cape Clear's strategy of providing MS.NET interoperability. CapeConnect has a useful WSDL repository for storing, searching, and displaying the generated WSDL and WSML.

A point to be noted here is that it is generally not a good idea to just take an EJB and expose it as a Web Service. A good deal of thought needs to go into deciding which functionality will be exposed from the system as a whole.

One of the great features that are new in this version of CapeConnect is that of a full local UDDI registry. Once the WSDL file is generated, the Deployment Wizard also gives you an option of publishing this information directly in the UDDI registry, with accompanying descriptions of the functionality provided by the Web Service.

Service Consumers that are interested in consumption of these Web Services take the WSDL file that was generated and, using an appropriate SOAP API/Toolkit, can write the client that will invoke the Web Service via SOAP calls over the Internet or intranet. CapeConnect provides an extremely useful but proprietary SOAP API called SOAPDirect that eases development of SOAP clients. Other third party toolkits explicitly supported include Perl::Lite and the Apache SOAP Toolkit.

Finally, we need a mechanism for deploying this Web Service so that a Web Service invocation via a SOAP Request at runtime is appropriately routed to the back-end component. CapeConnect provides a facility whereby this information is stored in an XML based repository that is handled at runtime by the CapeConnect XML Engine. Note that in addition to the Deployment Wizard, which deploys the Web Service, there are separate GUI tools for registering the mapping between the Web Service and the back-end component that actually implements this Web Service.

Now that we have generated the WSDL and published it, we obviously need to see how this entire mechanism is handled at runtime. The SOAP Client forwards the request to the CapeConnect Gateway, which runs within a Servlet environment. This gateway runs in a DMZ (demilitarized zone, between the application and the Internet), thereby providing you secure access between the firewall and the actual back-end systems. The CapeConnect Gateway is thereby responsible for forwarding these SOAP requests to the CapeConnect XML Engine. The Gateway is not typically needed for deployments on an intranet, where there is no DMZ between the internal intranet and external Internet. The XML engine, as we noted previously during our design phase, has access to the Web Service deployment configuration. It looks up this configuration to determine which back-end component it needs to route the calls to. Then it uses the appropriate communication protocol (IIOP, RMI) to invoke the back-end component, which could be residing in a third-party J2EE container or CORBA ORB. The XML Engine is thus responsible for translation between SOAP and the Java invocation and response. A notable standard feature is that both SOAP 1.1 and the more proprietary MS SOAP are supported. When MS SOAP messages are received, the corresponding SOAP response is sent in the correct MS SOAP syntax.

This is how the different components of the CapeConnect architecture work together to extend existing systems to a Web Services architecture.

CapeConnect Three - Feature Summary

Let us now summarize the different features of the CapeConnect Three Web Services Platform:

• Java and J2EE Support: The CapeConnect platform can expose new and existing EJB and standard Java components as Web Services. The platform supports the components in the following platforms: BEA WebLogic Server 5.1/6.0/6.1, IBM WebSphere 3.5/4.0.1, iPlanet 6.0. In addition to these J2EE platforms, CapeConnect platform also comes with a full-blown J2EE server, which could be used for deployment of the J2EE components.
• CORBA Support: The CapeConnect platform can expose new and existing CORBA components as Web Services. The platform currently supports the following platforms: IONA Orbix 3.3.1, IONA OrbixWeb 3.2, IONA Orbix 2000 2.0, Borland VisiBroker for Java/C++ 4.5, and BEA WebLogic Enterprise 5.1. No other Web Services Platforms currently support CORBA components.
• UDDI Registry: The CapeConnect platform comes with a full implementation of a UDDI Registry. This provides a convenient way for organizations to host a local UDDI Registry, thereby maintaining a repository of Web Services. CapeConnect also comes with a UDDI browser and a useful UDDIDirect client API for accessing UDDI registries.
• Deployment Wizard: The CapeConnect Deployment Wizard is a great tool to ease the progression towards quickly getting your Web Service up and running. It takes the JAR files, CORBA IDL, or EJB Interface definitions as input and generates the appropriate WSDL files. It includes full support for the XML Schema within the generated WSDL. Support for complex types such as collections, arrays, nested classes, and object graphs has been greatly improved in this version, thereby making it much easier for the client platform or language invoking the Web Service. Also, Java inheritance is now supported in CapeConnect Three. Another neat option within the Deployment Wizard is that it also provides you with the ability to publish this information to the local UDDI registry.
• Transport Protocols Supported: The CapeConnect platform support SOAP requests over the HTTP, HTTPS, and SMTP protocols. CapeConnect can also handle MIME attachments within SOAP Requests and Responses, which means that Web Services can now handle binary data like images. HTTPS provides a well-known way of ensuring the security of the SOAP messages, while SMTP enables asynchronous SOAP messages.
  
  Another key feature is that you can configure CapeConnect to use a connection-oriented protocol, that is, the same connection is used for multiple SOAP Requests thereby increasing the throughput. This would also result in significant performance gains in an external scenario between two trusted organizations where the service collaborations are simple.
• Security: The CapeConnect platform provides a security model within which the credentials of a SOAP Request are authenticated against an XML repository and requests can be encrypted and sent over HTTPS.
• Scalability: Since the CapeConnect platform supports connectionless protocols like HTTP, HTTPS, and SMTP you can easily cluster multiple instances of the CapeConnect platform to cater to efficient load balancing. It also uses a high performance SAX parser to speed up processing of SOAP Requests.

The CapeConnect Three platform is priced through developer and runtime deployment licenses. Developer licenses are $950 per user. The runtime deployment licenses are $10,000 per CPU.

In the next section, we will examine another product from Cape Clear called CapeStudio that really complements the CapeConnect platform by providing an environment for rapid creation of Web Services. Indeed, Cape Clear has stated that CapeStudio will quickly evolve into the Web Services development environment for CapeConnect.

CapeStudio

CapeStudio (currently in release 1.1) is a RAD environment that greatly simplifies the development of Web Services clients and servers for CapeConnect. It should be noted that CapeStudio can also be used as a standalone environment without the CapeConnect platform.

CapeStudio consists of two main components:

• WSDL Assistant: The WSDL Assistant is for use by developers, in order to generate Java or Visual Basic proxies from a WSDL file. These proxies contain the SOAP calls that make the requests to the Web Service. A client developer working in a Java IDE or Visual Basic IDE can then simply embed these proxy calls to make the requests to the Web Service. This shields the client developer from writing complicated SOAP methods or understanding WSDL files.
  
  The WSDL Assistant also provides a very useful feature that speeds up development of a Web Service: skeleton generation. This is useful if you do not have the code for the Web Service business functionality. You could start off with just the WSDL description and the WSDL Assistant will generate the skeleton service-side code for you, for example, stateless EJBs with deployment descriptors. You can then appropriately finish writing the business logic in the EJB.
• CapeStudio Mapper: The CapeStudio Mapper is a graphical tool that lets you do XML-to-XML translations. The Mapper will read XML Schema files for both the input and output and generate the XSL Transformation for the same. The CapeStudio Mapper generates the XSLT not only for XML-to-XML, but also for XML-to-SOAP and SOAP-to-SOAP.
  
  This is ideal for mapping your back-end system XML into a corresponding SOAP request via the XSLT and then passing on that SOAP request to the Web Service. This provides a huge productivity gain and I am pretty confident that this feature of the tool will be appealing not only to the developers but it will help present to the business analyst an easier and comfortable way to work within the Web Services realm.

Let us use our same method of understanding how CapeStudio would fit into the CapeConnect Platform (or any other Web Services platform).

Let us first concentrate on the Design Time environment. Given the WSDL files for the Web Service, the CapeStudio Development Environment (WSDL Assistant) is used to generate the Java Client or the Visual Basic proxies. Alternatively you can use the CapeStudio Mapper that we discussed to map an internal XML request to an equivalent SOAP response via the XSLT that it generates. These proxies are then integrated into the Client Applications (Java Client or Visual Basic client).

During runtime, the client application makes a call to the proxy, which in turn sends appropriate SOAP messages over the Internet to a Web Services platform (it could be the CapeConnect Platform or it could be any other Web Services platform). Finally the Web Services platform maps the incoming SOAP Request to the correct method invocation on the back-end component. The results from that method call are then packaged back into a SOAP Response and sent back to the client application.

Cape Studio development environment is priced at $450 per developer. There is no runtime/deployment license for using any of the code generated by CapeStudio.

Cape Clear list over a dozen reference customers on its Web site for CapeConnect and CapeStudio, including British Telecom, Robertson Stephens investment bank, General Electric, EDS, Ri3k, eFunds, Royal and Sun Alliance, and Sky Television. There are also some interesting case studies available, from http://www.capeclear.com/customers/.

Conclusion

This article presents the requirements for a Web Services platform and then discusses them in the light of the CapeConnect Three Web Services platform from Cape Clear Software. We saw how CapeConnect makes it very easy for a company to extend existing back-end functionality to a Web Services architecture. CapeConnect fulfills all the requirements for a Web Services platform and leads the field in terms of features and functionality. We also discussed CapeStudio RAD environment that complements the CapeConnect platform very well but it is also a powerful development environment that can be used independently to rapidly develop Web Services clients and servers.

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.

Printer-friendly version

Keep up to date with all the new articles and features on Web Services Architect:
Register for e-mail updates