As enterprise Web application development migrates from Business-to-Consumer (B2C) to the apparently more lucrative Business-to-Business (B2B) transaction model, developers must learn new technologies. 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.
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.
Can't get enough Web services? Check out these articles:
Web services: Putting theory into practice
Create your own Web services
Web services security
Web services with Java
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.
|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.
WSDL-XML documents contain a Header section for namespaces, a Services schema defining element types, a Messages section for element Request and Response mapping, a PortType section that defines endpoints for services, a Binding definition for Input and Output parameters, and a Security declaration section. A picture is worth a thousand words, so refer to Figure C for the WSDL-XML document structure.
|WSDL XML document structure|
Where's the SOAP?
SOAP is an XML derivative used by Web services to marshal transaction information into XML elements of the Transaction Request at the client side, bind it to the Transport protocol, and unmarshal it at the supplier side. It then reverses that process to pass results back to the client application through the Transaction Response. SOAP is protocol independent so it can bind to supported transport protocols like HTTP, HTTPS, and SMTP. For B2B, SMTP provides an appropriate asynchronous transport. Figure D gives a glimpse of a SOAP transaction’s flow.
What role does ebXML play?
Electronic Business using Extensible Markup Language (ebXML) is the counterpart to EDI in the XML world, providing extensibility, flexibility, and schema services as a common business exchange platform for trading partners. With ebXML, business contracts can include rules of engagement, process schemas, and namespace. EbXML uses SOAP headers to pass routing information.
What is transacted with Web services?
Web services can support any B2B transactions as well as a host of new transactions:
- Corporations can support automated B2B transactions in supply chain and customer value chain applications.
- Software can leverage Web services to automatically research and recommend best product offerings on a global scale in a productive manner heretofore unachievable on a manual or automated basis.
- Just-in-time inventory management can reach commodity status for small- and medium-size business usage.
- Web services providers will be in demand as third-party services brokers who facilitate inter-business flow through UDDI Directory Services.
- Information and knowledge providers can provide research repositories through semantic interfaces like taxonomies and ontologies.
Web services are waiting to take you away
Web services can take business automation to the next level of productivity and affordability through open standards. New services and products coming to market will facilitate automated inter-business transactions and highly productive knowledge and information research offerings. Enterprise application developers and product providers who don’t take advantage of J2EE Web services will be left behind in this architectural shift as these new, more productive technologies replace sunset application development architectures made popular over the past few years.