Printer Friendly

Integrating inter- and extra-enterprise applications using Web Services.


The fast-paced advancement of information technology is rapidly changing the business world. Fulfilling on-demand service requests is vital to today's business survival. Enterprises must incessantly upgrade and integrate their e-infrastructures in order to maintain their competitive advantage. One major roadblock to integration is that there is usually an inherent heterogeneity of system platforms and software applications existing within the same enterprise and among collaborative partners. Thus, it is common that enterprises must spend an astronomical amount of time and money to link the new and legacy systems in order to exchange data, information and knowledge.

The recent development of Web Services has greatly improved information-sharing and -exchange. Simply stated, Web Services use XML-related technologies such as SOAP as the communication protocol; WSDL as the interface description language; and UDDI for registering and searching services. In this paper, we establish an integration framework to develop web-services-enabled enterprise applications utilizing the UML tools. To achieve the desired integration, a uniformly integrated user interface will be designed and developed. Under the proposed framework, heterogeneous systems and applications across different networks can exchange and share data with a minimal need to add or change the existing hardware or software. Lastly, a completed case study [12] of the presented integration framework is briefly illustrated.


In facing increasingly competitive markets due to the globalization of business, business enterprises are required to unceasingly adjust to new challenges and transform themselves. Since the inception of computers, the computerization of business organizations has itself gone through a sequence of transformations due to the rapid development in information technology and increasingly complex business needs. The continuous e-revolution of business processes has encountered a number of challenging technological issues, but none more critical than the incompatibility and importability which currently exist between information systems and applications.

Historically, the inherent heterogeneity of system platforms that exist within the same enterprise and among business partners (e.g., suppliers, distributors and customers), has been a major obstacle to the smooth and timely flow of data and information required to successfully support business operations or processes. More importantly, there exists another serious incompatibility issue among software applications. "The reason is because historically most applications have not been designed for interoperability with other applications. Even when running on the same hardware platform and using the same database, different formats and implementation of business logic makes exchanging information difficult without custom built Application Program Interfaces (APIs). What's more, these applications were not designed for the web" [11]. Clearly, there is an urgent need to create an integration backbone to support all or most of the enterprise applications and data across different platforms and the World Wide Web.

Enterprise Application Integration (EAI)

Usually, an enterprise has existing legacy systems, applications and databases and wants to continue to use them. One solution to address the incompatibility issue is the emergence of the Enterprise Application Integration (EAI) concept and its related products. The essential concept of EAI is to integrate enterprise applications and resources so that they can easily access or share business processes and exchange data. EAI's goal is to integrate the business processes, applications and data sources. This is expected to be achieved without incurring heavy-toll changes to the existing applications and the data.

Linthicum [4] states that "... Enterprise Application Integration (EAI) offers a solution to this increasingly urgent business need. It encompasses technologies that enable business processes and data to speak to one another across applications, integrating many individual systems into a seamless whole." "EAI solutions are software products that completely or partially automate the process of enabling custom-built and/or packaged business applications to exchange business-level information in formats and contexts that each understands" [5]. The key to achieve the EAI goal is to create a "middleware" platform that links to the internal and external legacy systems through adding or migrating to a new set of applications that use the Internet, World Wide Web, intranet, extranet and other related new technologies.

Certain benefits of implementing EAI:

* EAI dramatically reduces effort, time and cost of system maintenance.

* EAI leverages all existing legacy applications and systems by exploiting the infrastructure of the World Wide Web and Internet to reduce the efforts of application recoding.

* EAI provides a single, open architecture that is scalable, non-invasive and operates across environments, connecting databases, warehouses, packaged software and custom legacy systems.

* EAI increases efficiency--key and routine processes are automated.

* EAI adds flexibility to the reconfiguration of enterprise organizations and processes when reflecting changes in the business environment and strategies.

The growth of EAI spending is increasing sharply; $500 million and $900 million were spent on EAI tools in 1999 and 2000, respectively. IT analysts predict that by 2005, companies will spend $7.3 billion on EAI.

