Wednesday September 26 2001

Enabling Web Services with BEA WebLogic

Using WebLogic and CapeConnect from CapeClear

Romin Irani

Printer-friendly version

BEA Systems, Inc., announced full support for Web Services in release 6.1 of their industry leading WebLogic Application Server. Though they had provided this starting from the Beta release of Version 6.1, it was not until the formal release of version 6.1 that developers really started getting serious about taking a look at their Web Services support.

In this article, we shall take a look at some of the practical considerations in implementing Web Services in general and then see how we can address those within the BEA WebLogic platform. Of course, during the course of our discussion, we are well aware that it is not feasible for every company to migrate to version 6.1 of the BEA WebLogic Application Server. This is due to the fact that several companies have existing systems on previous versions of WebLogic and they would like to protect their investments in such systems. We shall also discuss options open to a company having version 4.5, 5.1, 6.0 of the WebLogic Application Server in order to enable select aspects of their functionality as Web Services.

Web Services Today

Web Services as they stand today comprise open Internet standards like WSDL, SOAP, and UDDI. WSDL is used to describe the Web Service, UDDI is used to publish and query Web Services, and finally SOAP is used to invoke the Web Service. This is the common Web Services programming model, as we all know. Web Services provide compelling benefits to organizations that plan to use them. Primary among these include: low-cost of development, open Internet standards, and chiefly the overwhelming support demonstrated by all the system software providers like BEA, IBM, Microsoft, Sun, Oracle, etc. Along with these large organizations, we are seeing a number of smaller organizations announcing toolkits and platforms that ease the development of Web Services.

For any organization, finding Web Services platforms and tools is not a problem. Getting them to work together may be though. At the same time, organizations with existing business applications are looking beyond just the simple "describe, list, and invoke programming" approach as propagated by the Web Services programming model.

Some of the common concerns that are raised by organizations today are the following:

• Business Processes
  Any organization uses complex business processes that tie in with applications from different departments in an organization. These organizations are interested in learning how Web Services can participate within a business process along with transaction support, routing of messages, etc. The concern is that most of the Web Services platforms that we see today provide a quick way of Web Service-enabling existing applications and invoking that functionality. Business Processes however automate a set of operations that the organization performs. These operations could encompass, that is, aggregate several Web Services, invoke other systems, and perform transactions all as part of the business process. Hence it is important for an organization to be able to understand how exactly Web Services would seamlessly fit into already defined business processes.
• EAI support
  Web Services are often touted as being an effective alternative to EAI (Enterprise Application Integration). Although it is not practical to say that Web Services will replace all the existing EAI platforms out there, it is fair to say that in certain situations they do offer a more cost-effective and much simpler mechanism to integrate applications within the enterprise. For Web Services to be used effectively for EAI, we need to see how any of the current Web Services platforms would aid in Application Integration. An example of Application Integration within an organization could be integrating a custom financial application written in Microsoft Visual Basic to connect to the SAP ERP system to obtain details like invoicing, purchase orders, etc.
• B2B Communication
  For organizations that conduct electronic businesses with partner organizations, it is important to see how Web Services would blend into providing support for XML vocabularies like ebXML, RosettaNet, cXML, etc. For Web Services to be used effectively for enabling B2B Integration, the Web Services platforms need to address common XML dialects, translate between dialects via XSL, security, compliance to contracts, etc.

As noted above, organizations are evaluating these very aspects of Web Services. It would be very difficult to find a Web Services platform today that addresses all of the above. In the remaining part of this article, we shall take a look at how organizations using or planning to use Web Services within the BEA WebLogic platform can address some of the issues.

To analyze the options available for implementing Web Services within WebLogic server, we need to classify organizations into two kinds, those that have existing applications on WebLogic Server 4.5/5.1/6.0 and those that are planning to develop afresh on WebLogic 6.1 or planning to migrate to WebLogic 6.1

Customers with Existing Applications on Versions Prior to 6.1

In this case, there is no support for Web Services standards like WSDL, UDDI, or SOAP. For organizations to migrate to version 6.1 of WebLogic is often not practical from a business sense. One of the extreme options that a company can choose is to implement the Web Services standards within their application. But this requires deep technical expertise and extensive testing. On the other hand, there are several Web Services platforms that are available today from vendors that help protect existing investment in EJBs and help expose the functionality in them as Web Services.

Let us consider how this can be achieved today using a Web Services enabling platform like CapeConnect for J2EE from CapeClear Software (http://www.capeclear.com/). We shall assume that the application is running on one of the following versions of WebLogic: 4.5, 5.1, or 6.0. CapeConnect is a Web Services platform that allows you to expose your existing Java and EJB components as Web Services, providing full support for WSDL, UDDI, and SOAP.

Let us take a look at the following diagram showing how this is possible:

We will start from the extreme right where the current application functionality resides in the WebLogic Application Server. Of course, it is important to note that one does not expose functionality present in the EJBs as it is. Instead, the organization will accordingly decide on aspects of this functionality that need to be exposed. In the diagram we assume that the EJBs represent the functionality that needs to be exposed as Web Services. The steps involved in exposing these EJBs are Web Services are as follows:

1. The CapeConnect platform, and generally most of the other platforms available today, provides support for exposing only stateless session beans. From the EJB interface definitions (the home interface, remote interface, etc.) we generate WSDL files that map to the equivalent EJB business methods. This is done using the WSDL generator tool.
2. Once you have the WSDL files, you can interpret them directly to invoke SOAP calls on the methods via the Apache SOAP API, or instead use a simpler SOAP API called SOAPDirect from CapeClear.
3. CapeClear also provides an excellent RAD tool called CapeStudio that helps generate either Java or Visual Basic stubs that you can call from your Java or VB client code. This shields the calling program from knowing too many details about SOAP programming.
4. Finally when a SOAP request comes in, the CapeConnect gateway receives the request, which is then parsed by the XML Engine, which in turn activates the correct EJB, invokes it, and packages the return values as a SOAP response and sends it back.

So from the above process we find that using a CapeConnect Web Services platform is a convenient way to expose functionality in existing EJBs as Web Services. Exposing Web Services and using them via the generated stubs, however, is more of a Point-to-Point integration scenario. A Point-to-Point integration between two applications means that both applications are aware of each other's details, thereby resulting in tighter integration. This, however, sacrifices key features like being able to adapt to changes in the two applications. As we had highlighted before, though, such a process suffers from inherent drawbacks, some of which are listed below:

• Lack of support for Business Process integration.
• The Web Services invocation is synchronous, like Remote Procedure Calls. Several business scenarios need to integrate with Web Services in an asynchronous manner.
• Transaction support will need to be handled by your application, or you can depend on the transaction capabilities of WebLogic Application Server.
• There is no local UDDI server implementation to aid organizations in hosting internal UDDI registries with partner organizations.
• Lack of inbuilt versioning support would present unique problems if the Web Service were upgraded to a new version while running the older version, etc.

Until recently, this strength has been somewhat mitigated by the fact that there were several competing Java commerce platform vendors that did not comply, nor intend to comply, with the J2EE standard, Sun's platform for enterprise computing. In the main, companies have quoted their lack of faith in the technology, though the loss of existing code bases and the work to convert the rest must have been overwhelming. To some extent this was no doubt in part due to the proprietary, counter standards approach to application servers that has been the norm until recently.

Customers Migrating to or Using Version 6.1

WebLogic 6.1 enables full support for Web Services standards like WSDL and SOAP. For organizations that are planning to migrate to WebLogic 6.1, they can continue to use a third-party Web Services platform like CapeConnect. In this section, however, we shall take a look at the Web Services support provided by WebLogic 6.1 itself.

In summary, WebLogic 6.1 provides the following features as shown below. Note that we relate this to the components that CapeConnect software provides as we saw in the previous section:

• Web Services run-time component
  This is similar to the CapeConnect Gateway/XML Engine that we saw before. This run-time component is responsible for receiving the SOAP requests and invoking the appropriate Web Service. An advantage over the CapeConnect engine is that the Web Services run-time component supports, in addition to the RPC-style (synchronous) invocation mechanism, an asynchronous (JMS-based) mechanism to invoke your Web Service.
• Standardized J2EE assembly and deployment
  An Ant task along with the Administration console is used to package and deploy Web Services as standard .ear files. This is a feature unique to the WebLogic 6.1 Web Services implementation. In CapeConnect, you will have to follow a predefined mechanism for deploying your Web Service that is proprietary to CapeConnect.
• Generation of WSDL file
  From the deployed Web Service, WebLogic automatically generates the WSDL for a Web Service that will be used by the SOAP clients to invoke it. This is similar to the WSDL generator in CapeConnect.
• Java client to invoke WebLogic Service
  WebLogic generates a thin Java client that can be used to develop Java clients that invoke Web Services. This is similar to the stubs that CapeConnect generates.

From this discussion, it should be clear how the WebLogic 6.1 Web Services solution closely mirrors the approach CapeConnect employs to enable the EJBs in pre-6.1 versions of WebLogic. Apart from an additional way of invoking your Web Services (asynchronous), this simple enabling of Web Services in WebLogic 6.1 still suffers from the same drawbacks that we listed before: lack of business process support, lack of support for XML-standards, etc.

BEA WebLogic Integration

So, what is BEA trying to do to address these issues, without which acceptance of Web Services into enterprises will remain but a dream? BEA have introduced a new product called BEA WebLogic Integration, which is really an integrated offering of four products in one:

1. Application Server: This is the J2EE Application Server that we discussed above.
2. Application Integration: This product simplifies integration of e-business applications with enterprise systems like SAP or Siebel based on the J2EE Connector Architecture.
3. Business Process Management: This product represents a process solution that allows business analysts to design and execute complex e-business processes. This process solution will allow analysts to combine services from different applications from a business point of view without worrying about the technical details of it like the J2EE Connector Architecture, etc.
4. B2B Integration: This product helps to automate cross-enterprise business processes. The product provides support for a variety of standards like RosettaNet, and leverages Web Services technologies like SOAP, UDDI, and WSDL.

If you look in detail at the B2B Integration part of the BEA WebLogic Integration product, you find that it really takes the simple Web Services that we described in the previous section to a more complex level typically used in a business scenario. It thus meets some of the requirements that we identified in this article. Some of the features that it provides are as follows:

• Support for standards like RosettaNet, cXML, and SSL
• Support for conversational state, which helps in long-running collaborative processes
• Support for sophisticated aggregation of Web Services by combining them into a transactional and collaborative workflow process
• Support for advanced security mechanisms like non-repudiation and digital signatures

Conclusion

From this article, readers should be able to get an understanding of possible approaches available today to help enable Web Services in BEA WebLogic Application Server. We considered not only organizations that will continue to use older versions of WebLogic Application Server in which there is no native Web Services support, but we also saw the simple Web Services support provided by WebLogic version 6.1.

The solutions for both these cases, however, fall short of complex business processes that are prevalent in organizations today. It is hoped that platforms like the BEA WebLogic Integration solution will provide a single platform that will help to address issues of multi-party, collaborative processes that will help ease organizations into global electronic business.

The author hopes to provoke debate from vendors of Web Services platforms and toolkits regarding their efforts to solve the problems outlined here.

Similar articles:
Practical Considerations In Implementing Web Services, by Romin Irani
Web Services Spin, by Brent Sleeper of the Stencil Group.

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