B2B Integration Web Services Whitepaper

A Service-Oriented Approach to B2B Integration using Web Services
White Paper By Saumil Gandhi
Published for DREAMSCAPE MEDIA
TABLE OF CONTENTS
ABSTRACT....................................................................................................................... 3 INTRODUCTION............................................................................................................. 3 STATEMENT OF PROBLEM........................................................................................ 5 SIGNIFICANCE OF THE PROBLEM.......................................................................... 6 PURPOSE OF THE STUDY ........................................................................................... 8 REVIEW OF LITERATURE.......................................................................................... 9 Literature Review Methodology.................................................................................. 9 Resources .................................................................................................................. 10 Important keywords used.......................................................................................... 11 Literature Findings..................................................................................................... 12 Issues with existing business integration approaches ............................................... 12 A service (component) oriented approach to developing middleware ..................... 14 Web services for enterprise integration .................................................................... 16 Strengths and Weaknesses ......................................................................................... 18 Definition of Terms ..................................................................................................... 18 Delimitations................................................................................................................ 23 Assumptions................................................................................................................. 24 Limitations................................................................................................................... 25 PROCEDURES ............................................................................................................... 25 Analyses........................................................................................................................ 28 FINDINGS AND DISCUSSIONS.................................................................................. 29 Evolution of B2B Integration Solutions .................................................................... 29 The service of web services - Service-oriented Architecture (SOA) ....................... 32 Benefits of the Service-oriented Architecture for B2B Integration........................... 36 The web of web services enabling the SOA for B2B Integration......................... 37 Basic Layers of the Web Service Stack .................................................................... 38 Benefits of web services for B2B Integration............................................................ 40 Web service workflow for B2B integration............................................................... 42
Deploying web services the .NET platform ........................................................... 44 Proof-of-concept a web service for credit card validation using .NET............... 46 Prototype Overview .................................................................................................. 47 Credit Card Validation Web Service ........................................................................ 47 Client Applications ................................................................................................... 49 Findings from the proof-of-concept .......................................................................... 50 A web service approach for B2B integration ........................................................... 51 RECOMMENDATIONS FOR FURTHER STUDY ................................................... 54 CONCLUSION ............................................................................................................... 55 REFERENCES................................................................................................................ 59 APPENDIX A .................................................................................................................. 64 creditCardValidatorvb.asmx ..................................................................................... 64 Web Service Description Language for creditCardValidator service ................... 65 APPENDIX B - J2EE client files ................................................................................... 69 input.jsp ....................................................................................................................... 69 JSP result page Result.jsp ....................................................................................... 70 Java proxy class for the web service creditcardvalidatorvbProxy.java ............. 76 Java classes for Soap request object.......................................................................... 79 Java class for SOAP response object ........................................................................ 80 APPENDIX C - .NET client ........................................................................................... 82 VB.NET form page ..................................................................................................... 82 The .NET proxy class.................................................................................................. 84
ABSTRACT The goal of this study is to propose the usage of a web-based architecture to interconnect information systems between enterprises. Business-to-business integration has become a critical issue as organizations find a greater need to consistently interact with new partners in a global business environment. Some of the problems faced with earlier integration approaches include scalability, cost of deployment, flexibility and speed of deployment. The concept of a service-oriented architecture was applied to the web-based model for B2B integration to help overcome these problems. The author examined design-level and implementation-level issues in deploying such a web-based model between enterprises. Microsoft Corporations .NET framework was used to demonstrate the implementation of a model system for B2B integration. A Proof-ofConcept was be developed for this purpose, and tested in a simulated test environment to prove the utility of web services. This prototype simulated an online payment functionality encapsulated within a web service.
INTRODUCTION Given the degree of interaction that businesses and organizations have along the value chain of any industry today, it is critical that these enterprises be able to share information in a fast, inexpensive, scalable and dynamic way. As stated by Brown, Durschlag and Hagel, (2002) "The power lies in the ability to make the systems of trading partners interact." This understanding has made organizations rethink the way they look at managing their business processes. Hagel (2002) observes that making connections between
companies and their applications is highly complex. Traditionally, companies believed in tightly integrating the processes involved in producing and delivering products or services, not only within the organization, but across corporate boundaries as well. Hagel shares two of the biggest drawbacks of doing this. First, these process chains are highly inflexible because of their close coupling. Second, problems with their suppliers or manufacturers can be critical and harmful. To address these concerns, a lightweight coupling architecture and a corresponding communication platform are needed to allow quick and flexible business process integration across enterprise boundaries. Organizations could use a framework that allows them to look at their processes as process networks rather than production lines (Brown et al, 2002). The term process network implies a more loosely-coupled view of business processes, where processes are not tied closely together, and are relatively independent of each other. With flexible process networks laying the foundation for business collaboration, organizations can focus on innovation in its core activities, making these networks more efficient and flexible. A service-oriented approach supports such a concept, and web services, which allow services to be offered by specific protocols and communicate over the Internet provide a distributed computing infrastructure for both intra-and cross-enterprise application integration and collaboration (Papazoglou and Georgakopolous, 2003).
STATEMENT OF PROBLEM A major problem in business-to-business integration is that organizations did not necessarily agree upon a common communication platform, which constrained the speed and cost with which key relationships could be established. Medjahed, Boualem, Bouguettya, Ngu and Elmagarid (2003) mention that initially, technologies like EDI (Electronic Data Interchange) were used to meet the demand of business-to-business (B2B) integration. However, as relationships between organizations became more dynamic in nature, scalability became a big factor in EDI-based integration since it led to a very high level of coupling between the interacting systems. This and other factors like cost led to the concept of CORBA (Common Object Request Broker Architecture). CORBA is a distributed framework which contained independently existing components that could be used by more than one application by encapsulating them correctly. Medjahed believes this did not completely resolve scalability issues because it required the interaction of systems to be restrained by the platforms on which the systems were deployed. The above clearly established the need for a common communication platform, making it easy for companies to share information or interact with other companies easily and quickly. This need for a common platform led to the choice of the adoption of the Internet as a communication protocol that all businesses could already access. With the web as a middleware between interacting objects, information systems can easily form new relationships with other systems as long as the middleware uses standard and open protocols that all companies can use and adopt (Stal, 2003). A key requirement in the
deployment of this middleware is to use an appropriate technology that can fully optimize the ubiquitous nature of the web for B2B integration.
SIGNIFICANCE OF THE PROBLEM Two important trends in the business environment today have created the scope for this study: the ubiquitous adoption of e-business and increasing business collaboration the exchange of information stimulated by interacting business processes. The first trend is the widespread adoption of e-business (doing business online), which Freemantle, Weerawarana and Khalaf (2002) identify as the motivation for companies to expose their business process over the Web. E-business led to the portal concept, where a web interface is a one-point entry to the enterprises information systems. This makes the Internet a critical element in the communication channels between businesses and between a business and its customers. The other trend is the need for a business to establish dynamic relationships with key business partners, suppliers or vendors in an effort to provide end-to-end services to their customer. Hagel (2002) believes that the long-term value of business collaboration lies in "mobilizing the assets of partners to deliver more value to their customers." This consequently requires a greater need for the information systems of the interacting organizations to be coupled, yet the coupling should be loose enough to handle the dynamic nature of the relationship. Web services are an alternative that could combine and optimize the benefits of these trends. There are a growing number of organizations that have adopted web
services as an important element in how they do business. Consider the following statistics: In a survey of CTOs in 2001 by InfoWorld magazine, 70% of the CTOs predicted that web services would be most effective in the B2B ecommerce area of their company. Andrews (2003) predicts that by 2006, web services will be a competitive differentiator in business relationships and will be used by businesses to provide partners with information as easily as possible. Gartner Dataquest estimates that the worldwide market for consulting and development and integration services relating to web services integration software was $7.4 billion in 2002 and will reach $14.3 billion by 2006 (Cantara, 2003). According to Varon (2003), in a survey by the Cutter Consortium consultancy of 250 clients, 13% of the clients said that they were using web services for business critical applications since January 2003. 54% of them were developing prototype web services. These figures are indicators of the significance of web services for B2B integrations. Frank Moss, chairman and cofounder of Bowstreet, an enterprise portal provider and a web service user summarizes the significance of web services aptly: "Companies are transitioning from being product providers to becoming service providers. To grow their revenue, enterprises have to provide more and more services around their services products or their existing services. The web services architecture is a natural way to do that" (Knorr, 2001).
PURPOSE OF THE STUDY This study evaluated the implementation of a service-oriented, web-based technology (e.g. web services) as a middleware platform for integrating enterprise information systems within organizations or between organizations using open and scalable standards. It examined the possibility of combining the established and accepted current practice of a service-oriented application development approach to integration with a web-based abstraction at an implementation level using contemporary technologies and platforms. The purpose of this study was to create and deploy web services on the .NET framework to demonstrate how systems on different platforms could be integrated. A prototype web service middleware was created as a Proof-of-Concept (PoC) for this purpose. The web service was deployed using open and scalable standards (XML and SOAP). This ensured that an application or a system could invoke this service independent of that applications deployment platform over the Internet, and demonstrated the utility of such an approach to facilitate B2B integration. By analyzing the interoperability of such an implementation, the study illustrated how a web-based, service-oriented architecture can be used to easily and speedily integrate disparate business systems with minimal cost and effort. It evaluated this integration approach from a service-oriented architecture context and judged it on the basis of parameters like scalability, security, volatility and interoperability. The .NET framework embraces a range of technologies and development platforms, allowing it to be viewed as a universal development platform. By proving its utility in developing web services for the purpose of B2B integration complemented with
component-oriented architecture, the study provided a reference point for future implementations of this nature. The deliverables of this study are: 1. Identification of the parameters for evaluating the service-oriented architecture as a development approach. 2. A proof-of-concept web service. 3. Demonstration of how an application can invoke this web service independent of the deployment platform. 4. Comparison of .NET and J2EE architectures for web services, and the identification of the benefits of using the .NET framework as a deployment platform for web services.
REVIEW OF LITERATURE Literature Review Methodology The literature review is divided into three sections so as to establish the correct context for this study. 1. Issues with existing business integration approaches This reviews the history of B2B integration, and focuses on the problems inherent with some of the current practices like CORBA and EDI. It provides a context and helps to understand the present-day solutions to business integration and how they have evolved to their present form 2. A service (component) oriented approach to developing middleware It is important that web services be viewed within a certain conceptual framework
rather than an individual technology or a standalone idea. This has led to the essential idea behind a successful integration solution a component-based approach to an enterprise integration solution. This section discusses the use of components for creating middleware. It explains how the component model is used in creating a service-oriented architecture for application development. It then proceeds to demonstrate the utility of a service model for creating middleware for business integration. This phase thus examines the design architecture of an integration platform, and suggests how this can be manifested in a web-based implementation. 3. Web services for enterprise integration This section examines how the service-oriented approach is applied over the Internet and manifested as web services. It describes how a web service is better suited for integration over its predecessors, and discusses the use of widely-accepted protocols like XML and SOAP. These are the enabling technology elements that contribute towards making web services a preferred B2B integration solution.
Resources Gartners research database (which it shares with Purdue University) and online magazines like CIO.com and ComputerWorld.com were starting points in most research initiatives. Each of these resources has specific sections related to web services, making the initial research organized and efficient. Gartner is especially useful in this sense. It has a series of cross-linked articles that view web services from a service-oriented architecture perspective, providing greater relevance to this study.
10
Technically more involved and detailed resources were needed to scrutinize the initial cursory research. Industry journals like IEEE and Communications of the ACM are much more theory-oriented and suitable for researching and developing a theoretical foundation. Both have considerable resources which discuss the actual implementation issues and ideas for web services; for solving existing business problems with web services. Online databases like Academic Elite, Master File Premier and Business Source Premiere complemented these resources by providing a more real-word manifestation of the theories and ideas laid out in the aforementioned sources.
Important keywords used 1. Enterprise Resource Planning (ERP) 2. Enterprise Application Integration (EAI) 3. Information systems 4. Cross enterprise integration 5. Business process re-engineering 6. Information flow in enterprises 7. Enterprise information architecture design 8. Web services 9. Service-oriented Architecture (SOA) 10. XML 11. Middleware 12. Web-based integration 13. Component-oriented software
11
14. Component middleware 15. Object-oriented applications 16. Distributed application architecture 17. .NET and J2EE architecture A mix of the above keywords (alone, and in combination with others using the or and and operators) provided a range of articles relevant to the area of interest.
Literature Findings Issues with existing business integration approaches Bill Gates Business @ Speed of Thought (1995) was the first to talk about the idea of an information backbone for an organization, and stress the importance of an enterprise information system. Gartner is an excellent resource in terms of current buzz words related to the topic, and a good predictor of the future of these systems. Comport (2002) provides an especially useful insight into how the view of enterprise systems would make a transition from being rigid, closed systems to open architecture systems using accepted standards. He predicts that through 2007, vendors will shy away from proprietary application architectures and move towards an open enterprise architecture. The primary reason for this shift is that the proprietary application architecture does not allow easy extensions to other systems or applications, since they were not constructed for this purpose. This is a subtle indication of the fact that Comport feels that businesses will need to consider the issue of business integration in designing and developing their information systems, and therefore need to have a strategy that is inherently flexible
12
rather than think of a middleware after creating their systems. This is the very basis for a service-oriented approach. An important study by Medjahed et al (2003) provides a comprehensive analysis of business-to-business integration solutions. The study evaluates popular integration technologies EDI, distributed architecture and XML against factors like coupling, heterogeneity, adaptability, security and scalability. Coupling refers to the degree of tightness and duration of interaction between business partners. Heterogeneity refers to the degree of dissimilarity among business partners, e.g. the difference in data formats across different information systems. Adaptability refers to the degree to which an application is able to adapt to changes. Security refers to issues of authentication, integrity of information, and confidentiality between interacting business partners. Scalability refers to the ability of a system to grow in one or more dimensions such as volume of data, number of transactions, or number of relationships managed at a given time. The study explains how lack of a platform independent middleware has restricted the utility of EDI or CORBA as an integration solution. It also talks about the important platforms and notes Microsoft Corporations .NET as an important deployment platform for future solutions. A more practical illustration of selecting middleware is illustrated in a case study by Mondal and Das Gupta (2000). This case study provides insight into the decisionmaking process involved in selecting a middleware before adopting a web-based integration approach of a legacy system. Factors like cost of deployment, scalability of the system and reusability of the system components are used as evaluation parameters in ruling out CORBA and similar object-oriented approaches.
13
A service (component) oriented approach to developing middleware Crknovic, Hnich, Jonsson and Kiziltan (2002) examine the formal specifications of components and component-based relationships. They elaborated on how components allowed separation of interface from the function, making them important in a distributed application environment. A paper by Levi and Arsanjani (2002) further stressed the benefits of adopting a component-based approach to model business information architecture. Consider the example of a process used to calculate the wages of employees in a company. Traditionally, this would be encapsulated in a function which is tightly built into the information system of the company. However, in a component-based approach, this calculation would be a component that exists independent of the system, and is called by the system whenever needed, simply by communicating via messages. Now if the company acquires another business, it would be much easier to adopt a message-based communication method with a freely existing component, than with a function hidden within a completely different application. Similar ideas are put forth in another paper by Sutherland and Heuvel (2002). Both studies indicate that components can best realize the power of distributed application platforms with a more looselycoupled architecture. Gokhale, Schmidt, Natarajan and Wang (2003) go a step ahead and examine the application of component middleware in enterprise applications. They propose a specific middleware approach called Model-Integrated Computing to satisfy demands like efficiency, scalability, dependability and security in enterprise applications like ecommerce and automated stock trading systems. This approach involves the abstraction
14
of Quality of Service (QoS) specifications rather than establishing them at the development level. It will help make such services reusable and overcome the limitations of programming languages when they attempt to achieve those demands. In doing so, it highlights one of the major advantages that a service-oriented approach has over traditional integration methods. The preceding discussion describes the attempts that have been made towards having a loosely-coupled, component-based approach for business integration. Such an approach will support reusability in a distributed application environment. It will also make the middleware more scalable so as to support integration of a greater variety in applications or systems. A service-oriented model to implement such an approach was suggested in a white paper for IBM by Brown, Johnston and Kelly (2003). The paper defines the basic premise of a service as a software entity that interacts with applications and other services through a loosely-coupled (often asynchronous) message-based communication model. The paper discusses how a service-oriented architecture can benefit by using components for development, and recommends this as a practice for web-based applications or web services. A review of the OASIS case study (Bacon and Moody, 2002) brings to the forefront a practical approach for resolving large-scale interoperation using an open and distributed service architecture. The study discusses an XML-based version of the Opera research groups CEA (Cambridge Event Architecture) system which was used in implementing a health record management system in the UK. The service model was
15
used to increase the interoperability of this system and make it independent of interacting technology platforms. The idea of software as a service is further explored by Turner, Budgen and Brereton (2003). The authors proposed a dynamic service model that is aimed at a flexible and inexpensive way for businesses to interact and perform this interaction over the Internet.
Web services for enterprise integration Zarras, Issarny and Kloukinas (2003) discussed the design and development of middleware for application integration in a distributed system environment. They made a distinct attempt to approach the integration process keeping the scalability and flexibility of the solution as a primary concern. Kon, Costa, Blair and Campbell (2002) presented a study on a model for designing next-generation middleware: reflective middleware. The model was designed with the view of supporting distributed development for web-based applications, again as a means to achieve easily scalable and dynamically manageable enterprise integration solutions. Stal (2002) proposed using web-based lightweight protocols like XML, HTTP and SOAP to encapsulate the integration solution in a service-oriented architecture. The paper made the case of employing the Internet as it was the single most uniform and accepted communication protocol across enterprises and industries. Stal states that he objective is to master and manage the heterogeneity, not eliminate it. XML is the building block for creating any web service. Any business integration has data exchange as one of the core objective. Stackpole (2001) feels that XML is likely
16
to become the standard for automating data exchange between business systems, whether between systems in one company or between suppliers and customers. Scribner and Stiver (2002) consider two important reasons for the widespread use of XML. First, it is loosely-coupled, which means sending an XML document is like sending text rather than formatting data in a proprietary protocol. They feel that this is a key reason for its wide acceptance on the Internet. Second, because it is used on every computing platform, its interoperability is very high. One of the main reasons for Microsoft developing the .NET platform was to take advantage of the concept of web services. Web services are built, from a developers perspective, with the modular development technique. To take advantage of this, Microsoft incorporated two key concepts in the .NET approach for modular architectures, as discussed by Weiss (2001). One is that an application is not restricted to a single computer. Rather, it is envisioned as being constructed of services invoked over a network. The second is the language independence it offers when it comes to code reusability. This involves the usage of SOAP as a standard communication protocol between interacting web services. As long as SOAP is used, web services on a .NET platform can be developed using any language and will still be able to interact with each other. Knorr (2003) explains that web services will play an important role in business integration because they will help make applications inside the enterprise available to other applications by wrapping them in web service interfaces. As organizations standardize their internal systems and interfaces, web services will take them closer to the plug-and-play integration environment.
17
Strengths and Weaknesses The reviewed literature establishes a solid foundation for the need of a new middleware approach to business integration. A major strength of this new approach is that the pitfalls in the earlier middleware approaches have been clearly identified, thus delineating the scope of what is needed to be done in proposing a better solution. In the context of this project, a major weakness in most of the current bodies of knowledge reviewed by the author is that they propose only models or theories describing the application of service-oriented architectures for business-to-business integration. The actual implementation has not been discussed at the same level of detail. Though other papers have further described how a web-based model for such an approach would serve the needs of managing dynamic and flexible business relationships in a scalable fashion, they do not describe how to make the transition from the model to the actual application. The strength of this study is that it probed deeper into the actual implementation of the proposed web-based model. The study identified the design and development-level issues of such an implementation. It used Microsoft Corporations .NET deployment platform for Web Services to develop the web-based integration model within serviceoriented architectures, and identified the benefits and problems inherent in such an approach.
Definition of Terms .NET Architecture - The infrastructure of the .NET platform from Microsoft. It includes the Common Language Runtime (CLR) and .NET Framework class library. The
18
CLR provides the environment for running .NET applications, and the class library provides the foundation services, including ASP.NET, ADO.NET, Windows Forms (for building GUIs) as well as classes for accessing COM services B2B see Business to Business Business process In context of information systems, a it is the application of a business transaction to a database. Business to Business Integration Refers to application integration across companies for the purpose of exchange of products, services, or information between businesses rather than between businesses and consumers. Business Process Re-engineering - Using information technology to improve performance and cut costs. Its main premise is to examine the goals of an organization and to redesign work and business processes from the ground up rather than simply automate existing tasks and functions. Component Middleware Refers to middleware that consists of program modules that are designed to interoperate with each other at runtime. Components can be large or small. They can be written by different programmers using different development environments and they may or may not be platform independent Component-Oriented Software - Program modules that are designed to interoperate with each other at runtime. Components can be large or small. They can be written by different programmers using different development environments, and they may or may not be platform independent. Components can be run in stand-
19
alone machines, on a LAN, intranet or the Internet. Examples of this include J2EE, .NET, CORBA, DCOM. CORBA (Common Object Request Broker Architecture) - A standard from the Object Management Group (OMG) for communicating between distributed objects (objects are self-contained software modules). CORBA provides a way to execute programs (objects) written in different programming languages running on different platforms no matter where they reside in the network. Coupling Architecture the assembly of software components, technologies and protocols that bind disparate information systems together for the purpose of exchanging or sharing information. Cross enterprise integration see business to business integration. CTO (Chief Technical Officer) The executive responsible for the technical direction of an organization. DCOM - (Distributed Component Object Model) Formerly Network OLE, it is Microsoft's technology for distributed objects. DCOM is based on COM, Microsoft's component software architecture. It defines remote procedure calls that allow objects to run over a network. Distributed application architecture A highly modularized software system whose functions are represented by components that are logically independent of each other. The system relies on interaction between different components to accomplish its task. Enterprise Application Integration - Refers to integrating applications internally within the organization in contrast to business-to-business (B2B) integration.
20
EDI (Electronic Data Interchange) - The electronic communication of business transactions, such as orders, confirmations and invoices, between organizations. Third parties provide EDI services that enable organizations with different equipment to connect. Although interactive access may be a part of it, EDI implies direct computer-to-computer transactions into vendors' databases and ordering systems. Enterprise Information Systems/Architecture A computer-based information backbone of an organization that is responsible for collecting, managing and disseminating business information within and across enterprise boundaries ERP (Enterprise Resource Planning) - An integrated information system that serves all departments within an enterprise Information flow refers to the path that specific data follows from beginning to end within an information system Information system - A business application of the computer. It is made up of the database, application programs, manual and machine procedures and encompasses the computer systems that do the processing Internet - is made up of computers in more than 100 countries covering commercial, academic and government endeavors. Originally developed for the U.S. military, the Internet became widely used for academic and commercial research. Users had access to unpublished data and journals on a huge variety of subjects. Today, the Internet has become commercialized into a worldwide information highway, providing information on every subject known to humankind.
21
J2EE - A platform from Sun for building distributed enterprise applications. J2EE services are performed in the middle tier between the user's machine and the enterprise's databases and legacy information systems. J2EE comprises a specification, reference implementation and set of testing suites Legacy Application or System - An application that has been in existence for some time. It often refers to mainframe and ERP applications; however, as users abandoned DOS and Windows 3.1 for Windows 95/98 and NT, they too are called legacy applications Middleware Software that manages interaction between disparate applications and platforms; a computer intermediary. Service-oriented Architecture A software framework in which software components are exposed as services on the network and can be reused for different applications and for different purposes. SOAP (Simple Object Access Protocol) - A message-based protocol based on XML for accessing services on the Web. Initiated by Microsoft, IBM and others, it employs XML syntax to send text commands across the Internet using HTTP UDDI- (Universal Description, Discovery and Integration) An industry initiative for a universal business registry (catalog) of Web services Value Chain The sequence of business partners along any industries that interact with each other to provide a service or a product to the customer. Web-based architecture Refers to software that runs on or interacts with a Web site, which may be on the Internet or on an in-house intranet.
22
Web-based integration Refers to integration software that runs on or interacts with a Web site, which may be on the Internet or on an in-house intranet Web Services - Web-based applications that dynamically interact with other Web applications using open standards such as XML, UDDI and SOAP. These applications typically run behind the scenes, one program "talking to" another (server to server). Microsoft's .NET and Sun's Sun ONE (J2EE) are the major development platforms that natively support these standards WSDL-(Web Services Description Language) A protocol for a Web service to describe its capabilities. Co-developed by Microsoft and IBM, WSDL describes the protocols and formats used by the service. WSFL-WSFL (Web Services Flow Language) is a protocol from IBM for describing the workflow between services. XML - XML (Extensible Markup Language) is an open standard from the W3C for describing data. XML provides a flexible way to create common information formats and share both the format and the data on the World Wide Web, intranets, and elsewhere. The developer, depending upon the business requirement, can define XML tags.
Delimitations The study did not explore the underlying concept of component-based architecture in detail. It primarily investigated the web-based model that can be built on top of it.
23
The purpose of the study was to focus on the implementation of web services using .NET. Although XML and SOAP were used to create the web service, this study did not explore the benefits and drawbacks of these technologies the purpose was to study system interoperability rather than data exchange. In this context, the possible issues concerning the implementing of these technologies was not be the focus of this study. The evaluation of web services using the parameters identified during the literature survey was a qualitative one. This evaluation was in the form of a comparative analysis of web services with other integration techniques, rather than a direct measure of the parameters. The selection of the comparative analysis was due to both the lack of established methods or measures for assessing web services and the need to limit project scope. Creating the metrics and a framework to apply them for measuring these parameters would have exceeded the scope of this study.
Assumptions The study assumed that web-based standards for web services, though not universal, are considered widely used enough within the industries that will implement web services to support the claim of web services being scalable and platform independent. The study further assumed that participating businesses have their information systems designed and implemented using the accepted distributed application architecture using a component-oriented approach.
24
Limitations The development and publishing of a full-fledged web service that would meet the needs of businesses would have taken significantly more time than was available for this study. As such, only a basic web service was created. Similarly, only a simulation of a B2B environment was possible. Testing of the web service in a live environment was not feasible. This would have required publishing of the web services on a public server, and registering the web services with a public registry. The cost associated with the above two activities and the technical support available for the scope of this study restricted the testing to a simulated environment.
PROCEDURES The study was a qualitative analysis of technology factors in business-to-business integration. The objective of the study was to analyze an implementation of web services on the .NET platform and evaluate the web services that were developed as a B2B integration mechanism against parameters mentioned by Medjahed et al (2003). These include scalability, security, heterogeneity and adaptability. As explained in the delimitations section, the study did not entail measurement of specific metrics for these parameters, but relied on a more qualitative approach. The target population is any two or more business information systems interacting via a middleware tool. Although the interacting systems can be deployed on any platform, there is a stipulation that they must support the concept of a distributed computing architecture to enable a web service integration solution. For the scope of this study, the sample business information systems were simulated using specific
25
components of the whole system. A web service was the interface between these two application components. The study consisted of four distinct phases: 1. Examination of existing B2B integration techniques. 2. Analyses of the service-oriented architecture and its benefits in B2B integration. 3. Analyses of web services from a service-oriented architecture perspective and its suitability for implementing a B2B integration solution. 4. Developing a web service proof-of-concept using the.NET platform. The study attempted to provide a historical perspective in the continuing issues that have hindered business communication. Broad categories like industry standards, communication protocols and technology platforms were investigated to identify implementation level issues for business integration. Identifying problems from this initial research, the study proposed a possible solution applying a service-oriented approach for a web-based model as an alternative method to integrate disparate information systems. A model web service was created on Microsoft Corporations .NET platform and used as a prototype to understand and illustrate the possible benefits and drawbacks of using this approach for resolving the issue stated above. The study relied on the sources identified during the literature review to present the evolution of business-to-business integration to its current form. This analysis involved papers on each of the earlier integration solutions to provide a complete perspective on these solutions. Discussions of the underlying technology led to the problems inherent in these solutions. Medjahed et al provided one such discussion and
26
comparison of earlier business integration solutions (EDI, component based integration) and provided an insight into the need for a web-based, service-oriented architecture. The study analyzed the literature to provide a summarized report of previous technologies and their problems. Articles and case studies from leading publications like IEEE, ACM and resources like Gartner Research established the importance of a service-oriented approach for integration in todays business environment. The resources in this phase were analyzed more critically, keeping in mind the important factors that in the first place led to the recognition of such an approach scalability to provide for a more dynamic and flexible business communication infrastructure between enterprises. The study then provided a more technology-related perspective of this proposed solution. It explored the relationship of the needs and characteristics of a service-oriented approach to business integration, and how these could be complemented by implementing such a solution using Microsoft Corporations .NET development framework on a webbased model (Web Services). An important goal was to substantiate the reasons for using .NET as a development framework for creating web services for business communication. By comparing broad-level features of this environment with other leading technology frameworks like J2EE, the study also provided a comparative rationale for using .NET. A model web service was developed adopting a service-oriented development architecture (Plummer, 2003) to simulate and demonstrate how independent businesses could interoperate via this web service. This web service was developed and deployed using the .NET platform. XML was used as the data format and SOAP as the
27
communication protocol as both these technologies are considered to be industry standards. For the purpose of this study, an online credit card approval service was created. By demonstrating that systems on different technology platforms (like .NET and J2EE) could access and use this web service, the study demonstrated the interoperability of web services. This proof-of-concept was used to identify two distinctive elements of web services that make it a B2B integration technology - namely its usage of SOAP and the concept of WSDL and proxy class and how they helped make web service a better approach to B2B integration. These findings were the basis in developing the web service approach to B2B integration.
Analysis An online credit card approval component-based system is the proof-of-concept that was developed for this study. It was designed and deployed following the principles of a distributed, component-oriented approach. Important guidelines and ideas for this development were discussed by Issarny, Kloukinas and Zarras (2003) and Brown et al (2003). Further, the ideas proposed by Turner et al (2003) to orchestrate these components and treat the software as a service was the key in designing the web service. to the web service was created to be highly re-configurable to allow deployment over the Internet using standards like HTTP and XML. Microsoft Corporations .NET platform was used as the deployment platform. The study analyzed the following
28
1. The implementation of a web service using the .NET framework this identified the benefits and drawbacks of deploying the web service on the .NET platform. 2. The implication of adopting the service as a web-based interface for different applications to communicate with each other this investigated how factors like scalability, adaptability and cost of implementation were affected by the approach this study recommends.
FINDINGS AND DISCUSSIONS This section of the report includes the following: 1. Identifies the issues and challenges in B2B integration. 2. Demonstrates how SOA would serve as a conceptual solution to these problems. 3. Explains how web services will manifest SOA in creating a B2B integration solution at a practical level. 4. Identifies the benefits of deploying such a web service solution on the .NET platform using a proof-of-concept web service. 5. Uses the proof-of-concept as a basis to develop a web service approach for B2B integration
Evolution of B2B Integration Solutions The challenge in B2B interaction lies in the integration and interoperation of both application and data (Medjahed et al, 2003). This is due to the heterogeneous systems,
29
distributed applications and legacy data formats that every business has maintained. They identified the following dimensions to evaluate a B2B integration framework: coupling among partners, heterogeneity, autonomy, external manageability, adaptability, security and scalability. Samtani and Sadhwani (2002) put forth a similar set of parameters required from a B2B integration solution. The solution should automate real-time exchange of data between disparate applications of any business partner at any point in time (coupling). The solution should also provide for monitoring services like log audits and secure transactions (security, external manageability). The solution should be able to support different data formats and communication protocols that each of the interacting business use (heterogeneity). The solution should be deployed on a global set of standards that allow any business to use it (autonomy). And finally, the system should be scalable vertically and horizontally (scalability). All these issues had to be considered at a practical level in the following B2B connections: 1. Front-end with back-end systems 2. Proprietary/legacy data sources, applications, processes and workflows to the web 3. Trading partners systems Initial B2B efforts to resolve the above problems resulted in the creation of Electronic Data Interchange (EDI) (Accredited Standards Committee , 2004). EDI is the inter-organizational application-to-application exchange of standardized business documents between computers. EDI defines a limited set of document formats based on the ANSI X12 standard. The main objective of these documents was to represent the business transactions electronically and eliminate paper-based transactions more than
30
providing an interacting platform for B2B communications. As such, EDI did not consider a lot of factors relevant to B2B integration. EDI provided a very stronglycoupled environment, leaving no flexibility for partners who did not follow the EDI standards. Also the cost of joining an EDI network was considerably high as it involved proprietary and expensive networks. This constrained the scalability and autonomy of EDI as a B2B integration solution. In terms of B2B connections, EDI was primarily setup only for trading with partners systems. It was not used for connecting front-end with back-end systems or for exposing proprietary systems and workflows to the web. To facilitate a more flexible interaction between businesses, the component middleware framework was conceived. Component-based systems consist of a lightweight kernel to which new features can be added in the form of components (Bichler, Segev and Zhao, 1998). A component is defined as a self-contained entity that describes and/or performs a specific function. This approach requires interconnection of geographically-distributed components and allows interoperability between components of different systems. CORBA, DCOM and EJB are examples of component middleware frameworks. However, when it comes to inter-organizational B2B interactions, component-based interaction is limited by the fact that the interacting systems need to be deployed on the same platform. A CORBA-based component (deployed on Java) cannot communicate with a DCOM component (deployed on Microsofts component software architecture). This greatly limits the scalability and adaptability of these frameworks. Component-based systems also result in tightly-coupled business systems, and do not adapt to rapid changes in business processes and new business partners. Like EDI, it had
31
no inherent support for exposing systems to the Internet to allow easy and quick access to business information for their partners and customers. The preceding analysis clearly highlights the drawbacks of contemporary middleware techniques. This project suggests the use of a different integration method based on the service-oriented architecture to overcome these problems. Before identifying the benefits of this technique, it is important to understand the architecture itself. The advantages that web services hold over other contemporary B2B technologies are best described by the two components that make up its name web and services.
The service of web services - Service-oriented Architecture (SOA) The service component of web services refers to the conceptual idea behind web services. Web services are constructed on a service-oriented architecture (SOA). The basic (technical) concept underlying this architecture is to provide access to software functionality by wrapping it as a service. Service here is defined as a unit of functionality with its semantics defined in the form of an interface Perrey and Lycett (2003). This implies a dynamic application structure. Unlike a distributed application which consists of software functionality wrapped as objects bound to each other the service-oriented application environment consists of a loosely-coupled service space. If the user of a service-based application desires a particular functionality, the application will invoke the correct service from this service space. In essence, the service-oriented architecture turns software into a service by enabling the dynamic creation of one or more services or functionality using existing services. This objective is achieved by a process called ultralate binding (Turner et al, 2003).
32
Ultra-late binding allows the services in the service space to exist independently of each other; they are coupled only when one service needs another to perform a task. The software as a service paradigm (Turner et al, 2003) differs radically from the traditional software development approach in that it envisions the service model to be demand led; applications can be constructed from smaller component services and bound dynamically as needed. This is called service composition. Traditionally, software components were packaged together to serve a pre-determined set of purposes, and could not be repackaged to perform other functions if needed. With the introduction of the concept of service composition, SOA allows binding of lower level services to create a new service which can be used without user intervention as the business need and context change. It is necessary to understand the general framework and elements of the SOA that contribute to its feasibility as a B2B integration framework. Figure 1 is a simplistic view of a working model of a SOA.
Figure 1. The Service Model. Source: www.ibm.com
Each element of the SOA can play one or more of the three roles service requester, service provider, and service broker (Tsalgatidou and Pilioura, 2002). Service provider is the entity that provides the software application or functionality as a service.
33
The provider is considered to be the owner of the service and the platform where it is executed. The service broker registers and categorizes services to make them searchable. Service providers publish their service with the broker. The service requester is the system (or business) that needs the software functionality. The requester will search for a service from the service broker. Once a service has been found, the service provider for that service will bind the service request from the requester (ultra-late binding) and the necessary functionality will be provided to the requester. The interactions between these three roles are driven by three primary actions service description, service discovery, and service delivery (Turner et al, 2003). Service description is the most important function in SOA it is what is published, requested and categorized for every service (Burbeck, 2000). The service description makes it possible for the service provider to describe the syntax and semantics of the service so that the service can be mapped to fulfill a client need. The service description includes descriptions of functionality, interfaces, and nonfunctional characteristics like security, authentication and privacy issues related to the exchange of information and constraints such as quality of service and cost. This description is published with the service broker. A business or client (i.e. a service requester) can use service discovery to identify which service will meet the organizations functional requirements. The service description of that service is used to make this assessment. Service discovery also include service negotiation, which is used to create an agreement between the service provider and requester. Once the requester has identified the correct service from the service discovery phase, the provider will deliver the service to the requester. This is the service delivery phase, or the runtime phase. It is when the sequence of collaborations between services is
34
realized. It requires the calling client/interface to invoke the correct service based on the agreement created in the service discovery phase. The provider will then provide the service in a manner and for a period of time as agreed upon in the contract with the requester via service binding. This sequence of events between the three roles constitutes the actual functionality of the service-oriented architecture. A more complete environment for implementing the service-oriented architecture would involve non-functional services like monitoring and quality of services, valueadded services, security and monitoring. An extended service-oriented architecture which encompasses this is shown in Figure 2, and would be a more practical representation of the SOA.
Figure 2. Extended Service-Oriented Architecture. Source: Communications of the ACM
The relevance of a service-oriented architecture for B2B integration One of the objectives of this project was to clearly understand how this technical concept of services is relevant when considering B2B integration at the process level. Perrey and Lycett
35
(2003) define services from a business perspective as a unit of transaction described in a contract and fulfilled by the business infrastructure. The presumptions and semantics of service signify the business experience and this shapes the perspective. The benefit of the service-oriented architecture then stems from the fact that it provides an architecture for organizing a technical framework which will support the automation of business services and processes to permit restructuring to serve the demands of new or constantly changing processes. In the context of B2B integration, this implies having a central network of independently existing services whose interfaces define the semantics, syntax and functionality of the service. When an inter-organizational process has to be executed, the predefined workflow for that process will compose the required services from the service space, choreograph the sequence of execution of the services and orchestrate the business process in the service-orientation architecture. Thus, stateless services are composed and choreographed based on the context provided by the workflow that is defined by the business process at the time of execution of the process. Benefits of the Service-oriented Architecture for B2B Integration - The most obvious benefit of SOA over EDI and component-based integration is that it provides a loosely-coupled integration framework. SOA focuses on delivering functionality as a set of distributed services that can be configured and bound at execution time (Turner et al, 2003). This ultra-late binding of services makes it much more flexible and adaptable to accommodate new services (or functionalities). Thus the scalability of such an approach is much more than previous B2B integration techniques. Again, because services are not bound to each other until needed, different systems built on a similar architecture can access an existing service or integrate their service with one from another system by
36
simply invoking it (assuming that the security policy allows it to). The interaction of these services is independent of the deployment platform. This independence means that the interoperability of the SOA solution will be much higher. SOA is most popularly manifested in web services (Papagozlou and Georgakoplous, 2003). It involved the usage of standard protocols like SOAP and XML for messaging and storing data, which have been accepted as standards for web services by most leading web service platforms including IBMs Web Sphere, Microsofts .NET and Suns J2EE. This makes SOA a heterogeneous and open architecture to deploy middleware integration solutions. SOA is also extensible, allowing participating businesses to adopt their own data formats using XML and still be able to engage web services for B2B interactions. Thus, SOA supports all three B2B connections mentioned above front-end to back-end, legacy systems exposed to the web, and between trading partners system.
The web of web services enabling the SOA for B2B Integration The web component of web services refers to the practical or implementation aspect behind the concept of web services. Web services can be defined as self-contained, modular applications, accessible via the Web, that provide a set of functionalities to businesses or individuals (Tsalgatidou and Pilioura, 2002). Software applications developed on a service-oriented architecture are manifested on the Internet as web services. The Web has become the user interface of global business, and web services now offer a strong foundation for software interoperability (Chung, Lin and Mathieu, 2003). Companies are exposing their business processes and systems on the Internet to achieve greater automation, efficiency and global visibility. Web services allow
37
companies to do this using the SOA described in the previous section. Because they allow businesses to take advantage of the loosely-coupled application paradigm of SOA over the Internet, it makes web services important for B2B integration. A brief understanding of the architectural elements of web services can be instructive before realizing how web services as a whole are relevant to B2B integration. These elements include protocols and standards that allow system developers to develop service-oriented applications over the Internet, non-functional characteristics like security, quality of service and workflow management, and application programming interfaces (APIs) that allow individuals and businesses to locate and utilize web services. These elements are thus the enabling tools of SOA for application development. The elements put together in an architectural framework are referred to as the Web Services Stack. A general view of the stack accepted as a standard by all leading web service vendors is in Figure 3:
Figure 3. The Web Services Stack. Source: IBM Journal
Basic Layers of the Web Service Stack
38
o The network is the underlying transport protocol layer which makes web services available over a network. The stack supports the HTTP protocol which allows access to web services via the Internet, and also other important network protocols like SMTP, FTP, IIOP and MQSeries. In its truest form, messaging in web services is independent of the protocol used at the network layer. This freedom from being tied to a specific protocol ensures that web services do not end up being a proprietary tool, which is very important for a B2B interaction. Again, its support of the HTTP protocol implies that any business that can access the Internet would be able to participate in a web service-based business interaction. o Over the network layer is the XML messaging layer. It uses the Simple Object Access Protocol (SOAP). SOAP is a standard for messaging and making remote procedure calls over the Internet between the service requester and the service provider. It is independent of the transport protocol or the programming language of the requester or the provider. It is essentially an XML document coded in a specific format. SOAP messages are used to publish, find, bind and invoke services. The SOAP document consists of three sections. The envelope contains the namespace information for that message. The head is used to encode information regarding non-functional services like authentication and security. The body contains the main message o Web Service Description Language (WSDL) is used for describing the web service. This is also an XML-based schema used to describe the functionality
39
of a service in terms of its interface. It also contains information regarding the location of the service and how to invoke it. o The Universal Description, Discovery and Integration (UDDI) protocol is an XML-based schema used to publish web services. Publishing allows a business requiring a service to gain access to the WSDL document of a service to determine if the service matches the business need. Since web services are a realization of the SOA, the roles and interactions in a web service environment will resemble the interactions shown in Figure 4.
Figure 4. Web service interactions. Source: Distributed and Parallel Database
Benefits of web services for B2B Integration - This project identifies the use of XML (Extended Markup Language) as one key factor that makes web services a potentially universal option for B2B interaction (besides its foundation of SOA). Major standards in web services like WSDL, UDDI and SOAP are all XML-based protocols. This stems from the fact that XML is not merely a data format but is more of an open standard which can be used to represent any data as needed by a business. In the case of
40
data storage, when XML is used for storing information, interoperability between systems can be achieved since one XML representation can easily be converted to another. Because web services employs XML as its native protocol (irrespective of the deployment platform), web services deployment and accessibility is not restricted to any technology, platform or vendor, and it makes web services a superior candidate for B2B integration. The benefits of adopting web services as an integration technique are latent in its architecture. The protocols at every layer of the stack are XML based, which is accepted as the standard in interoperability by all major businesses in the B2B community. This standardization of the open protocols and APIs shown in Figure 3 is the key to the ubiquitous deployment of the web service architecture, and the ubiquitous deployment of the infrastructure is the key to the adoption of web services (Gottschalk, Graham, Kreger and Snell, 2002). Systems using XML can interact with each other even if the XML encoding is different for each system. The deployment platforms of systems or their geographical location does not impact the interaction as long as both systems can access the Internet. This is a great advantage that web services hold over traditional B2B integration methods, all of which were tightly-coupled and platform-dependent. Thus, at the data level, system interoperability is achieved using web services. The benefits of the web services stack for B2B interaction are summarized by Baglietto, Maresca, Pardoi and Zingirian (2002) below: 1. Integration of enterprise systems and collaboration using Internet wide transport protocols (HTTP/SMTP).
41
2. Interoperability achieved by exploiting XML formats for document exchange and service access through SOAP protocol. 3. Registry-centric, distributed architecture adopting the UDDI Registry standard. Web service workflow for B2B integration - B2B interactions are not limited to data exchange. It is the inter-organizational interoperability that can be achieved at the process level using web services that makes it a superior approach to B2B integration compared to previous attempts. This project introduces the notion of using web services at a process level using a concept called workflow of web services. Implementing and managing web service workflows across organizational boundaries would lead to B2B interoperability. B2B integration through workflows requires the construction of business processes from multiple web services. This is referred to as web services composition. It requires mapping a business process to one or more web services and controlling the flow of these web services to execute the process. It is driven by two activities orchestration and choreography, as depicted in Figure 5.
Figure 5. Orchestration and Choreography of Web Services. Source: IEEE Computer Society
42
Peltz (2003) defines orchestration as an executable business process that can interact with both internal and external web services. The interactions occur at the message level. They include business logic and task execution order, and they can span applications and organizations to define a long-lived, transactional, multi-step process model. Choreography is associated with tracking messages among the interacting services across organizations, and is required to maintain the overall state and context of the orchestration process. Interoperability at the process level to enable such an orchestration of services requires the representation of business processes as web services. This mapping of a business process to a web service can be accomplished by the Business Process Execution Language (BPEL). It is one of the specifications for representing process workflows, and has support from Microsoft, IBM, Siebel and other major web service vendors. Leymann, Roller and Schmidt (2002) propose an approach to implement activities within a business process using web services. It uses directed graphs to implement flow models a graphical representation of processes. Once the activities in a process have been identified in the flow model, BPEL (or a similar language) can be used to model each activity. Both interacting partners need to adopt this approach before true B2B integration can be achieved. In a true service-oriented architecture, the interacting business partners will expose the service interfaces of inter-organizational processes as WSDL descriptions. When interaction is required, the BPEL (also an XML-based schema like WSDL) representation of the process will use the WSDL ports of each partner to facilitate the execution of the process across the organizations.
43
The author feels that as business interactions exceed the traditional boundaries of information exchange and extend to process interoperability between partners and vendors to leverage the true power of business automation and derive maximum efficiency, the application of workflow technology to web services for B2B interactions will be the single most important factor in creating a successful business integrating approach. This could potentially be the greatest benefit of web services when used for B2B integration.
Deploying web services the .NET platform Microsoft's .NET framework and Sun's J2EE (Java2 Enterprise Environment) are the two industry leaders in providing platforms for web services. Though both have, for the first time, agreed on the core standards that define web services, both have distinct and often contrasting approaches to deliver the benefits of web services to customers. The basic premise of the argument is that the .NET framework can better leverage an existing Windows environment. .NET is tightly coupled with the Windows operating system. It provides for better integration of web services with other Microsoft products. This is primarily because the .NET framework was architected around XML and web services. It is not as mature, so existing Microsoft applications need to be recoded to move them to .NET. J2EE enables a more cross-platform solution. It is not a product suite like .NET, and is more of a standard that developers and applications need to follow to fall within the J2EE framework. As such, J2EE provides a more abstract and looselyintegrated environment. J2EE uses Java, which is more mature; however, its vendors view web services as more of an add-on to a proven technology.
44
.NET is accepted as the early mover in web services. More importantly, it can boast of a framework developed with web services as the core idea. Weiss (2000) pointed out that the core idea in conceiving the .NET framework was that of providing a distributed computing environment. The .NET framework views an application as fragments of functionality spread over a network. This loosely-coupled approach to application development is synonymous with the service-oriented architecture philosophy, and as such the .NET architecture and its elements inherently support the deployment of web services for B2B integration. .NET provides intrinsic support for the main elements of web services XML. .NET also supports messaging via the HTTP protocol. These factors make .NET an important alternative. The .NET environment has intrinsic support for web services in its major components the .NET framework, Visual Studio.NET (VS.NET) and ASP.NET (Newcomer, 2002). .NET also hosts the client and server technologies for web services, which J2EE does not. This implies that if a .NET application wants to expose a service or functionality as a web service, it is one of the native options available in VS.NET. In the case of J2EE, an additional step of wrapping the service in a certain type (called Enterprise Java Bean or EJB) is needed before it can be exposed as a web service. Thus, every web service feature or standard (like SOAP or WSDL) requires the use of additional APIs with the J2EE framework, while .NET has support for this built into the platform itself. Another benefit of using the .NET platform is the sophisticated IDE available for developing web service applications Microsofts VS.NET (Visual Studio.NET). Because J2EE is a standard and not a platform, there is no one integrated IDE that can
45
provide the development support for web services as easily as VS.NET does. The relatively friendlier user interface and proximity with the .NET framework make VS.NET a preferred IDE for web service developers. .NET does have a drawback in that it is tied to the Windows platform, as it has evolved from the Windows DNA architecture. Thus, a .NET developed web service needs to be hosted on a Windows server, limiting its deployment scope to a Windows environment. However, the interoperability of the web service thus developed is not affected, and as such is still a widely used development platform for web services.
Proof-of-concept a web service for credit card validation using .NET A prototype web service was created for this project. This was the proof-ofconcept required to demonstrate the utility of web services for business integration. The proof-of-concept was also developed to demonstrate the deployment issues that arise in a practical case scenario of implementing web services. Microsofts .NET framework was the chosen deployment platform for the proof-of-concept, and enabled a first-hand look at the benefits and problems faced in using .NET for creating and deploying web services. .NET provides a way for mapping class methods or functions to a web service. One of the most efficient and popular ways to do this is using the WebMethods framework in ASP.NET. Conceptually, web services involve processing of SOAP documents, which are messages requesting a certain operation and encoded in XML. WebMethods provides an abstraction to this messaging by generating and parsing the SOAP documents that are sent from and received by the web service. Thus developers need not understand the XML schemas used for SOAP messages while creating or
46
invoking web services. A class representing the web service is created, and the functionality that it will provide is encapsulated within the methods of this class. Prototype Overview- The prototype consists of a client requiring credit card validation for any user filling out his/her credit card details and submitting the form. This client could be a desktop application or an e-commerce web page. The client platform could also be variable. A .NET application which provides this validation service using Luhns Formula was created using Visual Studio.NET and deployed on an IIS server (Internet Information Server) with support for the .NET framework. To achieve interoperability with any operating system, this application was conceived, developed and exposed as a web service, and made accessible over the Internet. Two clients were created, one a desktop application form on Microsofts .NET platform using VB.NET (Visual Basic.NET) and the other on Suns J2EE platform using JSP (Java Server Pages). The use of a desktop application created on one platform and a web application on another platform to call a web service clearly indicates the extent of interoperability that can be achieved using web services. An attempt was made to prove the utility of web services in interacting with a diverse range of technologies, platforms and software architectures, and how scalable this interaction could be. Both clients could invoke and use the same service irrespective of their platforms. Thus, the prototype showed how B2B integration could be achieved using web services. Credit Card Validation Web Service Credit card numbers can be validated using Luhns formula. The web service contains the function to implement Luhns formula. It accepts the credit card number (say from an e-commerce store front form page), and then applies certain numeric processing steps to decide whether this number could be a valid
47
credit card number or not. Only if it is valid would the client application need to send the number for further processing, say by the credit bureau or bank. The basic function to implement Luhns formula was created using VB.NET. (See Appendix A)A creditCardValidatorvb class was created, and saved as an .asmx file. This is the standard extension for saving web service pages when creating them in .NET. This class has one method called creditCardValidator. The method accepts one argument, a string representing a credit card number which is sent by the client application invoking the service. This request for service and the string parameter are sent via a SOAP message from the client to the web service. A typical SOAP request for this web service would look like the following:
POST /sgandhi/webservice/creditcardvalidatorvb.asmx HTTP/1.1 Host: sotdev1.tech.purdue.edu Content-Type: text/xml; charset=utf-8 Content-Length: (length) SOAPAction: "http://tempuri.org/CreditCardValidator" <?xml version="1.0" encoding="utf-8"?> <soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <CreditCardValidator xmlns="http://tempuri.org/"> <cardNumber>(string)</cardNumber> </CreditCardValidator> </soap:Body> </soap:Envelope>
ASP.NETs WebMethod framework was used to expose this method as a web service. If a client requests a web service, a proxy class is compiled on the client side which would translate the request into a SOAP message (above) and send it to the web service. The request is parsed and mapped to the correct objects in .NET and then the creditCardValidator method is invoked to process the request. The response of the
48
method is again translated to a SOAP message, and sent to the proxy class at the client side. The proxy class will map the request back to a syntax understood by the client application. A typical response for the request above would be
HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Content-Length: length <?xml version="1.0" encoding="utf-8"?> <soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <CreditCardValidatorResponse xmlns="http://tempuri.org/"> <CreditCardValidatorResult>string</CreditCardValidatorResult> </CreditCardValidatorResponse> </soap:Body> </soap:Envelope>
Client Applications Two client applications were used to invoke the web service. The first was a desktop application form, created in VB.NET and executed locally on a computer. (See APPENDIX C) It essentially accepted a credit card number, and invoked the web service to validate this number. A similar form page was also created on a J2EE client, a JSP form page. (See Appendix B) The choice of these two clients was specifically made to demonstrate two important aspects of web service that would make it useful for B2B integration. 1. Scalability Web services can communicate with any kind of application, web-based or desktop-based. This flexibility makes it very easy for a business with an existing application to use this web service, since it does not need to conform to a specific application architecture. This use of the Internet to enable distributed applications to communicate with each other is a feature
49
that makes web services easily accessible and provides for a scalable communication infrastructure. 2. Interoperability A .NET and a J2EE based client were selected to prove that web service consumption is independent of the technology platform. This is one of the biggest advantages of web services - it can allow components from different platforms to interact with each other. This is a feature that distinguishes web services from EDI, distributed computing or any other previous and existing integration techniques.
Findings from the proof-of-concept The proof-of-concept helped identify two key features of web services that make it a superior approach for B2B integration. 1. The use of WSDL and proxy class for remote web service invocation Both the J2EE and the .NET clients used a proxy class on the client side. This class was created at design time. It is based on the WSDL provided by the web service, and it understands the parameters, data types and communication ports that a particular web service requires. Application developers can use the methods and functions that a web service provides (in any platform) just as if those functions were available locally. Conceptually, it means writing an application in several different languages, using the best language when needed, and not having to worry about how the different parts of the application will communicate with each other. Thus, the best features of several programming languages can now be used for a single application,
50
which would not have been feasible without web services. Thus, it is this proxy class that facilitates the concept of ultra-late binding, and is responsible for the loosely-coupled architecture that web services can bring to B2B integration. 2. The use of SOAP for messaging SOAP is an XML schema. It is an open protocol, and not owned by any vendor. Support for SOAP is easily incorporated in most distributed computing environments, since it is not dependent on the transport mechanism. Thus, both the JSP page and the .NET form could easily exchange SOAP messages with the web service, and map the results to their internal objects by parsing the SOAP responses. This ubiquitous nature of SOAP makes it a flexible communication mechanism which anyone can use irrespective of the technical platform.
A web service approach for B2B integration The proof-of-concept demonstrated the interoperability of web services, independent of the communicating platforms. The key to interoperability using this approach is the use of SOAP as the messaging protocol and XML as the underlying data representation technique. Both these protocols are considered as industry standard, and have been adopted for use by industry leaders like Microsoft, IBM and Sun. It also showed how scalable the application was. Once XML and SOAP are used, then the published service is easily accessible (to any other application or web service) over the Internet as a URL. The findings of the proof-of-concept were used to develop the following approach for using a web service for B2B interactions:
51
1. Creating a workflow for business processes and their functions 2. Web service creation and description for use with SOAP and XML 3. Web service discovery and contract negotiation 4. Web service consumption The following is a more detailed discussion of each of these steps. Creating a workflow for business processes and their functions For B2B interactions, web services will emulate inter-organizational business processes or transactions. Thus, it is important to represent these processes using XML so that they can be executed using web services. This representation is called a workflow. Workflow representing complex processes or spanning organizations are usually composed of individual web services representing native functions. These will also be represented in an XML format. The Business Process Execution Language (BPEL) is a combination of two standards IBMs Web Service Flow Language (WSFL) and Microsofts XLANG (one of the emerging specifications for mapping processes to an XML based schema). An XML-based workflow can be used as an executable script to enable two or more information systems or applications to interact with each other by orchestrating one or more web services and thus complete the implementation of the business process. Web service creation and description for use with SOAP and XML Individual web services can be created on any platform that supports the web service concept. .NET and J2EE are the two accepted platforms, but a web service can be programmed in any traditional language, since the service user will interact with the service using SOAP and XML, and does not need to understand or be compatible with the actual coding language. Usually, a class is created to represent the web service. The methods of this class will
52
encapsulate the functionality that the service provides. These methods are exposed as the interface to the web service. Thus the main requirement for a programming language to support the creation of a web service is that it be able to expose this class or method as a web service to other applications. J2EEs JAX-RPC specification and .NETs WebMethods framework are two examples of extending support for web services using current programming languages. Once the web service has been created, it can be discovered by another application or web service based on its description. This automated discovery of a web service is enabled by the Web Service Description Language (WSDL). It specifies the port of communication, data types and the sequence in which the parameters should be supplied. This is referred to as the functional description of the web service. A greater challenge is to describe and implement the non-functional characteristics of the service like security, quality of service, state management etc. Web service discovery and contract negotiation Publishing the web service is essentially a matter of making the web service available as a URL at a public repository. The UDDI (Universal Description, Discovery and Integration) specification is a standard marketplace where businesses can register their web services to be discovered by another application or business globally. The UDDI is accessible over the Internet and acts as a global consortium to enable the exchange of services independent of technology platforms and vendors. It can be considered a yellow book for web service providers. Service requesters can access the WSDL descriptions of web services via the registry to determine the service they need. Thus applications and other web services can dynamically invoke any web service they need to implement a business process or
53
function, as long as there is a web service available for it. This makes the web service model a loosely-coupled architecture. If two interacting businesses have such a looselycoupled architecture, interoperability of their information systems can be achieved. This ability to achieve system interoperability dynamically and easily sets web services apart from the other B2B integration techniques. Once a service has been discovered, it has to be negotiated. Negotiation of service involves agreeing on the non-functional service features e.g. security. This negotiation and agreement is completed via XML-based documents. Web service consumption The core idea of using web services is that of a proxy class. The proxy class allows applications to dynamically invoke services during run-time from a distributed environment. A proxy class can be viewed as a compiled interface of the service on the client side. The client application communicates with this class identical to how it would communicate with any other local class. The proxy class will then handle both: the SOAP messaging and the XML to class mapping between the application and the web service. The proxy class can be compiled and created during development time (if the service needed is known at that time), or can be created during run-time. This idea of a proxy class enables ultra-late binding, the heart behind a serviceoriented architecture. This ultra-late binding completes the interaction to allow B2B interoperability between different systems using web services.
RECOMMENDATIONS FOR FURTHER STUDY This project has identified the following areas of opportunities for further study:
54
1. Quantifying inter-organizational processes using XML schemas True automation in business interoperability requires the representation of business processes using a format that web services can understand and use to communicate without human intervention. This will require a greater use of specifications like BPEL to map business processes. Moreover, a certain degree of standardization is needed before completely autonomous web services can be used to integrate disparate information systems. 2. Web service orchestration As vendors move towards providing complex and exhaustive services to businesses, it is necessary to manage the interactions between services of different vendors to implement a process smoothly and correctly. This requires orchestration of web services, which involves controlling the interaction between web services, and the sequence in which they are invoked. 3. Providing non-functional services A practical web service integration solution will require a close examination of how the traditional problems of the Internet can be overcome in deploying web services. Specifications for web service security, state management over long transactions and similar issues will have to evolve before comprehensive service architectures can be implemented. 4. Automated contract negotiation This is an important element when multiple web services are needed to automatically interact with each other. The implementation of SLAs, Quality of Service monitoring and standards will be needed before this automation can be achieved.
CONCLUSION
55
Web services are increasingly being adopted by organizations as a tool for business interoperability. They are a logical step to the distributed application structure. The cost of deployment of web services despite being a new technology is considerably low, encouraging organizations to test and adopt them at a much faster rate than they otherwise would with new technologies. Thus, the technical ease of constructing and using web services is responsible for its rapid initial acceptance. The benefit of web services for B2B data integration using is well documented, and is one of the reasons why web services is a relevant technology for the integration solution. According to Gwen Moertel, team lead for Wachovia Securities capital markets technology group, the purest form of Web services is not caching or storing anything. This is the first advantage Web services add to B2B systems. Under the Web services structure, data will be forwarded and responded directly; none of the data will be saved or cached. In the ever-changing modern world, this is exactly what enterprises need: realtime information. This project identified a further, more influential benefit of web services for B2B integration that of process integration. Because web services use XML and SOAP as the communication bridge between applications and Web services, integration between numerous business partners will become easier than ever. The only other alternative is to deploy cross-enterprise ERP applications. Connecting multiple value chains in this manner is not only costly, but the complexity of developing and implementing such a system itself is a barrier to its implementation. Scalability becomes an impossible consideration in this case, unlike with web services. This benefit was also the root idea in developing the web service approach to B2B integration recommended by this study.
56
How fast web services continue to mature will depend largely on their continual adoption by the industry at large. There are some drawbacks due to the existing state of web services. One is the standardization of specifications and protocols used for creating and using web services. Microsoft, IBM and Sun are the major promoters of web services and each have their own approaches and tools for using web services. This has led to the existence of more than one occurrence of the various specifications. This is particularly true for non-functional services like security and workflow management. Besides, these are not the only vendors of web services. A truly integrated web service environment would require industry-wide acceptance of a standard or a specification. The implementation of the proof-of-concept helped uncover two other drawbacks. The first is the lack of support for non-functional features. The most important one is security. Any B2B interaction must take place in a secure environment. But web services rely on the HTTP protocol, which does not have any inherent support for transactional security. Again, because HTTP is stateless, another non-functional feature that is not supported is state management. This is especially critical in long-running, complex B2B transactions. Similarly, SOAP is currently restricted to being used as a universal messaging format. If web services are to take the next step in B2B integration, it will largely depend on how SOAP can accommodate some of the transactional features like state management, authentication and security that are critical in any B2B interaction. The second drawback is the need for a better way to describe the semantics of a web service. WSDL is the key to creating proxy classes on remote clients, and dictates the nature of the proxy class. This proxy class is the core of any web service integration solution. Currently, WSDL provides only a syntactic description of the web service, and
57
is limited to stating the parameters, data types and communication ports required for the interaction. For describing more complex data types and services, WSDL must be able to incorporate a more sophisticated and semantic description of what the web service can do. This facilitates a better and more automated discovery of web services and contract negotiation process. Web services provide a new conceptual view to B2B integration that of a collaborative enterprise. A B2B integration technology platform requires a flexible and loosely-coupled architecture. For it to be adopted industry-wide, the deployment cost and complexity should be at a minimum. With its Internet-based protocols, web services have an open and flexible architecture that is easy-to-use. Adoption of web services does not require discarding of expensive ERP systems or other enterprise wide software applications. On the contrary, at an incremental expense, they can leverage the information from these systems and share it with business partners in a B2B marketplace. Thus, web services allow an abundance of declining integration costs and improved scalability opportunities in a B2B collaborative business environment.
58
REFERENCES Andrews, W. (2003, November). Predicts 2004: Web services. Retrieved March 20, 2004 from http://www.gartner.com/NewsLetterServlet?fcn=activityPublisher&unique=3777 406&link=8297&doc_cd=118573 Bacon, J. and Moody K. (2002, May). Towards Open, Secure, Widely Distributed Services. Communications of the ACM, Vol. 45, No. 6 Baglietto, P., Maresca, M., Parodi, A. and Zingirian, N. (2002). Proocedings of the Sixth Enterprise Distributed Object Computing Conference, IEEE. Bichler, M., Segev, A. & Zhao, L. (1998, December). Component-based E-Commerce: Assessment of Current Practices and Future Directions. ACM SIGMOD Record, Volume 27, Number 4. Brown, A., Johnston, S. and Kelly, K. (2003, April). Rational White Paper: Using Service Oriented Architecture and Component-Based Development to Build Web Service Applications. Retrieved September 20, 2003 from http://www.rational.com/media/whitepapers/TP032.pdf Brown, J., Durschlag, S. & Hagel, J. (2002). Loosening up: How process netwroks can unlock the power of specialization. Retrieved December 7, 2002 from http://download.mckinseyquarterly.com/forbes/web_services.pdf Burbeck, S. (2000, October). The Tao of e-business services. The evolution of Web applications into service-oriented components with Web services. Retrieved March 16, 2004 from http://www-4.ibm.com/software/developer/library/wstao/index.html
59
Cantara, M. (2003, May). Magic Quadrant for Web Services Consulting. Retrieved March 28, 2004 from http://www.gartnerconnects.com/reprints/wipro/DF-198268.htm Chung, J., Lin, K. & Mathieu, R. (2003, October). Web Services Computing: Advance Software Interoperability. IEEE Computer Society. Comport, J. (2002, December 2). Enterprise Application Architecture: New Challenges Ahead. Retrieved September 5, 2003 from http://www.itap.purdue.edu/itresources/gartner/research/111700/111773/111773.h tml Crknovic, I., Hnich, B., Jonsson, T. and Kiziltan, Z. (2002, October). Specification, Implementation, and Deployment of Components. Communications of the ACM, Volume 45, No. 10. Freemantle, P., Weerawarana, S. and Khalaf, R. (2002, October). Enterprise Services. Communications of the ACM, Volume 45, No. 6. Gates, B. (1995, March 24). Business @ The Speed of Thought. Warner Books. Gokhale, A., Schmidt, D., Natarajan, B., and Wang, N. (2002, October). Applying Model-Integrated Computing to Component Middleware And Enterprise Applications. Communications of the ACM, Volume 45, No. 10. Gottschalk, K., Graham, S., Kreger, H. and Snell, J. (2002). Introduction to Web services architecture. IBM Systems Journal, Volume 41, Number 2. Hagel, J. (2002). Web Service Technology as a Catalyst for Strategic Thinking. [Electronic Version]. Harvard Management Update, 7, 3
60
Issarny, V., Kloukinas, K., and Zarras, A. (2002, June). Systematic Aid for Developing Middleware Architectures. Communications of the ACM, Volume 45, No. 6. Knorr, E. (2001). Make Way for Web Services. Retrieved April 21, 2004 from http://www.cio.com/archive/101501/et_article.html Knorr, E. (2003). A Bargain So Far. Retrieved January 29, 2004 from http://www.cio.com/archive/091503/et_pundit.html Kon, F., Costa, F., Blair, G. and Campbell, H. (2002). Adaptive Middleware. Communications of the ACM, Volume 45, Issue Levi, K. and Arsanjani, A. (2002, October). A Goal driven approach to Enterprise Component Identification and Specification. Communications of the ACM, Volume 45, No. 10. Leymann, F., Roller, D. and Schmidt, M. (2002). Web services and business process management. IBM Systems Journal, Volume 41, Number 2. Medjahed, B., Boualem, B., Bouguettya, A., Ngu, A. and Elmagarid, A. (2003, April 3). Business-to-Business interactions: issues and enabling technologies, VLDB Journal. Mondal, S. and Das Gupta, K. (2000, May). Choosing a Middleware for Web-Integration of a Legacy Application. ACM Sigsoft, Software Engineering Notes, Vol 25 No. 3. Newcomer, E. (2002, October). Decide Between J2EE and .NET Web Services. Retrieved March 20, 2004 from http://www.ftponline.com/wss/2002_10/magazine/columns/webservices/default_p f.aspx
61
Papagozlou, M. and Georgakoplous, D. (2003). Service-Oriented Computing. Communications of the ACM, Volume 46, No. 10. Peltz, C. (2003, October). Web Services: Orchestration and Choreography. IEEE Computer Sociey. Perrey, R. and Lycett, M. Service-Oriented Architecture. Symposium on Applications and the Internet Workshops. IEEE. Plummer, D. (2003, October). SODA Harnesses Web Services for Process Fusion. Retrieved January 31, 2004 from http://www.itap.purdue.edu/itresources/gartner/research/117600/117684/117684.h tml Samtani, G and Sadhwani, D. (2002, January). B2Bi and Web Services: An Intimidating Task? Retrieved March 17, 2004 from http://www.webservicesarchitect.com/content/articles/samtani02.asp Scribner, K. and Stiver, M. (2002, July). Applied SOAP: XML and Web Service Implementation. Retrieved February 2, 2004 from http://www.informit.com/isapi/product_id~%7B6C104B1E-755F-43EA-8FB158AA20652529%7D/content/index.asp Stal, M (2002, October). Web Services: Beyond Component-Based Computing. Communications of the ACM, Volume 45, No. 10. Sutherland,J. and Heuvel, W. (2002, October). Enterprise Application Integration and Complex Adaptive Systems. Communications of the ACM, Volume 45, No. 10. Stackpole, B. (2001, February). What is XML? Retrieved February 2, 2004 from http://www.darwinmag.com/learn/curve/column.html?ArticleID=74
62
Tsalgatidou, A. and Pilioura, T. (2002). An Overview of Standards and Related Technology in Web Services. Distributed and Parallel Databases. Turner, M., Budgen, D. and Brereton, P. (2003, October). Turning Software into a Service. IEEE Computer Society. Varon, E. (2003, October). Calculated Risks. Retrieved February 1, 2004 from http://www.cio.com/archive/100103/risks.html Weiss, A. (2001, December). Microsofts .NET: platform in the clouds. Communications of the ACM, Volume 5, Issue 4. Accredited Standards Committee (2004) ASC X12 FAQs: What is EDI. Retrieved April 19, 2004 from http://www.x12.org/x12org/about/faqs.cfm#a1 Zarras, A., Valerie, I. and Kloukinas, C. (2002, June). Systematic aid for Developing Middleware Architecture. Communications of the ACM, Volume 45, Number 6.
63

