Office applications Toolkit

Magical Web service tour

Tags:
B2B,
SOAP,
HTTP,
XML

Bain McKay Builder.com

Published: 13 Jun 2002 16:48 BST

In this new application era, Web services supersede EDI (Electronic Data Interchange), and synchronous processing gives way to asynchronous processing over SMTP, using SOAP (Simple Object Access Protocol) for distributed cross-platform interoperability. But there's a lot to learn. Take the Web services tour for everything you need to get started.

We'll begin with an overall architectural diagram (Figure A) and proceed by building a deeper understanding of the components.

Figure A

Architectural diagram

While Web services can operate over synchronous message transports like HTTP, with B2B an asynchronous transport like SMTP is more appropriate. Using SMTP, a J2EE transaction request is transported to its targeted destination and queued to execute against a Web service without need for the client to wait for a response. When the transaction completes, the results are placed in the J2EE transaction response, and a message posts to the LDAP directory notifying the client application that the results are available. The client application retrieves the results and processes them locally.

The J2EE transaction model is reminiscent of the old department store system, in which the sales clerk places the sales details in a container, closes it, and sends it via a pneumatic tube to the accounting department. The accounting department transacts the sale and returns the invoice through the response side of the tube. This system has been replaced by point-of-sales (POS) automation. The endpoints represent the sales clerk's station and the accounting department respectively, except in B2B, they really represent remote business transaction services.

Locating the transaction service
Services are registered in a registration database through the UDDI (Universal Discovery, Description, and Integration) protocol, which provides an API for client applications to find and execute remote services through attribution queries, and for supplier services to register themselves, their services and respective attribution. UDDI is layered on top of SOAP in the Web services architecture hierarchy (see Figure B). SOAP provides the ability to route remote transactions safely through corporate firewalls so that the transaction can be serviced by secured back-end databases and applications.

Figure B

Web Services stack

UDDI services include:

Contact information for the publisher.
Services the publisher provides as specified by a business entity data structure.
Technical information on the service provided, including a WSDL file.

A business entity description is an XML file detailing element definitions. It includes a categoryBag that contains general categories as a taxonomy describing the type of business and its services (also called a tModel or Type Model). Standard tModels exist to describe businesses and services, providing the ability to programmatically query UDDI Directories by services categories. TModels have unique keys that can be used as signatures of services ontologies (an ontology is a taxonomy with relationships). This delivers a powerful offering that aims to supplant EDI with an inexpensive, widely accessible, intuitively usable commodity-B2B transaction service for the masses.

What's remarkable about Web services is all this is accomplished programmatically, with no manual intervention necessary. This means you can leverage the power of the Internet with the power of J2EE technology to automate distributed and remote B2B transactions supporting any kind of service that can be automatically packaged. UDDI-API calls like the following provide the programmatic ability to find and execute remote Web services:

find_business: searches for businesses by name, category, supported models and more
find_relatedBusiness: finds businesses related to a specified business
find_binding: finds services signatures that are compatible with your software application
find_service: finds services that a business offers
find_tModel: finds tModel structures (taxonomies and ontologies) that match the criteria specified
get_bindingDetail: gets the binding detail structure given the bindingKey. Bindings represent the In and Out parameters for driving remote transaction services components.
get_businessDetail: gets information about the business specified
get_serviceDetail: gets details on the service specified
get_tModelDetail: gets details on the tModel specified

Once found, how does the client application instruct the supplier application to service its request?

UDDI Services are described using a standard language called Web Services Definition Language (WSDL). WSDL is an XML derivative language for describing services parameters, attributes, and methods in a standard format, much like a schema for invoking database services. This allows remote application methods to be fed and executed, and results generated and placed in the response side of the transaction request. If you consider that J2EE architecture tends towards application component decoupling through declarative scripts, you could view WSDL as a declarative binding declaration for distributed application methods. A method at the client endpoint can run a method at the supplier endpoint, passing its parameters and setting its attribution accordingly over SMTP, with the remote method passing results back to the calling method through the J2EE Transaction Response.

Go to section: