By Nitin Bharti

April 2002

On the fourth day of EJB For Architects, we take a look at Web Services, and the various technologies that comprise them such as XML, SOAP, WSDL, and UDDI. During the latter part of the day, the class is divided up into two groups whose goal is to model a real world J2EE application using the various J2EE technologies covered in class so far.

Introduction

The morning rays of the sun illuminated the brown, ordinary looking building at 230 West Monroe Street, where ordinary people filed in for their ordinary jobs on what was another ordinary day in the city. Buildings of the most varying shapes and forms stand together in downtown Chicago, some great feats of modern architecture, others echoing an older time, while yet others, boxlike and nondescript, simply stand silently against the Chicago skyline.

All these diverse buildings nevertheless shared a common infrastructure that defined the city: common roads, sewers, transits, and city bylaws. Conformity, integration, and universality. Was this what Web Services was all about? Is this what J2EE is reaching out to? As I walked into the front foyer of 230 West Monroe Street for the fourth day of EJB For Architects, meditating on these profound questions, it all started to make sense. Today's class was not only about integrating J2EE internally, but about reaching out to something greater: Web Services.

Web Services: SOAP, WSDL, UDDI

As a lead in to the Web Services unit, Partha asked the class "What problems are there when integrating 2 businesses?" Several issues were raised such as different infrastructures, firewalls, and the problem of agreeing upon a common data schema. Web Services attempt to address the discrepencies of B2B integration by making business services universally accessible through a common protocol (SOAP), interface language (WSDL), and data format language (XML). Although there are vague and disparate notions of what exactly Web Services are, what is certain is that XML lies at the heart of all true Web Services.

"There is no formal definition right now," explained Partha. "The loosest definition is that a Web Service is any remote service that takes XML input and processes XML output. XML in, XML out."

On the server side, the goal of a web service is to make a computational resource available over the web to a client via various XML technologies like SOAP, ebXML and UDDI. UDDI allows a business to publish its service over the web so that others can discover it and learn its interface. SOAP is a standard way of packaging and sending XML over the wire and is basically used to call a web service. On the client side, an application is written against the web service interface which can invoke the service, register with it, and arrange for payment and authorization to use the service. The client calls the remote service using SOAP or ebXML (a standard method, similar to SOAP, for exchanging business messages).

"How many people have worked with SOAP before?" Partha asked the class shortly before the lunch hour.

"I use it every morning" answered a student. A roar of laughter erupted. It certainly was a humourous and unexpected lead in to the section on SOAP.

