Infrastructure for an Interconnected Enterprise

The need for communications between applications across enterprises is well recognized; EDI has been serving this need for a number of years now. The Internet is providing a means for secure transactions between applications on a public network, bringing down the price point considerably. This makes electronic communication affordable for even smaller businesses.

Exploiting this development, a new genre of applications, known as EAI (Enterprise Application Integration), are entering the market. Players include TIBCO, NetFish, and SeeBeyond.

All of these tools have the following characteristics:

• Applications can receive messages from participating companies in multiple ways: ftp, email, SOAP, EDI etc.
• Received messages are published on message queues for guaranteed store/forward delivery.
• Consumers can subscribe to messages of interest.
• Messages can be transformed using a variety of schemes: XSLT, GUI, or User-Defined.
• Internal business processes for the flow of messages can be defined and controlled graphically.

Applications built with these facilities are especially important for industries that are supply-chain-centric, transportation-centric, and e-commerce-centric. The specific application areas may include warehouse management, inventory control, flow of goods across the entire supply chain, customer visibility, and tracking.

Driving this revolution from the data perspective and transformation perspective is the increasing role of XML.

Role of XML

In an interconnected enterprise, the primary task is the movement and interpretation of messages. It is important that there is a common language and structure for interpreting these messages. XML offers the following benefits for representing these messages:

• Well-defined grammar for defining message structures (DTD, XSD).
• Tools (such as parsers) available for working with XML documents.
• Tools available for generating and consuming XML messages.

This means any communication with the external world has an advantage when it uses XML. Let's take a look at the essential components for XML interconnectivity.

Ability To Receive XML Messages

An application must have an easy way of receiving XML messages. This could be done using any of the following ways: FTP, email, SOAP, enterprise connectors for Oracle, SAP, PeopleSoft, etc.

Regardless of the way a message is received, it has to adhere to the following:

• Security (Authentication and Authorization)
• Journalling
• Guranteed Delivery

This is where lot of the EAI tools can help in unifying the gateways through which messages can be received. Nevertheless, if a company has a Web server infrastructure, there is a cheaper alternative to buying a fully-functional EAI tool. The solution is to adopt SOAP. SOAP is widely available and has the following benefits:

• Uses your Web server as the gateway.
• Secure.
• Goes through firewalls.
• Very cheap.
• Widely available APIs/tools that sit on top of SOAP (JAXM, JAX-RPC, etc.).

SOAP does have some drawbacks, however:

• Not a store/forward architecture, where the server has to be available all the time.
• Any journalling has to be programmed on top of SOAP.
• Does not offer any explicit queuing.

Ability To Generate XML Messages

Much of the data in the enterprise sits in relational databases. An important question is how one can generate and send an XML message to a requesting customer. Let us list a few of the ways this can be done:

• Write a Java program that can create these XML messages from relational databases. This implies writing a Java program for every message that goes out.
• Use a graphical mapping/transformation tool such as Mercator to map from relational database tables to an XML message.

While the Java solution is open and can accommodate all data sources, the GUI solution may be limited only to relational database tables and SQL (not even stored procedures).

Another interesting observation in this XML generation is this: when an IT company develops a Web-based solution using JSPs, the company is already converting relational data to XML data -- the XML just happens to be HTML. So why not architect your Web solutions so that you can deliver your data either in HTML or XML? This way, you can have one solution that accommodates B2C and B2B simultaneously. This last approach is what I recommend to companies trying to integrate themselves into a global community of companies.

Ability To Define Transactionally Secure Services

Security. When you receive XML messages, it is important that they arrive through secure channels. The SOAP protocol makes use of SSL and HTTP to satisfy this requirement. In addition, you can make use of sessions supported by the servlet framework.

Transactions. When you receive an XML message, you may have to call a series of business processes to satisfy that XML message. These business processes will have to be executed within well-defined transactional boundaries. The transactional boundaries could have the following possibilities: no transaction at all, single-phase commits, two-phase commit protocols, or long-running transactions.

The solution should accommodate these transactional requirements. A Web server and its accomdating infrastructure, such as EJBs or MTS, can take care of this situation quite well.

Ability to Publish Available Services to Interested Parties

Another important aspect of an integrated enterprise is how easy it is to discover useful services between the collaborating parties. The mechanisms of publishing available services may range from informal conversations to Web-based documentation to more recent technologies such as UDDI. The visibility of newer technologies promises to revolutionize inter-company communications because of the new levels of access to information.

SOAP

The solution offered by SOAP as a transport for XML messages is compelling. SOAP runs on HTTP, thereby co-opting a publicly available network that can go through corporate firewalls, and makes use of SSL for security purposes. SOAP is typically implemented on well-known platforms, such as servlets, at little or no cost. SOAP uses the Web server infrastructure you already have in place for your B2C applications; no additional infrastructure is required.

UDDI

UDDI (Universal Description, Discovery, and Integration) is a public registry for all of the companies in the world to register their services under secure conditions. UDDI defines a standard way to publicize the services offered by a company. This discovery and visibility should revolutionize the communications puzzle. Any XML interoperability solution should seriously look at registries similar to UDDI to publish their services.

WSDL

WSDL (Web Service Definition Language) is another standard that allows you to declare your services in XML, allowing you to automatically register those services in UDDI. WSDL is a structured way to define your services to the outside world. WSDL identifies input and output XMLs for each message between participating companies. Typically, WSDL documents for each message are exposed through UDDI.

Process Analysis

The final effort required to adapt services infrastructure is to identify the business processes in a company and arrive at a series of refactored services that can be defined in XML. This process is similar to Object Oriented Analysis and Design (OOAD), where your domain object models are defined.

Similar to OOAD, UML (Unified Modeling Language) can quite effectively define what these services are, and what their inputs and outputs are. And the UML can be used directly to generate the necessary WSDL and UDDI documents. Once these services are identified, registered companies can start to collaborate using these well-defined API-level XML services.

Role Of Web Servers

As mentioned earlier, when a company has invested in B2C infrastructure (J2EE, WebLogic, WebSphere, etc.), it already has the needed infrastructure to participate in XML communication. SOAP implementations are readily available for all J2EE Web servers. These solutions allow you to immediately converse with the outside world using XML. When a proper Java architecture is chosen to develop your HTML pages, it if fairly easy to use the same architecture to develop XML messages in place of HTML. Technologies such as Transparent Data Pipelines can be readily used (with no changes) to serve the same HTML data as XML data.

A Simplified Solution for EAI That Doesn't Cost Millions

No one can deny the immense value provided by the EAI programming suites, the cost of which may run into a few million dollars. At their core, these programming suites consist of:

• The ability to securely receive data from anywhere (SAP, Databases, email, fax).
• The ability to use store/forward messages queues.
• The ability to define business processes graphically.
• The ability to transform standard messages (such as EDI).

But often the solutions offered by SOAP sitting on top of your favorite Web server can more than adequately solve the inter- company communication problem. Here are the components of such a simplified solution:

• Clients send XML messages using SOAP to your Web server.
• Your Web server consumes the incoming XML messages in a transactionally-secure manner using EJBs.
• Your Java application server generates an XML reply from your data sources and sends it to the awaiting client.
• For long-running messages, one can adapt Asynchronous SOAP options.
• SSL will be used for security.
• Web server-based authentication, authorization, and session management will be used for tracking users.
• All of the XML messages will be identified; the following will be defined:
• UML declares the structure of the message.
• XSD defines the data structure of the message.
• XML messages will be declared into services using WSDL.
• WSDL will be used to register the services in a public UDDI.
• An EAI solution can be used to convert non-SOAP messages to SOAP messages.