Feature

EMALL is a procurement portal for the U.S. Department of Defense. Defense and federal personnel use it to shop for items ranging from office supplies and equipment to weapons systems. The personnel have various levels of privileges to access classified catalogs and place orders.

They create "shopping carts" and submit their orders through a Web application. EMALL processes these orders via a rule engine with complex validation rules. After validating the orders, it sends requisitions to a supplier's system. Various authorized users can then track these orders.

Hundreds of vendors compete for this business. They have a huge item inventory with several million SKU numbers. Their systems need to be able to accept these requisitions from EMALL, and send the status of the orders back. An order may take anywhere from a few milliseconds to several months to process. EMALL handles classified and sensitive information, and large transactions. It needs to integrate with several systems that are geographically separated and based on a diverse range of distributed architectures and data communication technologies.

Architecture Choice
The EMALL project presented some interesting challenges. We needed a system that:

• Was highly secure, robust. reliable, and scalable
• Integrated sub-systems based on a wide range of technologies
• Handled long-lived transactions with complex paths of execution

In considering these challenges, we identified the following approach:

• Extensive use of XML as the data format between sub-systems
• Use of ebXML over HTTPS protocol as a transport between the sub-systems
• THe total decoupling of the implementations of various sub-systems
• Use of workflow-style asynchronous processing for long-lived transactions
• Use of J2EE for core components of EMALL, including the rule engine
• Use of SOAP, ebXML, and Web services to interact with external systems

The use of ebXML as a mode of communication between EMALL sub-systems was the key to our success. It provides important security and reliability features, including:

• Transport-level security via use of HTTPS
• Message-level security via use of digital signatures for protection against message tampering
• Support for nonrepudiation, including origin of the message as well as receipt of the message
• Reliable messaging by providing "once-and-only-once" quality of service

Choosing BEA WebLogic Platform 8.1
The EMALL project involved a high degree of complexity and stringent security and reliability requirements as well as a very aggressive time frame. The proper technology choice was key to that success. After careful consideration, we chose BEA WebLogic Integration 8.1. Some of the important factors that influenced our choice were:

• BEA WebLogic Integration 8.1 is built on BEA WebLogic Server/J2EE technology, which has proven to be highly stable, scalable, and secure.
• It supports long-lived business processes or workflows.
• It supports the ebXML specification versions 2.0 and 1.0.
• It easily integrates traditional EJB components with business processes and Web services.
• It includes a powerful IDE, BEA WebLogic Workshop, that allows rapid development. Workshop provides an easy-to-use interface, yet builds J2EE-compliant components that are deployed into BEA WebLogic Server.

Let's look at how we leveraged this platform to build EMALL (see Figure 1).

Configuring Trading Partners
BEA WebLogic Integration 8.1 includes a Web-based admin console that allows us to configure the trading-partner relationships for each entity participating in EMALL. The Trading Partner Profile includes the identity of the business entity, digital certificates associated with that entity, and ebXML bindings supported by that entity. The ebXML bindings include delivery semantics (e.g., once-and-only-once), a transport protocol (e.g., HTTPS), and URL end-points. These trading partners offer specific services that are defined by service profiles.

In our prototype, we defined three trading partners:

• WEB_UI: Represents the Microsoft .NET Web application used by the end users to submit and track orders.
• ICF: Validates the orders and sends requisitions to the vendors. This rule engine was developed using BEA WebLogic Platform 8.1. We created an "Application" icfApp in Workshop to represent this functionality.
• VENDOR: Represents one of the vendors that participate in EMALL.

Developing ebXML Participant Processes/Workflows
In the icfApp, we created a "Project" icfAppWeb. For each service offered by the ICF entity to other trading partners, we created one ebXML participant process. BEA WebLogic Workshop allows us to develop business processes that can be invoked by external trading-partner entities via ebXML messages. Workshop generates all the required transport-level components for handling the ebXML protocol. The developer needs to worry about only the application data. Workshop allows us to define the input and output of each business process. It creates a Java file with additional annotations (with a .JPD extension), for each process. Developers can put any business logic in the JPD, including calling EJBs, sending messages to MB-Broker channels or JMS destinations, invoking subprocesses, etc. When we build the application in Workshop, it creates the transport-layer components, such as servlets, that accept the HTTPS requests, handle the ebXML headers, extract the application data from the ebXML requests, and hand it over to the developer's code. The output of the JPD (the return value) is packaged into ebXML responses and returned to the caller by the transport-layer.