B2B Integration Web Services Whitepaper

Transféré par

Informations du document

Description originale:

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

B2B Integration Web Services Whitepaper

Transféré par

Droits d'auteur :

Formats disponibles

A Service-Oriented Approach to B2B Integration using Web Services

White Paper By Saumil Gandhi

Published for DREAMSCAPE MEDIA

A Service-Oriented Approach to B2B Integration using Web Services

A Service-Oriented Approach to B2B Integration using Web Services

A Service-Oriented Approach to B2B Integration using Web Services

A Service-Oriented Approach to B2B Integration using Web Services

A Service-Oriented Approach to B2B Integration using Web Services

A Service-Oriented Approach to B2B Integration using Web Services

A Service-Oriented Approach to B2B Integration using Web Services

A Service-Oriented Approach to B2B Integration using Web Services

A Service-Oriented Approach to B2B Integration using Web Services

A Service-Oriented Approach to B2B Integration using Web Services

A Service-Oriented Approach to B2B Integration using Web Services

A Service-Oriented Approach to B2B Integration using Web Services

A Service-Oriented Approach to B2B Integration using Web Services

A Service-Oriented Approach to B2B Integration using Web Services

A Service-Oriented Approach to B2B Integration using Web Services

A Service-Oriented Approach to B2B Integration using Web Services