The adoption and implementation of EAI can streamline data flows. The entire enterprise can enjoy quick and easy access to consistent, valuable information. Less programming effort is needed to create interface among systems due to EAI's process- and business-driven approach to linking various applications. Data and information channels are integrated to provide a unified view of business processes among customers, suppliers and vendors along the entire supply chain.

Unfortunately, EAI tools have many shortcomings and potential pitfalls. Pender [6] points out that "Before implementing EAI, CIOs must first be prepared to deal with the technology's potential problems: cost overruns, poor interface design and the inability to provide full system integration, among others." In addition, there are other severe EAI technology shortcomings such as the lack of open standards, difficulty in supporting many-to-many connections and limited ability for business process integration. Component-based programming plays the key role in the installation of EAI. Most software vendors often communicate distributed components within a system via a proprietary protocol, and the protocol is usually connection-oriented. Well-known distributed technologies using proprietary protocol are DCOM (Microsoft's Distributed Component Object Model), CORBA and Java RMI. However, because of the limitations of existing technologies in facilitating communication between heterogeneous computer systems, software vendors have often resorted to building their own infrastructure. This means resources and efforts that could have been applied to add improved functionality of components or services have instead been devoted to writing proprietary network protocols or creating new interfaces.

Clearly, EAI technologies are not the final answer to the challenges of integration issues. To remediate the shortcomings encountered implementing EAI, we created an integration platform using the new and promising Web Services technology. The project has been carried out with the aid of popular UML tools, where the UML (Unified Modeling Language) is a standard language for specifying, visualizing, constructing and documenting the artifacts of software systems, as well as for business modeling and other non-software systems [3]. The integration platform is designed by taking full advantage of the cross-platform feature of Web Services technology that standardizes communication, description and discovery mechanisms. The platform allows us to dynamically integrate and distribute service components of the enterprise across the Internet through the simple creation of a user interface.

A Brief Discussion on Core Technologies Involved

Client/Server Computing and Distributed Object Technology

Developments in client/server computing since the 1980s have been helping to improve business information processing in the last 20 years. A client is a computer that requests services, and a server is defined as the computer that provides services. The client/server architecture has been created as a versatile, message-based and modular infrastructure that is intended to improve usability, flexibility, interoperability and scalability of computing as contrasted to centralized, mainframe, time sharing computing. However, as the volume of data and information flowing among enterprises increases explosively, the traditional client/server structure becomes hard pressed to keep up with complicated requests, and it is also more difficult to enlarge and maintain.

Distributed Object Technology has been introduced to alleviate some of the aforementioned client/server difficulties. The distributed object technology places a middleware between clients and servers. The middleware serves as a mediation point between applications, and provides generic interfaces with which all integrated applications pass messages to each other. Distributed Object Technology hence provides the communications channel that enables plug-and-play interoperation of distributed components across diverse networks and operating systems, allowing them to be easily assembled, reused and managed.

However, distributed object technology usually encounters a number of serious obstacles when applied on the Internet.

a) It is difficult to penetrate the firewalls.

Under TCP/IP, every frequently used protocol is given a port number, and every request packet using the specific protocol is attached with the same port number. Firewalls will usually block most other ports from access due to security reasons. This is the main cause that renders the distributed object technology impotent. Usually, the protocol of the distributed object technology is dynamically assigned a port number when there is a request for it. If no firewall exists between the server and the client, then the distributed object technology can be effectively utilized on the network. However, with the enactment of a firewall, the connection of the two communication endpoints using the protocol will be disrupted, because the firewall disallows the arbitrary assignment of port numbers.

b) The communication connection must be tightly coupled. Coupling implies the dependency between interactive systems or application components. Tightly coupled components tend to make maintenance and reuse much more difficult because a change in one component automatically means changes in others. For example, it will be difficult to keep the unified structure of the computing platform using the tight coupling scheme when a merger or acquisition between enterprises occurs.

c) It is difficult to integrate application programs.

The major obstacle to the smooth flow of data and information is due to the heterogeneity of IT products inherently existing within the same enterprise and among supply chain partners: suppliers, distributors and customers. The enormous variety of designs and technical specifications in products has made the integration of application components, especially over a network, a formidable task. Some of the challenges to applications integration include the methods of transport, specifications of call procedures and formats of messages.

