Web Services Architect : Articles : E-Logistics Framework
Web Services Architect

Register for e-mail updates:

 

E-Logistics Processes Integration Framework

ELPIF and Web Services

Liang-Jie Zhang and Henry Chang

Printer-friendly HTML version
Or purchase the extended PDF version of this article from our download site, or from Amazon.com.

In recognition of the increasing importance of globalization and the resulting need for greater, faster, and more flexible communications, a framework is required to allow any company to establish itself in no time or make optimum use of their legacy applications and run efficiently with minimal cost input. This article briefly presents such a framework called ELPIF (E-Logistics Processes Integration Framework) for e-logistics processes integration based on Web Services via incorporating (1) common alliance interface, (2) adaptation layer, and (3) dynamic data binding mechanism. This framework can be adopted as a new service delivery model that uses a design pattern, business process inheritance, and solution templates.

In the last couple of years, various on-line shipping tools have been developed for e-commerce application developers. Take the example of the transportation industry; United Parcel Service of America (UPS) provides several on-line XML Tools and HTML Tools (UPS On-line E-Commerce Tools, http://www.ec.ups.com/), and Federal Express (FedEx) provides in-house Web tools (FedEx API, http://www.fedex.com/) for developers in order to facilitate the development of on-line shipping tools. We have not, however, seen a common service interface to allow users to easily hook up with existing tools. The developers of client applications usually are forced to construct by hand multiple requests for different backend servers requiring a great deal of time and effort, although integration software vendors have been addressing this issue for years. Different shipping carriers might require distinctive implementations and could have proprietary platforms and their own constraints.

In order to expedite the shipping process and minimize costs, the shipping solutions provided by a value-added service provider specializing in the transportation industry must empower the customers and suppliers with the ability to rate, ship, and track shipments. Many solutions in today's competitive market have been able to achieve the above goals but they still have some deficiencies:

  • Most of them are platform-dependent and unique to a specific shipping carrier. Since these shipping solutions are not generic, they could not be considered as a candidate for standards that can be followed by the rest of the players in the industry.
  • Because most Windows-based applications are standalone applications, users have no choice but to purchase or evaluate them before actually using them. Moreover, Web-based solutions are distributed over the Internet, implemented as servlets or CGIs. The interfaces for integration are not suitable for advertising and data exchange.

With the development of Web Services, it becomes technically feasible to define a uniform interface for the solution developers, which leads to potential business opportunities for technology vendors, service provides, and solution software providers. The framework, ELPIF, discussed in this article proposes to have a common generic interface for all the shipping service providers, allowing all providers to build their Web Services on such a standard interface and then deploy those services in the Universal Description, Discovery and Integration (UDDI) Registries for other companies to find and use them. Note that the common generic interface may cover all the possible services provided by the shipping industry. Only some of them will be implemented or provided by a shipping carrier. Though we are focused on the shipping industry, the principles embodied in ELPIF can be applied to other domains.

Blending Web Services and the dynamic XML data binding mechanism approach will lead the future shipping services to a model of what could be considered a generic shipping service. This is critical since it allows a shipping service client to design and deploy code to use the generic shipping model, and then at run time use a dynamic data binding mechanism to invoke a specific implementation of a shipping service. Because Web Services can be implemented in any programming language, developers are not obliged to change their development environments in order to generate or use Web Services. If the shipping service carriers have their own special services that differentiate themselves from others, we also recommend them to publish their service interfaces, either to the UDDI Registry or using Web Services Inspection Language (WSIL) documents, so that their e-logistics expertise can be made available to e-commerce sites and e-marketplaces as cost-effective services. At this point, the common interface for the shipping industry could be extended to encapsulate these new services. Consequently, any client application can benefit from the characteristic of architectural independence that is embraced in our framework and other people's work on Web Services based application integration.

For most integration architecture, XML plays a role of trivializing the exchange of business data among companies by providing a cross-platform approach in the areas of data encoding and data formatting. For example, Simple Object Access Protocol (SOAP), built on XML, defines a simple way to package information for exchange across system boundaries. UDDI Registries, on the other hand, allow programmable elements to be located in a central repository or on Web Sites, which others can access remotely. By adopting the above technologies, not only do we get interoperability for our customers but also we can use our multi-platform approach to provide better offerings and solutions with the help of which any industry can accomplish their transactions efficiently and profitably.

ELPIF serves as a Web Services model such that any user could easily access the services provided by ELPIF through a standard protocol, SOAP. ELPIF helps shipping businesses act more quickly and more efficiently, and it also provides a methodology of automating process integration resulting in reduced integration time and cost, increased efficiency of service delivery, and competitive advantage in the marketplace.

E-Logistics Processes Integration

E-Logistics Processes

When it comes to logistics, the challenge has always been how to deliver products to customers as quickly and safely as possible. Logistics is concerned with the flow of materials in the supply chain, from source through the industrial process to the customer, and then on to re-use, re-cycle, or disposal. By coordinating all resources, logistics have to ensure that service level agreements with customers are honored. Efficient logistics can result in cost savings, which can be passed on to the customer, often resulting in increased business.

E-logistics is defined to be the mechanism of automating the logistics processes and providing an integrated, end-to-end fulfillment and supply chain management service to the players of logistics processes. Those logistics processes that are automated by e-logistics provide supply chain visibility and can be part of existing e-commerce or workflow systems in an enterprise.

The typical e-logistics processes include Request For Quotes (RFQ), Shipping, and Tracking. As shown in the following diagram, e-Logistics interacts with the business process manager in an e-commerce server such as B2B (business to business) or B2C (business to consumer) server.



The business process manager invokes the RFQ process to get the basic services such as obtaining the quotes in an e-logistics process. Whenever a response is obtained, the purchase order (PO) will be updated. The shipping process is also invoked by the business process manager and will update the corresponding PO upon completion. Along with the shipment of goods, a tracking number will be given to the customer and that tracking number will be bound to the PO number in the processing e-commerce system. Customers can track their shipment with the help of that number. The interaction diagram of e-logistics and business process manager shown above represents the high-level view of ELPIF. It is worth noting at this stage that although FedEx and Airborne are both webMethods customers, the ELPIF presented in this article is a framework, not a single service. Thus, value-added service providers who adopt ELPIF could work with FedEx, Airborne, or other shipping service providers.

ELPIF Components and Services

There are three main components and services in the ELPIF under discussion:

  • The Common Alliance Interface, a higher-level service interface that encapsulates the clients from multiple transportation carriers and provides an abstraction layer for available services. The published Web Services communicate directly with the shipping companies' legacy applications using the adaptation layer and dynamic data binding mechanisms introduced in this article. All shipping carriers interested in integrating with ELPIF should implement the Common Alliance Interface, and the resulting Web Services are published in the UDDI Registry so that trading partners and customers can search and retrieve those services.
  • The Adaptation Layer, a key connector between the Web Services and corresponding legacy applications in an industry. The adaptation layer works as a service dispatching broker and service aggregation broker, responsible for manipulating the requests from the user and the responses from the server.
  • Dynamic Data Binding, a function performed by the adaptation layer. The adaptation layer is used to create a connection template while the dynamic data binding mechanism integrates real-time data into the defined connection template.

ELPIF Architecture

The ELPIF backend architecture in the following diagram shows the interaction between different layers. The Web Services of different shipping service providers provide implementations of the methods that are defined in the Common Alliance Interface. The user finds the appropriate service with the assistance of the UDDI Registry and sends its XML-based service request to invoke a service. The request is then sent to the appropriate shipping service provider (SSP) server and the response (an XML String) is sent back to the requestor by the adaptation layer and Web Services Layer.



Conclusion

ELPIF exploits Web Services as the building blocks that distinguish it from other existing integration solutions, most of which are either standalone applications or hard-wired with existing platforms. Hence, we argue that ELPIF contributes to the area of business process integration by providing a new service delivery model using a design pattern and solution templates, for the shipping industry in particular and whole industry that demands business integration in general.

This article is an extract from Web Services Business Strategies and Architectures. Buy the book from Amazon.com

Or purchase the extended PDF version of this article from:
our download site
Amazon.com

Adobe Acrobat format (PDF) - 132K
12 pages
Price: $20

Dr. Liang-Jie Zhang is a Research Staff Member at IBM's T.J. Watson Research Center, where he has been actively working on B2B integration using Web Services. He is the lead author of Business Explorer for Web Services (BE4WS). His other research interests include Web services-oriented business process outsourcing technologies and broadband-media commerce.
Dr. Henry Chang is a research manager for B2B service infrastructure at IBM's T.J. Watson Research Center. He has developed IBM's B2B extranet Web portal, and is now leading research in the areas of Web business services integration, business process solution management , and on-demand e-utility hosting infrastructure.

Printer-friendly HTML version

Keep up to date with all the new articles and features on Web Services Architect:
Register for e-mail updates


How useful is this article?
What's wrong and right about it?
What are your suggestions for taking it further?
Your views keep Web Services Architect focused.

E-mail us at feedback@WebServicesArchitect.com, or complete this form.
Note: fields marked * are compulsory.

Comments *:

E-mail *:

Job title:

First name:

Last name:

Allow Web Services Architect to display all or part of this message in an online forum.
I have read and agree to the terms and conditions.