b2b integration web services whitepaper

8/6/2019 B2B Integration Web Services Whitepaper

1/64

A Service-Oriented Approach to B2B Integration using Web

Services

White Paper

By

Saumil Gandhi

Published forDREAMSCAPE MEDIA


2/64

A Service-Oriented Approach to B2B Integration using Web Services

1

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.......................................................................................... 11LiteratureFindings ..................................................................................................... 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

Theservice 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


3/64


2

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 ........................................................................ 80APPENDIX C - .NET client ........................................................................................... 82

VB.NET form page ..................................................................................................... 82

The .NET proxy class.................................................................................................. 84


4/64


3

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-of-

Concept 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


5/64


4

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 termprocess networkimplies 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).


6/64


5

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


7/64


6

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


8/64


7

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 e-

commerce 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).


9/64


8

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


10/64


9

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


11/64


10

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.


12/64


11

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


13/64


12

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


14/64


13

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 decision-

making 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.


15/64


14

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 loosely-

coupled 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 e-

commerce and automated stock trading systems. This approach involves the abstraction


16/64


15

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


17/64


16

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


18/64


17

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.


19/64


18

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 service-

oriented 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


20/64


19

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-


21/64


20

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 (ChiefTechnical 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.


22/64


21

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.


23/64


22

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.


24/64


23

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.


25/64


24

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.


26/64


25

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


27/64


26

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


28/64


27

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 web-

based 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


29/64


28

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


30/64


29

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,


31/64


30

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


32/64


31

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 strongly-

coupled 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


33/64


32

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.

Theservice 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 ultra-

late binding (Turner et al, 2003).


34/64


33

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.


35/64


34

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


36/64


35

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, value-

added 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


37/64


36

(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


38/64


37

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


39/64


38

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


40/64


39

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 headis 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


41/64


40

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


42/64


41

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).


43/64


42

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


44/64


43

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.


45/64


44

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 loosely-

integrated environment. J2EE uses Java, which is more mature; however, its vendors

view web services as more of an add-on to a proven technology.


46/64


45

.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


47/64


46

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-of-

concept 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


48/64


47

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

b2b integration web services whitepaper

Documents