|
Wednesday October 31 2001 CapeConnect Three From Cape Clear Software Early Release Assessment 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:
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.
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:
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:
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. |