Web Services Technology

What are Web Services? As it happens in many emerging technologies, it is not easy to provide an exact, concise definition for Web Services. A simple Google web search on the definition of Web Services yields a large number of them, and each places different emphasis on certain distinct characteristics. We list three of them here that roughly complement one another.

* Web Services are a modular collection of web-protocol based applications that can be mixed and matched to provide business functionality through an internet connection. Web Services use standard Internet protocols such as HTTP, XML and SOAP to provide connectivity and interoperability between companies [1].

* A Web Service is a component that runs on a Web server and allows client programs to call its methods over HTTP. Each method on the component appears as a URL and may return data (perhaps an XML document) and accept parameters. This technology is based on the open SOAP specification, so now our server-side components can be available to virtually any client, regardless of language or platform [2].

* A Web Service is an application or business logic that is accessible using standard Internet protocols. Web Services combine the best aspects of component-based development and the World Wide Web. Like components, Web Services represent black-box functionality that can be used and reused without regard to how the service is implemented [13].

In a nutshell, Web Services use the World Wide Web as the gigantic platform for computing, so that all the service (or components) requests and fulfillments will be carried out on the platform by simply shifting the messages exchanging activities from a low layer of communications infrastructure to a higher layer that performs program logic.

As described by Short [7], Web Services encompass: Discovery, Description, Message Format, Encoding and Transport. For background information, the roles of the five building blocks are briefly discussed below.

Whenever the client application wants to access certain functionality exposed by a Web Service, the Discovery process finds the location of the remote Web Service. Discovery can be facilitated via a centralized directory such as the increasingly popular UDDI (Universal Description, Discovery and Integration Service). The infrastructure that supports UDDI is composed of a set of registries and registrars, where a registry contains a full copy of the UDDI directory and a registrar provides UDDI registration services on behalf of a customer.

Once the location for the requested Web service has been identified, the client needs clear information and instructions to properly interact with it. The description of a Web service includes providing a way for service providers to describe the basic format of Web service requests over different protocols or encodings, structured metadata about the interface that is intended to be consumed by a client application, as well as written documentation about the Web service, including examples of use. The key technology for the Description phase is WSDL (Web Services Definition Language). Simply stated, WSDL is used to describe what a web service can do, where it resides and how to invoke it.

In order to exchange data, a client and a server have to agree on a common way to encode and format the messages. SOAP (Simple Object Access Protocol) has been introduced as a standard way of formatting the messages. It is a protocol specification that defines a uniform way of passing XML-encoded data. And it also defines a way to perform RPCs (remote procedure calls) using the popular HTTP as the underlying communication protocol.

The data transmitted between the client and the server needs to be encoded into the body of the message. The popular choice for Web Services encoding is XML (eXtensible Markup Language) because XML offers many advantages, including cross-platform support, a common type system and support for industry-standard character sets.

Once the message has been formatted and the data has been included into the body of the message, the message must be transferred between the client and the server over some transport protocol. Key WWW protocols are HTTP and SMTP. HTTP-based Web applications are inherently stateless and they do not rely on a continuous connection between the client and the server. SMTP defines a routable messaging protocol for asynchronous communication. If SMTP service is disrupted, the e-mail infrastructure automatically handles retries.

In summary, the critical factor that allows Web Services to transfer data and execute instructions across heterogeneous platforms and over the Internet is the universal acceptance of adopting a simple unified format to describe data by the IT industry. The adoption of open programming standards such as XML, SOAP [9], WSDL [10] and UDDI [8] enables Web Services to dynamically publish, search and execute the services they provide. The key operations of a Web Service include Description, Publish, Find and Bind, and they are depicted in Exhibit 1.


1. Service Provider

A service provider supplies Web Services including business and other functionality to requesters. The key to the Web Services is the WSDL documents. The services of Web service providers are described by WSDL documents containing descriptions of required inputs and resulted outputs, as well as the URLs of the documents that allow requesters access. The WSDL documents are published on the UDDI service registries.

2. Service Requester

Using SOAP as a message protocol, the service requester sends the inquiry strings to UDDI trying to obtain a response. At the return of a response, the requester fills out the required data and then activates the URL of the requested service.