A Service-Oriented Approach to B2B Integration using Web Services

A Service-Oriented Approach to B2B Integration using Web Services

A Service-Oriented Approach to B2B Integration using Web Services

A Service-Oriented Approach to B2B Integration using Web Services

A Service-Oriented Approach to B2B Integration using Web Services

A Service-Oriented Approach to B2B Integration using Web Services

A Service-Oriented Approach to B2B Integration using Web Services

A Service-Oriented Approach to B2B Integration using Web Services

A Service-Oriented Approach to B2B Integration using Web Services

A Service-Oriented Approach to B2B Integration using Web Services

A Service-Oriented Approach to B2B Integration using Web Services

A Service-Oriented Approach to B2B Integration using Web Services

A Service-Oriented Approach to B2B Integration using Web Services

A Service-Oriented Approach to B2B Integration using Web Services

A Service-Oriented Approach to B2B Integration using Web Services

A Service-Oriented Approach to B2B Integration using Web Services

A Service-Oriented Approach to B2B Integration using Web Services

Figure 1. The Service Model. Source: www.ibm.com

A Service-Oriented Approach to B2B Integration using Web Services

A Service-Oriented Approach to B2B Integration using Web Services

Figure 2. Extended Service-Oriented Architecture. Source: Communications of the ACM

A Service-Oriented Approach to B2B Integration using Web Services

A Service-Oriented Approach to B2B Integration using Web Services

A Service-Oriented Approach to B2B Integration using Web Services

Figure 3. The Web Services Stack. Source: IBM Journal

Basic Layers of the Web Service Stack

A Service-Oriented Approach to B2B Integration using Web Services

A Service-Oriented Approach to B2B Integration using Web Services

Figure 4. Web service interactions. Source: Distributed and Parallel Database

A Service-Oriented Approach to B2B Integration using Web Services

A Service-Oriented Approach to B2B Integration using Web Services

A Service-Oriented Approach to B2B Integration using Web Services

A Service-Oriented Approach to B2B Integration using Web Services

A Service-Oriented Approach to B2B Integration using Web Services

A Service-Oriented Approach to B2B Integration using Web Services

A Service-Oriented Approach to B2B Integration using Web Services

A Service-Oriented Approach to B2B Integration using Web Services

A Service-Oriented Approach to B2B Integration using Web Services

A Service-Oriented Approach to B2B Integration using Web Services

A Service-Oriented Approach to B2B Integration using Web Services

A Service-Oriented Approach to B2B Integration using Web Services

A Service-Oriented Approach to B2B Integration using Web Services

A Service-Oriented Approach to B2B Integration using Web Services

A Service-Oriented Approach to B2B Integration using Web Services