Because performance over the internet is slow, traditional method invocations like RMI-IIOP, or DCOM-RPC are impractical for Web Services. Additionally, firewalls and disparate middleware further complicate B2B integration. SOAP is a lightweight protocol that allows heterogeneous enterprise systems to communicate, and is middleware- and language-independent. It is relatively simple to implement and easy to debug. However, since SOAP is unidirectional (i.e. the client doesn't receive a stub from the service provider), it is only good for stateless invocations. Other drawbacks of SOAP include its vendor-specific implementations across service providers, since there is no standard API for SOAP just yet. The SOAP specification still requires further work but because it has wide industry support, standardization isn't a long way off. Before lunch, Partha took the class through an indepth, technical overview of SOAP by showing and dissecting some real world examples.

It was a humid afternoon in Chicago, and as class recommenced after lunch, you could hear the sound of cold Snapples being opened. Partha, preparing the slides on WSDL and UDDI, prophetically declared as people settled into their seats:

"Why are we even teaching Web Services? The point is that you need to start thinking about services as soon as you think about implementation changes. Microsoft .NET is not going to fail. It's here to stay. You know that message in your car mirror saying objects are closer than you think? Well, Web Services are closer than you think."

WSDL (Web Services Description Language), is an XML format for describing the interface to a web service. It allows for web services marketplaces to match requirements. UDDI (Universal Description, Discovery, and Integration) is a way to publish and access web service interfaces. To get the class better aquainted with real world implementations of these technologies, Partha went to a site called Xmethods.com which provides services that facilitate the development, deployment, and usage of web services and web service networks. The site was basically a UDDI registry. One of the web services on it was an application, called BabelFish, that translated a string sent by the client from one language into another. A java client which he had written in accordance with the WSDL interface for the service, showed some of the intricacies involved in calling and consuming a web service. A syntactical look at the WSDL inferface revealed various XML tags that helped to guide, define, and format incoming messages.

UDDI defines 4 key elements: businessEntity, businessService, bindingTemplate, and tModel. The businessEntity element contains information about your company and is accessible via a web browser. The businessService element describes a particular service or category of the service you offer. The bindingTemplate contains technical information about a particular interface for a service. The tModel is the URL reference to the actual interface specification such as the WSDL document.

J2EE Group Project: Putting it All Together

After break, the class returned to quite an unexpected surprise. All the J2EE technologies we had learned in class were going to be applied in the modelling of a real-world business application. In the example application, Company ABC has a catalogue that needs to be accessed by both web-based and java clients. Registration is required but once users are logged in, they can purchase items from the catalogue using a credit card. The system must log every cancelled order and completed purchase in separate logs. Company ABC also wants to make this catalogue available to WAP clients who must provide the catalogue id, quantity being purchased, and credit card information. Additionally, the existing LDAP and RACF security structure of company ABC needs to be consulted to see if a userid and password are already defined there (if they don't exist in the current relational database).

The class was divided into two groups and it was interesting to see how each group approached the problem. Group 1 immediatedly started creating a diagram of their J2EE process model while Group 2 started off by defining their object model. As I paced back and forth between the groups, I noticed that Group 1 had more difficulty agreeing on effective design pattern strategies that met the requirements while Group 2 seemed to proceed comfortably from a well defined object model into the application design phase. Group 2 also seemed to have appointed a leader from the start who provided guidance and direction while Group 1 was more democratic in their approach of trying to incorporate everybody's ideas equally. Surprisingly enough, the end results turned out to be quite similar for both groups, although there were subtle differences.

Group 1's solution had two servlets: one for the WAP client and a 'general' one for web based clients. The web based and WAP clients talk to their respective servlets while the java client communicates directly with a stateful session bean. A business delegate sits between the servlet and the session layer, encapsulating all business logic, delegating method calls to EJBs, and allowing for the local caching of data. There was also some mention among Group 1 members of possibly wrapping the entire application as a web service for WAP clients.

Group 2 had a similar setup except for the fact that they only had one common servlet which received requests from both the WAP and web-based clients. When asked how the application will distinguish incoming requests by client, Gopal Pillai, who was presenting for Group 2 gave the simple answer: "look in the header." For credit card validation, a synchronous SOAP message is sent to a third party such as Verisign. An interesting feature in Group 2's system was the dynamic replication of users from the LDAP and RACF systems into the local database. When one of these users, already registered on a legacy system, first logs in, they are verified against the legacy system at which time a copy of their userid and password are created on the local database. On subsequent logins for that user, network overhead is reduced as the information can now be verified against the local RDB without having to make calls to LDAP or RACF. For logging purposes, both groups had agreed that JMS and Message Driven Beans were the solution to keeping track of cancelled orders and completed purchases.

The fourth day proved to be exciting in terms of conceptually 'gluing together' J2EE using a real world example. Web Services was not only taught as food for thought, but as something that can actually be written here and now; the examples shown in class testified to the reality of Web Services and made the class more aware about the importance of XML as a common language which businesses must standardize in order for B2B integration to become possible. On the fifth and final day of EJB For Architects, we will look at Large Scale System Design and Web Architecture, continuing with the fusion of J2EE technologies into robust, scalable, full-fledged enterprise systems.

PRINTER FRIENDLY VERSION