3. Service Registry

Service Providers publish their services on the Service Registries and requesters find the needed services from the Service Registries. The Service Registry databases are specified by UDDI where UDDI is a specification for maintaining standardized directories of information about Web Services, recording their capabilities, location and requirements in a universally recognized format.

Major Benefits of Web Services

* Easy to penetrate firewalls

SOAP, as a communications protocol, is similar to DCOM, CORBA and other distributed objects communications protocols in that it allows clients (or service requesters) to communicate with the RPCs of remote servers. However, DCOM and CORBA are proprietary protocols and their objects usually are forbidden to penetrate firewalls, while SOAP is an open standard and supports the exchange of messages across firewalls. SOAP can be accessed by almost any software objects. Therefore, SOAP can serve as a bridge between the two major camps, DCOM and CORBA, by allowing the objects created in both camps to communicate with each other over the Internet platform. Almost all firewalls keep their port numbered 80 open for communications purposes. Note that the port number for HTTP is also 80. Since the protocol of SOAP objects is founded on top of HTTP protocol, SOAP objects can penetrate freely across firewalls.

* Loosely coupled

Since the communications capability of SOAP is hinged on HTTP, SOAP, by nature, is also a stateless protocol. In other words, SOAP enjoys the flexibility of a loosely coupled communications protocol. This means the applications can continue to work even if the connection at the sending or receiving end is changed.

* Easy to integrate across computing platforms

Web Services are message-based and effectively utilize popular communications protocols such as HTTP and SMTP. The incorporation of XML (Extensible Markup Language) with the three key technologies--SOAP, WSDL and UDDI--has allowed us to create XML-based Web Services objects and to leverage Internet-based protocols. The XML-based Web Services objects created are similar to any software objects in that they are also programmable and re-usable. The difference is that the XML-based objects can be accessed, activated and distributed from any entry point of the Internet to invoke services and obtain needed information. XML-based Web Services as a new tool has the potential to break down the boundaries that exist among custom applications, proprietary software and the Internet; it has introduced hope for enterprises to collaborate on integration of information processing so that clients can access information on any computing platforms, any time, anywhere.

Constructing an Enterprise Application Integration Platform Using a Web Services-Based Architecture

Application Integration Platform Architecture

Enterprise application integration seeks to integrate all heterogeneous software and hardware systems to produce an integrated platform, without requiring major efforts to replace or modify existing databases and programs. For this purpose, we have designed a platform structure that allows application users to simply perform a few clicks on a generated interface to easily obtain the desired cross-platform services.

Our created platform structure, depicted in Exhibit 2, is composed of three parts: Services Side, Client Side and Server Side.


The Services Side includes all of an enterprise's service components and application objects already existing internally and externally. These components and objects are described by WSDL, published on UDDI servers and are made accessible to users via SOAP technology. The Client Side includes server managers, normal (client) users and other computing systems. The Server Side collects and records all the provided services/applications on servers and dynamically generates an integrated interface for users when a service is requested. The requested service can then be called into action according to the mapping between the selected interface item and the actual record of the stored service item.

For our purpose, as shown in Exhibit 3, the application server of the integrated platform is organized into a hierarchy of four layers: the interface layer, the enterprise objects layer, the physical layer and the transport transactions layer.

The Processing Mechanisms of the Proposed Platform Architecture


The processing of the proposed system is sequenced into six mechanisms: the exploring and Web Services record, action record, process record, procedure record, modeling record and interface record mechanisms. Each one of the six mechanisms includes five possible operations: Defining, Saving, Querying, Modifying and Deleting. For example, the "action record" mechanism includes action record defining, action record saving, action record querying, action record modifying and action record deleting operations.

The basic principle is to build sequentially the six mechanisms, starting from recording the characteristics and behavior of the provided Web Services to manipulating the records of action, process, procedure and modeling, and eventually to handling records of interface via a mapping scheme. This will lead to the generation of a user-friendly interface for the integrated platform so that users can easily obtain the desired services via the Web.

Design and Analysis of the System Components

To validate the proposed framework for applications and platform integration discussed in this paper, a case study [12] has been implemented and completed successfully. The study first illustrated the analysis and design of the needed system components: services integration components, message delivery components, procedure agent components, interface mapping components and others. The activities of the identified components were then classified using a three-layered approach: General Classification, Services Integration Classification and Interface Mapping Feedback Classification. In the Uniform Classification, interface templates were created separately for administration interface, agents and information entities. Under both the Services Integration Classification and Interface Mapping Feedback Classification, components were classified into the classes of administration interface, message delivery, agents, information entity and services integration, respectively, and the only difference between the two classifications resides in different calling modes.


The emergence of Web Services technology has made adoption of the Internet as the new computing platform a reality. Web Services use industry standard protocols with universal support to provide a simplified mechanism to connect business applications and to exchange data regardless of locations, technology or platforms. Employing Web Services can lead to many business and technology benefits including delivering platform and technology independence, improving business process efficiency, simplifying the complexity of integration design, reducing the cost of integration and enjoying a wide choice of middleware vendors. In addition, Web Services can remediate the pitfalls of the current implementation of Enterprise Applications Integration (EAI) by adopting the popularly accepted open protocols to standardize processes of communication, description and discovery.

Our proposed integration framework based on Web Services allows IT administrators to employ an interface template to easily integrate intra- and extra-enterprise applications and services without additional coding development effort, and then authorize the developed interface to field or customer users to execute effortlessly their desired requests. Furthermore, the developed framework reduces the impact of change, and response to changes can be automated. The design flexibility of the proposed integration framework leads to broad applicability not restricted to a single information management model; it can help revise or improve business models.

Web Services technology will continue to evolve. We expect that the inclusion of the related growing technologies such as WSEL and BPEL4WS (jointly developed by BEA, IBM and Microsoft) will be easily incorporated into our proposed integration framework.


1. AZTEC glossary, 2004. Accessed online on (date: December 26, 2004)

2. DevX.Com, Jupitermedia Corp. Accessed online on (date: December 26, 2004)

3. Eriksson, H.-E., M. Penker, B. Lyons, and D. Fado, UML 2 Toolkit, Indianapolis, Indiana: OMG Press, Wiley Publishing, Inc., 2004.

4. Linthicum, D.S. Enterprise Application Integration, Boston, Massachusetts: Addison Wesley, 1999.

5. Ovum Evaluates: What is Enterprise Application Integration? 2001. Accessed online on (date: June 14, 2003)

6. Pender, L. "Damned if You Do ... --Will integration tools patch the holes left by an unsatisfactory ERP implementation?" CIO Magazine, September 15, 2000. Accessed online on (date: May 15, 2005)

7. Short S. Build Web Services for the Microsoft.NET Platform. Redmond, Washington, Microsoft Press, 2002.

8. UDDI, UDDI Specification, ver. 3, 2005. Accessed online on (date: May 15, 2005)

9. W3C, SOAP Specification, 2003. Accessed online on (date: May 15, 2005)

10. W3C, WSDL Specification, 2001. Accessed online on (date: May 15, 2005)

11. WRQ Verastream Whitepaper, Integrating your Legacy Hosts: A Critical Step for B2B'S Success, 2001. Accessed online on (date: Dec 14, 2002)

12. Yang, H.M., F.V. Lu, S.Q. Huang, and C.B. Wang. Development of Web-Services Based Enterprise Application: An Integration Framework. A Completed Working Paper, November 2004.

13. ZEROONESOFTWARE Glossary 2004. Accessed online on (date: December 26, 2004)

Hui-Mei Yang, Tatung Institute of Commerce and Technology

FangLieh Victor Lu, The Peter J. Tobin College of Business, St. John's University
COPYRIGHT 2005 St. John's University, College of Business Administration
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2005 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Author:Yang, Hui-Mei; Lu, FangLieh Victor
Publication:Review of Business
Geographic Code:1USA
Date:Sep 22, 2005
Previous Article:Special issue: applications of Computer Information Systems and Decision Sciences.
Next Article:Wireless networks and security issues.

Terms of use | Privacy policy | Copyright © 2022 Farlex, Inc. | Feedback | For webmasters |