The WEB_UI application, which is based on Microsoft .NET technology, can invoke the ebXML participant JPD processes through the ebXML bindings defined in the trading-partner configuration.

WebLogic Workshop also allows us to create other processes, including those that can be invoked by sending messages on a channel, or via the Web services stack. We can also call one process from another, using the process control. The real implementation of "acceptCart.jpd" involves complex business logic, including XML data manipulation, rule-based validation, exception handling, and so on. Various tasks related to this JPD are performed synchronously or asynchronously as necessary. WebLogic Workshop allows us to create a process or workflow in the design-view of the JPD, define transactions, and implement complex business logic easily.

Using ebXML Controls
The business processes running on the ICF system also need to invoke ebXML services deployed on other trading partners. WebLogic Workshop allows us to use ebXML controls within the JPD files. The ebXML control is a Java interface generated by Workshop. This interface has methods that match the ebXML service provided by the remote trading partner service. The actual implementation class is generated by Workshop when you build the application. Therefore, the developer does not need to deal with the ebXML protocol stack and just calls the remote service via this interface. The ICF application invokes services from the VENDOR application through this mechanism. In our prototype, we simulated the VENDOR application through Business-Connect 8.1, a lightweight, ebXML-enabled server from BEA.

Handling XML Data
The WEB_UI application sends a shopping cart in the form of XML to the ebXML process in the ICF application. We created an XML Schema file using the XMLSpy tool bundled with WebLogic Platform. We then imported this Schema (XSD file) into the ICF Application. The WebLogic Workshop IDE generates Java classes that represent the XML types. Each class has get/set methods and Factory methods to parse Java strings, files, etc., into XML objects. These classes are available in the code for JPD files. We can define these types as input arguments or return values for the process. We then extract the fields from an XML type, or transform them into another XML type using the XQuery API. WebLogic Workshop provides an easy-to-use GUI interface for creating and editing XQuery expressions - available as Transformation Control methods. This allows us to develop applications quickly, without writing any low-level code.

Integrating EJBs into Workflows/Processes
Through WebLogic Workshop, we can create EJB controls that invoke the EJBs. The process is very straightforward.

We just deploy the EJB to the WebLogic Server hosting our WebLogic Integration application, and start the server. Then we can select these EJBs from Workshop and create EJB controls. The EJB control is an interface that wraps the methods of the EJB remote and home interfaces. We just call the methods from within the JPD. Workshop creates the implementation classes that perform low-level tasks such as JNDI lookups.

End-to-End Testing
The BEA WebLogic Workshop IDE allowed us to rapidly develop the application, deploy it on the WebLogic Server, and then test our code. A test browser integrated within the IDE invokes a particular JPD through the Web services stack, allowing us to see and debug our code. We can also copy the URL from the test browser and test our JPD file through a standard browser such as Internet Explorer. Workshop tightly integrates the compilation, deployment, redeployment, and execution in a simple, intuitive manner.

Conclusion
BEA WebLogic Platform 8.1 allowed us to build a mission-critical application with stringent security needs in about three weeks. This platform supports ebXML standards, with important features such as message-level security, transport-security, and guaranteied delivery. Using this framework, we integrated a Microsoft .NET application with J2EE applications.

Acknowledgements
We want to gratefully acknowledge the support of Dr. Bill Freeman, director of research and development for the Integrated Solutions Group of the South Carolina Research Authority. Dr. Freeman is also the project manager for SCRA's work on the DOD EMALL. BEA and ICF provide engineering services to SCRA.

We also want to thank Ricardo Valenzuela, Madhavan Rangarao, Dmitry Dimov, and Komal Mangtani from the BEA Engineering team, who provided technical support to achieve our goals.