Unit 2 Web Services

8/9/2019 Unit 2 Web Services

1/72

1

II UNIT

yyy BBBuuusssiiinnneeessssss MMMoootttiiivvvaaatttiiiooonnnsss FFFooorrrWWWeeebbb SSSeeerrrvvviiiccceeesss BBB222bbb BBB222cccyyy TTTeeeccchhhnnniiicccaaalllMMMoootttiiivvvaaatttiiiooonnnsssyyy LLLiiimmmiiitttaaatttiiiooonnnsss OOOfffCCCooorrrbbbaaa AAAnnndddDDDcccooommmyyy SSSeeerrrvvviiiccceee---OOOrrriiieeennnttteeedddAAArrrccchhhiiittteeeccctttuuurrreee (((SSSoooaaa)))yyy AAArrrccchhhiiittteeeccctttiiinnnggg WWWeeebbb SSSeeerrrvvviiiccceeesssyyy IIImmmpppllleeemmmeeennntttaaatttiiiooonnn VVViiieeewwwyyy WWWeeebbb SSSeeerrrvvviiiccceeesssTTTeeeccchhhnnnooolllooogggyyySSStttaaaccckkkyyy LLLooogggiiicccaaalllVVViiieeewwwyyy CCCooommmpppooosssiiitttiiiooonnn OOOfffWWWeeebbb SSSeeerrrvvviiiccceeesssyyy DDDeeepppllloooyyymmmeeennntttVVViiieeewwwFFFrrrooommm AAAppppppllliiicccaaatttiiiooonnn SSSeeerrrvvveeerrrTTTooo PPPeeeeeerrrTTTooo PPPeeeeeerrryyy PPPrrroooccceeessssss VVViiieeewwwyyy LLLiiifffeeeIIInnnTTThhheee RRRuuunnntttiiimmmeee


2/72

2

Introduction

A short history of Web services

The Internet began its success story in the early nineties, even though it was used in the academic

world before for many years. The main driver for the Internets success was the World Wide Web,

whose main innovation was the easy access to information, from any place, using standard

Internet protocols and a simple data access protocol that enabled the implementation browsers

on

a variety of platforms. Together with the spread of the WWW, the Internet and its related

technologies became the de facto standard to connect computers all around the world.

With the spread of the Internet, it became clear that the infrastructure that was introduced by the

Internet could be used not just to retrieve information that was to be presented using a browser

(called human-to-application, H2A, scenarios).

Rather, there was also an increased demand for application-to-application (A2A) communication

using the existing technologies. And, it was hoped that the existing protocols could be used for this

purpose.

However, it soon became clear that this was not the case. HTTP had been designed with the

retrieval of information in mind, following a very simple access path that basically relies on

documents being linked together by means of hypertexts. The protocol does not provide for

complex operations that arise from A2A scenarios. And some of the protocols that were defined at

this time could not be used either because they did not fit into the Web world or they were too

restrictive.

In late1999, Microsoft published an XML-based protocol, called SOAP that could be used for A2Ascenarios. As it was one among many protocols suggested, it may due to the fact that IBM started

supporting SOAP in early2000 that eventually lead to a public acceptance of SOAP by the industry.

At this point in time, SOAP was just a protocol to perform complex A2A scenarios. However, it

quickly gained popularity and it was clear that there was a need for better describing and finding

the services that were implemented using SOAP. The term Web services was coined several

months later, when IBM, Microsoft, and Ariba jointly published the Web Services Description

Language (WSDL). Eventually, UDDI was also introduced, thus completing the set of

standards and protocols that make up the basis of Web services.


3/72

3

As Figure 5.1 shows, Web services builds on SOAP's capability for distributed, decentralized

network communication by adding new protocols and conventions that expose business functionsto interested parties over the Internet from any Web-connected device. As we discussed in

Chapter 1, we're moving into a new computing paradigm based on the assembly of constituent

parts. SOAP, for example, is not a stand-alone technology, but the result of synergies between

XML and HTTP. This phenomenon of emergence has not been lost on the major industry players,

who are actively working to update their existing infrastructures to keep pace with the changes

wrought by SOAP-based messaging for the global Web.

Web services is a technology and process for discovery and connection.

Web services represents an industry-wide response to the need for a flexible and efficient

business collaboration environment. Technically, it is a way to link loosely coupled systems using

technology that doesn't bind them to a particular programming language, component model, or

platform. Practically, it represents a discrete business process with supporting protocols that

functions by describing and exposing itself to users of the Web, being invoked by a remote user,

and returning a response. It includes:


4/72

4

y Describing: Web services describes its functionality and attributes so that otherapplications can figure out how to use it.

y Exposing: Web services register with a repository that contains a white pages holding basicservice-provider information, a yellow pages listing services by category, and a green pages

describing how to connect and use the services.

y Being invoked: When a Web service has been located, a remote application can invoke theservice.

y Returning a response: When a service has been invoked, results are returned to therequesting application.

The driving force behind Web services is the desire to allow businesses to use the Internet to

publish, discover, and aggregate other Web services using the global underpinning of SOAP. The

fact that the delivery of Web services requires only the Internet means that legacy code and data

as well as object systems can plug into the Web services framework. This capability is expected to

result in new products, business processes, and value chains with global scope, deliverable over

wired or wireless networks. How these will emerge is anyone's guess. But the track record of the

Web, XML, and now SOAP indicates that new technologies will rapidly emerge.

Business Motivation for Web Services

Web services are the design center that can enable your company to rapidly take advantage of

XML. Web services are based on XML and are the application model adopted by the giants of the

IT industry. Companies such as Microsoft, IBM, Sun, HP, BEA and Software AG are building the

technologies that will make the vision of Web services a reality. In this chapter, we will explore

what Web services are and how you can take advantage of them by building a simple Webservices architecture for your company. This architecture is entirely based on standards, but at the

same time allows you to reuse existing infrastructure.

By now you should have heard something about Web services. The topic is hard to avoid. The

media machine is busy cranking out the hype that has become so typical of our industry.

Revolutionary. A breakthrough. Microsoft, SAP, HP, Sun and IBM joining ranks.

Transforming software into services. The buzzwords keep flying. There is not an IT publication

today that does not spout forth a never ending flood of abbreviations like WSDL, UDDI, SOAP, RDF,

XSLT, etc. And, like with so many other technologies, the average reader is left with the question:

What is in it for me? This chapter is devoted to demystifying the topic of Web services and to

explaining what Web services are and how to apply them to increase rev-

enue for your corporation and to drive down the IT cost associated with building new products,

services and revenue channels. If the information in this chapter whets your appetite, there is

plenty of additional information available on the Internet. Just type Web services into your

favorite search engine and prepare to be blown away by the wealth of information available on

this topic. For now, the most important fact to remember is that Web services form the design

center around XML, the most important IT standard for the next two decades.


5/72

5

Lets begin with looking at the term Web services. The use of the term Web implies that Web

services are based on the World Wide Web. While this is true, it is actually quite misleading.

Although the technologies for Web services are based on the standards that have evolved in the

World Wide Web Consortium (W3C), Web services are really not limited to the Web itself.

(Remember that the Web is really the graphical user interface that made the Internet easy to use.)

Web services are a new approach for building, extending, integrating and deploying applicationsbased on XML.

This new approach builds applications that can facilitate the communication process between

humans and machines (the Web), as well as the communication process between machines (the

Internet) and the communication process between applications (application integration). By

simplifying communications between humans, machines and applications based on a common

standard (XML), Web services are an important building block on the path to total business

integration and the unbounded enterprise. (Seechapter 1.) Web services allow your IT department

to do a number of extremely significant things, including but not limited to:

reuse existing applications.

tie existing applications into a single view.

make these applications available to employees, partners and customers.

build application extensions that model your business process.

flow information across departments, business units or corporations.

If this sounds interesting to you, you should also know that these things can be accomplished very

quickly and at a very low cost when compared to traditional approaches. The main reason why

Web services are finding such rapid approval in the IT industry is their ability to reduce IT costs

while delivering the capability of building new revenue models based on your core business. In

addition, Web services can be the model for new application types that need to be deployed very

rapidly. You might wonder: Why is this different? Have we not seen these claims before? The

answer is yes, we have seen the claims, but there has been a crucial element missing in the

equation. That element is called XML the Extensible Markup Language. XML has been acceptedin the industry as the de facto standard for storing, exchanging and publishing electronic

documents. (More information about XML can be obtained in the book The XML Shockwave by

the same author.). So what does XML have do with Web services? Everything. Period.

Web services (and their benefits of cost reduction and speed of implementation) are based on the

assumption that every single element and every single buzzword in the family of Web services

technologies must work with XML, and, as a matter of fact, are driven by the concept of XML

documents. To some extent, Web services are the killer application for XML,much in the same

way the Web browser was the killer application for the Internet. The Web browser made the

Internet easy to use and spawned an explosion of new applications that allow average users to

access information. There are a lot of benefits to this approach, and the fact that more than 400million people are using the Web proves that there is ampledemand for this kind of approach.

There is a downside, however. The Web is all about graphical user interfaces to applications. What

the Web fails to accomplish is the ability for applications and machines to communicate directly

and automatically based on common standards. This is where a huge potential for internal cost

savings still remains untapped. According to research done at the Massachusetts Institute of

Technology (The Unfinished Revolution, by Michael Dertouzos) about 50 percent of the world

economy is based on office work. This is a huge number. What this means is that in order to gain


6/72

6

more productivity, we need to build more automation into our business processes. We cannot

continue to assume that a human being sitting in front of a Web browser is the answer to the

productivity challenge every company faces. We need simple, automatic, machine-to-machine and

application-to-application communication. But how? How can this be done without the huge cost

that used to be associated with integration software such as CORBA and EDI?

Enter XML. XML is the standard accepted worldwide that helps corporations and IT companiesdefine the meaning of data. Once you have defined the meaning of data, you can build XML

documents that describe themselves that can be stored, exchanged and published with a

minimum of effort. XML is the technology that enables standards-based machine-to- machine

communications and application integration, process integration and business automation. XML is

well accepted. According to Giga Corporation, about 95 percent of companies surveyed have

already started using XML, and about 30 percent of companies have put their first mission-critical

projects in place based on XML. But XML is a basic technology that needs an approach, a model

and a design center to succeed in the long term. Web services are the design center for XML based

applications.

XML is taking the world of IT by storm, and the adoption of the Web services model is becoming

the killer application for XML. To understand this a bit more, we need to look at the second part of

the term Web services, i.e. services. Like the term Web in Web services, the word services is

correct in describing what Web services seek to accomplish, but it is also misleading.

A Web Service really is a self-contained application that is fully XML enabled. A Web Service can do

the following things automatically, without requiring human intervention:

Describe a business function that is available in your corporation, for example a request for

credit.

Publish that business function to other applications or end users based on standard Internet

technology such as Web servers, application servers, integration servers or XML servers. Receive XML documents as valid input to this business function.

Store those XML documents to preserve the integrity of the request and to enable auditing and

tracking.

Evaluate and process that input.

Route that input into a processing application that could be another Web service or a traditional

application.

Produce a result, for example the approval of credit.

Store that result to preserve the integrity of the output and to enable auditing and tracking.

Route the result to the consumer of the business function, which could be a user, a device such

as a mobile phone, a PC, a mainframe or any other entity that can be reached over the Internet.

Web Services

Introduction

In this chapterwe are going to see following,


7/72

7

1. What is a Web Service?2. Why we need a Web Service?3. ASP.Net Web Services4. Use Data in Web Services

What is a Web Service?

The Internet is quickly evolving from today's Web sites that just deliver user interface pages

to browsers to a next generation of programmable Web sites that directly link organizations,

applications, services, and devices with one another. These programmable Web sites

become more than passively accessed sites - they become reusable, intelligent Web

Services. They allow different applications to share business logic over the network.

The technical definition of a Web Service is programmable application logic accessible

via Standard web protocols.

Programmable Application Logic: A Web Service is Application non-specific. The application

logic can be implemented by components, by PERL scripts, or by any other mechanism thatsupports XML.

Standard Web Protocols: Web Services use Internet transport protocols such as SOAP, HTTP

and SMTP.

Why we need a Web Service?

Server and client need to understand following:

y Implementation details of a particular service,y Service deployment,y Security types and trusts, etc.

The common language runtime provides built-in support for creating and exposing Web

Services, using a programming abstraction that is consistent and familiar to both ASP.NET

Web Forms developers and existing Visual Basic users. The resulting model is scalable and

extensible, and supports open Internet standards (HTTP, XML, SOAP, WSDL). Therefore it

can be accessed and consumed from any client or Internet-enabled device.

One important feature of the Web services based computing model is that a client need not know

the language in which XML Web services are implemented. The client just needs to know the

location of an XML Web service and the methods that the client can call on the service.

Web services use XML-based messaging to send and receive data, which enables heterogeneous

applications to interoperate with each other. You can use Web services to integrate applications

that are written in different programming languages and deployed on different platforms. You can


8/72

8

deploy Web services within an intranet as well as on the Internet. While the Internet brings users

closer to organizations, Web services allow organizations to integrate their applications.

Web Services Infrastructure

The Web services infrastructure provides several components that enable client applications to

locate and consume Web services. These components include the following:

XML Web services directories (UDDI)

These directories provide a central place to store published information about Web

services. The Universal Description, Discovery, and Integration (UDDI) specifications define

the guidelines for publishing information about Web services. The XML schemas associated

with UDDI define four types of information that you must publish to make your Web

service accessible. This information includes business information, service information,

binding information, and service specifications. Microsoft provides one such directory

service, which is located at http://uddi.microsoft.com.

Web services discovery. (WSDL)

Using this process, clients locate the documents that describe a Web service using WSDL.

The discovery process enables clients to know about the presence of a Web service and

about the location of a particular XML Web service.

Web services description.

This component provides information that enables you to know which operations to

perform on a Web service. The Web service description is an XML document that specifies

the format of messages that a Web service can understand.

Web service wire formats.

To enable communication between disparate systems, Web services use open wire

formats. Open wire formats are the protocols that can be understood by any system that is

capable of supporting common Web standards, such as HTTP and SOAP. The HTTP-GET and

HTTP-POST protocols are the standard Web protocols that allow you to send parameters asname-value pairs. The HTTP-GET protocol allows you to send URL-encoded parameters as

name-value pairs to an XML Web service. The HTTP-GET protocol requires you to append

the parameter name-value pairs to the URL of the Web service. You can also use the HTTP-

POST protocol to URL-encode and pass parameters to the Web service as name-value

pairs. However, the parameters are passed inside the actual request message and not

appended to the URL of the Web service.


9/72

9

The SOAP protocol allows you to exchange structured and typed information between the

applications on the Internet. The SOAP protocol consists of four parts. The first part is mandatory

and defines the envelope that contains the message. The SOAP envelope is the basic unit of

exchange between the processors of SOAP messages. The second part defines the optional data

encoding rules that you use to encode application-specific data types. The third part defines the

request/response pattern of message exchanges between Web services. The fourth part, which isoptional, defines the bindings between the SOAP and HTTP protocols.

How components of the XML Web services infrastructure enable clients to locate and call methods

on XML Web services.

When a client accesses a UDDI service to locate a Web service, the UDDI service returns a URL to

the discovery document of the Web service. A discovery document is a .disco file, which contains

the link to the resources that describe a Web service. A discovery file is an XML document that

enables programmatic discovery of a Web service. After the client receives the URL to the


10/72

10

discovery document, the client requests a server, which returns the discovery document to the

client. The contents of a sample discovery document are shown in the following code.

XML

The client uses the information in the discovery document and requests a server to return the

service description of a Web service. The service description is a .wsdl file and enables a client to

interact with a Web service.

Next the client invokes methods on an XML Web service.

The process of communication between a client and an XML Web service is similar to a remote

procedure call (RPC). The client uses a proxy object of the XML Web service on the local computer

to call methods on the Web service.

Figure shows the process of communication between a client and a Web service.


11/72

11

Client and Web service communication

As shown in Figure, the interaction between a client and a Web service consists of several phases.

The following tasks are performed during these phases:

1. The client creates an object of the Web service proxy class on the same computer on whichthe client resides.

2. The client calls a method on the proxy object.3. The Web services infrastructure on the client system serializes the method call and

arguments into a SOAP message and sends it to the Web service over the network.

4. The infrastructure on the server on which the Web service resides deserializes the SOAPmessage and creates an instance of the Web service. The infrastructure then calls the

method with the arguments on the Web service.

5. The Web service executes the method and returns the value with any out parameters tothe infrastructure.

6. The infrastructure serializes the return value and any out parameters into a SOAP messageand sends them to the client over the network.

7. The infrastructure on the client computer deserializes the SOAP message containing thereturn value and any out parameters and sends them to the proxy object.

8. The proxy object sends the return value and any out parameters to the client.


12/72

12

To build Web services that the clients can consume, you use the ASP.NET infrastructure, which is

an integral part of the .NET Framework. Visual Studio .NET provides tools to build, deploy, and

publish your Web services using ASP.NET.

Benefits of Web Services

Experts and visionaries believe that the benefits of XML Web services will be instrumental in

propelling explosive business growth over the next few years. One of the major benefits is Web

services' ease of integration. You will easily integrate your software with other pieces of software.

You can run on all kinds of machines, from the desktop to the mainframe, either within your

enterprise or at external sites. This ease of integration will enable tighter business relationships

and more efficient business processes.

With Web services readily available, and as the pool of XML Web services grows, you will be able

to find software modules that can be integrated into your own application, by finding it and

integrating it through XML Web services. Integrate with existing Web services instead of

reinventing them. The bottom line is that you will be able to develop applications much faster

than before.

An integral part of the XML Web services programming model, is the ease of integration with

external data sources. No longer does each application need to copy and maintain external data

sources. You can request and get information in real time, and transform it to your particular

format. This will allow you to deliver individualized software and services, while your maintenance

burden is reduced.

Consumers will enjoy ease of use when using XML Web services-based applications. XML Web

services link applications, services, and devices together. Using Web services will be an integrated

experience that excels in its simplicity. XML Web services give users the ability to act on

information any time, any place, and from any smart device.

Businesses will love Web services because it will force them to streamline their processes. All

suppliers will use the same language to describe their offerings. An XML Web service is a simple,

reliable way to blend existing systems with new applications and services.

Microsoft is already sporting several commercial applications that were written in a record speed,

thanks to the use of XML Web services. The first one is from Dollar Rent-A-Car. In two weeks,

programmers built, tested, and deployed a Web Services-based solution that translates

reservation requests and data between the company's mainframe-based reservation system and

an airline partner's UNIX servers. Dollar can now reuse the same integration model to link their

reservation system with other airline or hotel partners. The second case is expedia.com. This is a

site that will find you the lowest price itinerary. They are now in the process of transforming

itineraries into communication centers. These centers are Web services that users can access to


13/72


14/72

14

Personal service

What is B2C?

B2C Commerce: Interactions relating to the purchase and sale of goods and services between a

business and consumerretail transactions.

Novelty is that retail transaction is done on the Internet, rather than a brick and mortar

store location.

Technical evolution of B2C from brick and mortar model not new.

Problem 1: I want to use your Web Service.

y Where can I find it?y What messages are accepted / generated? What syntax?y How should they be encoded?

Problem 2: Many others also want to offer Web Services

y Need standard format for describing Web Services

Revenue Models

Sell goods and services and take a cut (just like B&M retailers).(e.g., Amazon, E*Trade, Dell)

Advertising

Ads only (original Yahoo)

Ads in combination with other sources

Transaction fees

Sell digital content through subscription. (e.g., WSJ online, Economist Intelligence

Wire)

Open Issues in E-commerce

Globalization


15/72


16/72

16

Web Services Description Language

y Defines the contract/interface for using a Web Service:o URIo Messages accepted & generated (Syntax and datatypes)o Access protocolo Message encoding

y Standard format (use of XML)Web Services Description examples

1. get a temperature for a given US town2. set the temperature for a given US town3. Web Services Description example4.5.


17/72

17

6. targetNamespace="http://weather.com/USservice"7. [... xmlns declarations ...]>8.9. 10. 12. 14. 15.16.17.18. 20.21.22. 23.24.25.26. 27. 28. 29. 30.31.32.34. 35. 36. 38. 39. 40. 41. 42.

43. 44. 45.46.47.48.


18/72

18

50. 52. 53.54.55.56.59.60.61. 63. 64.65.66.67. 68. 69. 70.71.72.73.75. 76. 77. 79. 80. 82. 83. 84.85.86.

87. 89. 91. 92.93.


19/72

19

94.

What is CORBA?

Common Object Request Broker Architecture (CORBA) is a competing distributed systems

technology that offers greater portability than remote method invocation. Unlike RMI, CORBA isn't

tied to one language, and as such, can integrate with legacy systems of the past written in older

languages, as well as future languages that include support for CORBA. CORBA isn't tied to a single

platform (a property shared by RMI), and shows great potential for use in the future. That said, for

Java developers, CORBA offers less flexibility, because it doesn't allow executable code to be sent

to remote systems.

CORBA services are described by an interface, written in the Interface Definition Language (IDL).

IDL mappings to most popular languages are available, and mappings can be written for languages

written in the future that require CORBA support. CORBA allows objects to make requests of

remote objects (invoking methods), and allows data to be passed between two remote systems.

Remote method invocation, on the other hand, allows Java objects to be passed and returned as

parameters. This allows new classes to be passed across virtual machines for execution (mobile

code). CORBA only allows primitive data types, and structures to be passed - not actual code.

Under communication between CORBA clients and CORBA services, method calls are passed to

Object Request Brokers (ORBs). These ORBs communicate via the Internet Inter-ORB Protocol

(IIOP). IIOP transactions can take place over TCP streams, or via other protocols (such as HTTP), in

the event that a client or server is behind a firewall. The following diagram shows a client and aservant communicating.

CORBA client sends a request through its local

ORB to a remote ORB's servant

CORBA servant sends back a response to a

remote ORB

Limitations of CORBA


20/72

20

Describing services require the use of an interface definition language (IDL) which must be

learned. Implementing or using services require an IDL mapping to your required language -

writing one for a language that isn't supported would take a large amount of work.

IDL to language mapping tools create code stubs based on the interface - some tools may not

integrate new changes with existing code.

CORBA does not support the transfer of objects, or code.

The future is uncertain - if CORBA fails to achieve sufficient adoption by industry, then CORBA

implementations become the legacy systems.

Some training is still required, and CORBA specifications are still in a state of flux

Not all classes of applications need real-time performance, and speed may be traded off against

ease of use for pure Java systems.

Service-Oriented Architectures are an approach to distributed computing that thinks of software

resources as services available on a network. Such architectures are nothing new; CORBA and

DCOM are familiar examples. However, these older examples of service-orientation suffered from

a few difficult problems. First, they were tightly coupled, which meant that both ends of each

distributed computing link had to agree on the details of the API. A code change to a COM

object, for example, required corresponding changes to the code accessing that object. Secondly,

such Service-Oriented Architectures were proprietary. Microsoft unabashedly controlled DCOM,

and while CORBA was ostensibly a standards-based effort, in practice, implementing a CORBA

architecture typically necessitated the decision to work with a single vendor's implementation of

the specification.

Web services is an evolutionary development that improves upon DCOM and CORBA's

weaknesses. What is new about today's Service-Oriented Architectures built with Web services is

that they are standards-based and loosely coupled. The reliance upon universally accepted

standards like XML and SOAP provides broad interoperability among different vendors' solutions,

and loose coupling separates the participants in distributed computing interactions so that

modifying the interface of one participant in the exchange does not break the other. The

combination of these two core principles means that companies can implement Web services

without having any knowledge of the consumers of those services, and vice versa. The Service-

Oriented Architectures we will discuss are the standards-based, loosely coupled kind, which wewill refer to as SOAs.

CORBA and DCOM: A Feature Comparison

In the following sections, we define each enterprise quality and compare the levels of support

currently


21/72

21

available in CORBA and DCOM specifications and products. Although this list is not comprehensive,

it

stands as a reasonable baseline for middleware comparison. These features are not necessarily

listed in

order of priority. Instead, each is treated independently, though many are highly interdependent.

Finally,individual ratings are given at the end of each section to indicate the relative levels of enterprise

readiness.

A + implies full readiness, 0 connotes marginal status, and - indicates a failure to meet the

overall

needs of the enterprise.

Interoperability

Cross-Language Support

Cross-language support is one part of the critical interoperability capabilities required of

enterprise systems. While languages such as C++, Visual Basic, and Java are on the rise, COBOL is

still often cited as the most widely used programming language, with an estimated three million

active programmers.

CORBA

CORBA was designed from the ground up to be language and platform independent through the

use of a common Interface Definition Language (IDL). Now an ISO standard, OMG IDL provides a

common notation for describing cross-platform, cross-language application program interfaces

(APIs). IDL is used to define the interface of the component, not the inner workings.

For this, other standard programming languages are used. IDL interfaces are translated to

standard languages through mappings. Currently, IDL has been mapped to C, C++, Smalltalk, Ada,

OLE (Visual Basic, PowerBuilder, Delphi, etc.), Java, and soon to Eiffel and Objective C. The benefits

of interoperability are not without costs however. IDL was never meant to substitute for a general-purpose language. Instead, it was designed to express generalized interfaces. IDL limits the

language data types to a least common denominator that can be supported by all languages.

Although some of the language-specific data types are not directly usable, IDL does permit an

any type to overcome this obstacle.

DCOM

DCOMs language portability (heterogeneity) is based upon a binary standard. Binary

compatibility is accomplished at the ones-and-zeros level, an area that has previously been the

domain of computer language compilers and interpreters. To guarantee compatibility at this level,

the way each language is translated to machine binary code must be controlled. This can present a

few obstacles, but also has its benefits. First, there are fundamental differences in how languagesare translated. Since some languages are compiled and others are interpreted, binary

compatibility requires that components support all possible translation variations. Second, there

are many compilers/interpreters for a given language, each taking unique approaches to code

translation. Finally, specifying compatibility at such a low hardware level creates vulnerabilities

due to advances in hardware itself.

Microsoft has been successful in controlling the mainstream development tools in the desktop

arena for DCOMs predecessor, COM. COM is currently supported by the popular array of


22/72

22

Microsoft products as well as Java, PowerBuilder, Delphi, and Micro Focus COBOL. Distributed

COM, however, requires additional support from Microsoft or a third party that ports DCOM (see

Software AG below).

Summary: Both CORBA and DCOM provide extensive support for multiple programming

languages, though they use different techniques.

META Group ConsultingEnterprise Criterion Ratings

Interoperability CORBA DCOM

Cross-Language Support + +

Cross-Platform Support

The middle in middleware often refers to the synergistic connection between disparate

enterprise IT resources. Until it is feasible for all enterprise resources to be hosted entirely on

homogenous hardware platforms, middleware must support new and legacy platforms and the

freedom to mix them as required.

CORBA

Cross-platform support has always been a central focus of CORBA. ORBs currently exist for more

than 30 platforms and supports even more Microsoft operating systems than DCOM. Orbix, one of

the leading ORB products, supports 20 platforms itself.

DCOM

DCOM has approached cross-platform support as an afterthought. In 1993, Microsoft approached

a German company, Software AG, to port DCOM to other platforms. Software AG has ported

DCOM to several Unix variants; however, the port does not include many of the components of

DCOM. For example, many critical supporting technologies have not been ported, the most

important of which are MTS and MSMQ. Without MTS and MSMQ, DCOM is simply not a viable

enterprise middleware. DCOM has also been ported to Macintoshes and DEC Alphas that run

Windows NT. Many other ports are currently in the works (Open VMS, Digital Unix, HPUX, Solaris,

IBM OS/390, IBM AIX, and Linux).Summary: It should be clear by now that in order to cast either of these technologies into the

enterprise role, a comprehensive collection of critical infrastructure services must be considered

for each of the required platforms. For DCOM, this means exploiting the combined synergies of

COM, MTS, MSMQ, and clustering them together to fulfill the needs of enterprise computing.

Without MTS, for example, DCOM will be unable to fulfill these needs. By way of comparison,

CORBA-based products typically provide each of their services on all supported platforms. As such,

ORBs are much further ahead in their support for heterogeneous enterprise environments.

Enterprise Criterion Ratings

Interoperability CORBA DCOM Cross-Platform Support + -

Network Communications

Robust support for enterprise network communications requires that middleware seamlessly

provide interoperability with many disparate networked systems. To enable this, the middleware

should be protocol transparent.

CORBA

The predominant CORBA networking model for cross-ORB communication is based on a form of

TCP known as IIOP (Internet Inter-ORB Protocol), a connection-based protocol. IIOP was

specifically designed to ensure that all ORBs use a common communications protocol. Internal to a


23/72

23

particular ORB, however, other protocols are possible. ORB products, similar to DCOM, are usually

remote procedure call (RPC)-based.

META Group Consulting 9

DCOM

Initially, DCOM utilized UDP/DCOM, a connectionless protocol that is based on the OSFs DCE RPC

specification with some changes. DCOM now offers a TCP protocol configuration as an option,although by using this, many efficiency features are sacrificed.

Summary: CORBA has established the lead in common network protocol support through the de

facto IIOP standard. DCOM provides protocol options, but does not support them equally.

Enterprise Criterion Ratings Interoperability CORBA DCOM

Network Communications + 0

Common Services

Common services form the base infrastructure of the middleware. These services are married to

the individual patterns of business in an enterprise setting. For example, a banking model is highly

transaction oriented and requires secure transaction support as a fundamental middleware

service. To this end, most organizations require a number of key services. It should be understood,

however, that not all services are equally important to all enterprises. Where more than one

service is required, it should be fully compatible and interoperable with the others. Using the OMG

specification terminology, we consider the following services as a minimal set for enterprise

middleware: Transactions, Directory, Messaging, Security, and interoperability. The CORBA road

map provides ORB vendors with a path for service interoperability. This interoperability is required

to integrate the best available third-party services across platforms. Microsofts approach is less

explicit, with service interoperability implied for the NT platform only. CORBA and DCOM products

support these basic services in various degrees.

CORBA

The OMG has concentrated on the development and integration of key architectural services.

Their technology adoption process is specifically aimed at ensuring that services are implementedin an interoperable manner. The CORBA specification defines 15 services, though not all

commercial ORB products support the complete set. One exception to this is IBMs COS (Common

Object Services), a suite of the full 15 CORBA services that is compatible with DSOM

and other brokers.

DCOM

DCOM services are less defined from an architectural standpoint, though there are many CORBA

equivalents. DCOM currently offers a limited naming service, transactions, and security integration

with NT. Other services such as MSMQ and clustering are becoming available, but are not formally

integrated into the DCOM specification.

Summary: Full-service support is not yet available from DCOM or CORBA products. At present,CORBA products have the lead in the number, maturity, and scope of enterprise-required services

that are made available to both new and legacy applications. Enterprise Criterion Ratings

Interoperability CORBA DCOM

Common Services 0 -


Reliability

Transactions


24/72

24

Transaction support has been the focus of both middleware technologies in recent years. During

1997, the gaps in both camps were significantly closed.

CORBA

CORBAs Object Transaction Service (OTS) specification offers a range of services for distributed

transaction support. These services extend the range of traditional flat transactions to support

both flat and nested transactions (since nested transactions break up transactions into hierarchiesof sub-transactions, this offers developers the flexibility for failures in a subtransaction to be

retried using an alternative method, while the main transaction can succeed).

OTS enables both ORB and non-ORB applications to participate in the same transaction, so that

object transactions and procedural transactions (that support X/Opens DTP standard) can

interoperate. It also supports transactions across heterogeneous ORBs, so that multiple ORBs can

participate in the same transaction. Also, a single IDL interface supports both transactional and

non-transactional implementations. To make an object transactional, developers use an interface

that inherits from an abstract OTS class. Taken together, the interfaces for OTS, plus the

Concurrency and Control service and Transactions, offer full commit, rollback, locking and other

capabilities, enabling ORB vendors supporting it to offer distributed transaction capabilities. A

number of the ORB implementers have offered links to tools from traditional TP monitors, and

OTS enables them to incorporate these capabilities directly into the ORB and distribute them.

The goal of integrating best-of-breed transaction products has been widely realized in the ORB

marketplace over the last year. Tuxedo, the most scalable TP monitor for highly distributed

environments, has been successfully integrated with two prominent ORBs. In addition, Visigenic

and Hitachi have integrated TPBroker and Iona has integrated Transarc in OrbixOTS.

DCOM

Microsoft also has been aggressively attacking transaction support in the form of its Microsoft

Transaction Server (MTS). As a fully integrated transaction service, MTS has great potential for at

least the Wintel environment, and is positioned by Microsoft as an extension to DCOM. With MTS,

transactions are supported implicitly, thereby freeing the developer from the complexity ofdealing with transaction services directly. This enables MTS to preserve the

component model. In addition, MTS provides a declarative security model. MTS is in an early state

of maturity, however. Few examples are available to assess the relative scalability of MTS, and it

has not been offered for the cross-platform environment to date.

Summary: We continue to believe that CORBA will remain the leading-edge middleware

transaction model for networked objects, with DCOM MTS transaction support suitable for low-

end processing but gaining ground quickly.


Reliability CORBA DCOM

Transactions + 0Messaging

Reliable transmission and receipt of messages is a foundational quality of distributed middleware.

Without it, the electronic commerce (EC) systems of tomorrow will ultimately fail in delivering

expedient and reliable services to the increasingly demanding marketplace. Effective messaging

requires four important qualities: reliability, user convenience, system convenience, and

performance.



25/72

25

In messaging, reliability means nothing less than guaranteed delivery. To guarantee delivery of

anything requires a reliable middleman, not unlike the US Postal Service. Rain or shine, the postal

service can be relied upon to deliver mail to its eventual destination. The operational word here is

eventual. If the weather becomes too severe, postal workers do not throw the mail away; they

hold onto it until the weather permits delivery. The same quality is required of middleware.

User convenience, system convenience, and performance are highly interrelated qualities. Userconvenience means that the sending and receiving parties are not forced to be at a particular

place and time to send and receive messages. This is known in technical terms as asynchronous

communication. With asynchronous communication, a sender or system does not have to wait

until the message is sent AND received before being able to do other work. This convenience

enables all parties sender, system, and receiver to continue performing useful work,

regardless of each others current situation. To support these needs, distributed middleware

requires a robust message queuing system. Message

queues support asynchronous transmission by providing a persistent queue (message queue) as a

temporary message holding area. Again, CORBA and DCOM approach messaging in different ways,

but both technologies are geared toward the same needs outlined above.

CORBA

The early CORBA specifications addressed messaging from a more primitive standpoint. The Event

Service was the basis of many messaging protocols such as push-pull and pull-push. ORBs typically

provided two avenues for messaging: the Event Service primitives or a proprietary mechanism.

The OMG recently addressed a more robust messaging model in the CORBAservices specification.

This specification addresses the asynchronous communication option that is required by

enterprise-grade applications; however, it has not been adopted yet. Many ORB products have

implemented extensions to the CORBA Events service that provide reliable messaging. For

example, in early 1996, Orbix announced their OrbixTalk Reliable Multicast Protocol, which

provides reliable sequencing and delivery of messages. Some ORB implementations have

integrated an enterprise-grade messaging service on par with standalone Message-OrientedMiddleware (MOM). IBMs ComponentBroker is one example of integration with MQSeries, a

leading MOM product. Iona has been successful in demonstrating GIOP over MQSeries. BEA has

also announced intentions to integrate its newly acquired MessageQ into the Iceberg product.

DCOM

Formally, DCOM does not directly support asynchronous communication. Microsofts answer to

reliable messaging is a separate offering titled Microsoft Message Queue Server (MSMQ) or

Falcon. On the plus side, MSMQ promises to support each of the important qualities of reliable

messaging and more. Unfortunately, MSMQ is not a fully integrated part of DCOM at this time and

has the same interoperability limitations as MTS. Software AGs EntireX product, a cross-platform

port of DCOM, is integrated with the proprietary EntireX Message Broker service. This service doesnot rely upon MSMG and provides persistent storage of messages to enable asynchronous

communication between clients and servers.

Summary: Reliable messaging is now being recognized by both CORBA and DCOM as a critical

service for the enterprise. CORBA has been augmented with leading MOM products, but full inter-

service integration has not yet been achieved. DCOM has also been augmented with early MOM

functionality, but also lacks full integration with other complementary services and is again, not

available across a wide range of platforms. Enterprise Criterion Ratings


26/72

26

Reliability CORBA DCOMMessaging 0 -


Security

Clearly, security is one of the key considerations for enterprise computing. Most organizations

cringe at the prospect of opening up the mainframe to the Internet. Distributed applications that

are exposed to the Web simply cannot tolerate security breaches.CORBA

The CORBA Security service is one of the most comprehensive security specifications available for

distributed computing. The 262-page specification was jointly adopted with the Time Service and

covers nearly every conceivable aspect of security, including integrity, accountability, availability,

confidentiality, and non-repudiation. It also recognizes that differing levels of security needs exist

in an enterprise environment. The service defines three (0-2) levels of security compliance,

ranging from non-aware ORB products to those that require the entire range of services (access

control, delegation, auditing, authentication, and policy implementation).

ORB products differ widely in their support for security. For example, ICLs DAIS product was the

first ORB to offer CORBA security conforming to Kerberos and the GSS API standards. Orbix

provides both the SSL-IIOP standard (secure encrypted communications over the Internet) and an

implementation of the CORBA Security Level 1 service. Finally, Visigenic has recently partnered

with MITRE Corporation spin-off Concept Five to deliver the first ORB complying with

CORBA Level 2 security.

DCOM

DCOM utilizes NT mechanisms as the basis of its security support. NT Version 3.5 has been rated

level C2 by the National Computer Security Center and ensures a comprehensive array of security

controls such as discretionary access, authentication, and auditing. DCOM also provides a

CryptoAPI to enable advanced encryption of information. This service requires the support of a

Cryptographic Service Provider (CSP) that is provided with NT. Without question, the combination

of NT, MTS, and COM can provide a comprehensively secure environment; however, becauseDCOMs security managers are NT dependent, this support is limited to Windows/NT platforms.

Summary: CORBA and DCOM are both building comprehensive security mechanisms. To CORBAs

credit, the recognition of a wide variety of security services will provide more solutions to the

differing needs of the enterprise. For DCOM, the cooperation of the operating system is

paramount to providing high levels of security. Although from different directions, both

middleware technologies are reaching critical mass in their support for secure distributed

computing. Enterprise Criterion Ratings


Security 0 0

Directory ServiceAn essential feature of any middleware is the ability to keep track of the location of key services in

the distributed network space. This lessens the burden of each application (provides location

transparency) and, more importantly, provides for load balancing and failover services. Examples

of working directory services include; DNS, X.500, Novell NDS, and Microsoft NTDS, though each is

accessed by a specialized interface.


CORBA


27/72

27

The OMG has specified the Naming Service for just this purpose. Similar to a white pages

directory, the Naming Service permits a component to look up a service by name. The Naming

Service was designed to allow the use of conventional directory services such as those identified

above. These services are wrapped by a higher-level service interface that masks idiosyncrasies

from the developer.

VisiBroker offers a CORBA-compliant naming service that is fault tolerant (self-recovering) andpersistent (survives shutdowns and abnormal failures), and supports federated name spaces.

Orbix also provides a fault-tolerant naming service.

DCOM

Microsofts answer to this need is called the Active Directory Service (ADS). This service is said to

combine the best features of X.500 and DNS. Like the OMG Naming Service, ADS intends to

abstract differences between various directory services by providing one standardized interface.

ADS Version 1.0 is offered with NT 4.0, with the full ADS capability to be integrated in NT 5.0. The

ADS Interface (ADSI) is based on DCOM with specific offerings from directory service providers

being implemented as DCOM objects.

Summary: Both CORBA and DCOM are beginning to support sophisticated directory services on

par with previous enterprise tested incarnations such as NDS and DNS. Enterprise Criterion

Ratings


Directory Service 0 0

FaultTolerance

Middlewares ability to heal itself in the event of reasonable failure is essential for most

enterprise applications. There are many supporting mechanisms that contribute to this capability.

Asynchronous messaging (discussed under Messaging) is one example. Service pools and

redundant failover mechanisms also enable graceful recovery and increase the fault tolerance and

reliability of middleware. Finally, a reliable directory service is needed to find and connect backup

services in the event of failure.CORBA

The CORBA specification does not directly support fault-tolerance services; however, many ORB

vendors have provided this support. For example, Visigenics VisiBroker provides symmetric

failover support to automatically bind to another object server on a separate host in the event of

service failure.

Most ORBs provide a simple timeout mechanism for detecting dead or disconnected clients. This

approach alone is not sufficient for highly fault-tolerant applications.

DCOM

Basic support for fault tolerance is provided at the protocol level. DCOM utilizes reference counts

augmented by keep alive messages or pinging as an essential component of the DCOM objectlife cycle. It requires the successful transmission and receipt of a heartbeat every two minutes

between a client and server. If three consecutive heartbeats are missed, the server declares the

client dead and decrements the reference count. According to a recent Web FAQ1 maintained by

AT&T Labs (updated Nov. 5, 1997), DCOM does not support configurable times, so clients may not

detect problems for a considerable period of time (six minutes). Further, if a distributed

component gets into a continuous loop, there is no automated way to detect a problem, because


28/72

28

the 1 COM Reliability FAQ; http://akpublic.research.att.com/~ymwang/resources/COM-R-

FAQ.htm


heartbeats will still be sent. Finally, this approach utilizes significant network resources and may

not scale well for large numbers of connections. Microsoft has taken positive steps to streamlinethis approach and has employed piggybacking, grouped pings, and delta pinging to reduce

network traffic. Anything beyond this generally requires extensive customization on both the

middleware and application side.

Summary: Both DCOM and CORBA do not directly support robust fault tolerance; however, with

sophisticated customization, it can be provided. For DCOM, it is not clear whether such

customization is possible across a heterogeneous platform environment, because most

workarounds currently require the support of NT or Windows 95 components.Enterprise Criterion

Ratings


Fault Tolerance 0 0

Performance

Scalability

We generally define scalability as the middlewares ability to perform when the size of the

problem increases. Middleware performance can be highly variable depending on how it is used.

For example, component granularity is one of the most significant drivers of performance stress.

In other words, as the pieces get smaller, so does sheer volume causing the middleware

substrate mechanisms to work harder. As this occurs, the need arises for middleware mechanism

tuning in ways that conventional database products have supported. Finally, middleware

performance is very costly to measure, since only in vitro modeling can provide a reasonable

capacity estimation.

There must be compelling evidence, via current implementations or anecdotal data, that indicatethe middlewares ability to scale through various scenarios. These scenarios may include numbers

of objects or users. Key areas where impacts are most likely are found in services that commonly

aggregate components such as naming services or interface repositories. Finally, middleware must

able to support threads to allow parallel processing of work.

CORBA

As a specification, CORBA does not address specific scalability services aside from providing for the

transparent distribution of processing. Instead, individual ORBs deal with this problem in one of

two ways:

Threading Many ORBs provide thread-safe libraries that use each operating systems native

thread model. This enables threads to be created for clients, objects, or even specific method callsof an object. In addition, several ORB products also support thread pools. Filters can also be used

to balance processing based on current loading.

Tuning ORB products provide various internal tuning mechanisms to enable optimization for

specific situations. For example, internal memory representations can be changed to order

references by most frequently used or other criteria that suit the specific conditions.

DCOM


29/72

29

DCOM offers similar scalability mechanisms such as parallel processing and threading. As with

CORBA, DCOM features are not transparently supported, and require detailed knowledge of

client/server interactions to implement.


Thread pools DCOM utilizes thread pool managers to maximize scalability however, Windows

NT symmetric multiprocessing is required to support this feature. Summary: Both middlewareproducts are relatively nascent in their support for highly scalable enterprise applications. There

are, however, a growing number of large-scale ORB implementation examples in the investment,

aerospace, and telecommunications industries. In addition, indirect evidence of scalability can be

inferred when combining ORBs with enterprise-grade products such as commercial TP monitors

and MOM. Concrete evidence of large-scale DCOM enterprise applications is not readily available

at this time. Enterprise Criterion Ratings

Performance CORBA DCOM

Scalability 0 -

Viability

Product Maturity

Despite the current fragmented condition of middleware offerings, we believe IT organizations

should be consumers of middleware components, not producers. As of this writing, the best way

to manage the massive complexity of middleware is through the purchase and customization of

commercial frameworks that organize their flexibility into structured application packages. Such

frameworks go beyond the primitive and complex services that CORBA and DCOM can provide but

still require a minimum maturity level from each.

CORBA

Many commercial ORB products are in their third generation of development. As such, we are

beginning to see a critical mass of services (Directory, Messaging, Transactions, and Security) in

several leading products. Although the OMG specification is explicitly designed to insure these

services are well integrated, no single ORB vendor has brought them all together in strict CORBAcompliance. Irrespective of this, ORBs are now being used for enterprise systems in many

demanding industries, including telecommunications, aerospace, and investment.

DCOM

The arrival of the predator services (Falcon, Viper, Wolfpack, and Active Directory) represents

Microsofts recognition of what must be in place in an enterprise setting. Like the leading ORB

products, these services are not fully integrated (even in the NT only environment) and are not

explicitly part of DCOM. What is worse, platform interoperability is only just appearing on the

DCOM radar screen and will likely be the last piece to fall into place.

Summary: Products from both DCOM and CORBA are only just beginning to aspire to the so-called

heavy lifting demands of the enterprise. At the end of the day, representative products fromboth middleware camps require a tremendous amount of financial fortitude and technical

expertise from the adopting enterprise to be successful.


Viability CORBA DCOM

Product Maturity 0 -

Vendor Outlook


30/72


31/72

31

Discovery: fetch descriptions of providers. UDDI, WS-Inspection.

Description: describe services. WSDL.

Packaging: is serialization or marshaling. SOAP.

Transport: application-to-application communication. HTTP, SMTP, TCP, Jabber.

Network: network layer. TCP/IP

Communications Layer

Web Services are essentially transport-neutral.

A web service message can be transported using HTTP or HTTPS, as well as more

specialized transport mechanisms, such as e.g. JMS.Web services insulate the designer

from most of the details and implications of the message transport layer.

Messaging Layer

SOAP = Simple Object Access Protocol

A protocol to exchange structured information in a distributed environment.


32/72


33/72

33

WS Specifications:

1) A series of smaller, purpose-focused specifications dealing with narrow problems

(security, transactions, etc.) in isolation.

2) Each WS specification is designed to be composed with the others.

3) WS designers determine which specifications their system needs and implement them

accordingly.

WS-I Organization

Web Services Interoperability organization (WS-I):

1) WS-I is to standardize combinations of WS specifications that can be used to increase

the level of interoperability between web services.

2) WS-I promotes the Basic Profile - implementation guidelines for how non-proprietary

WS specifications, such as SOAP, WSDL, UDDI, should be used together for best

interoperability.


34/72

34

Current Web services stack

In this section, I will recap the standards and the tools used to implement them at each layer in

the Web services stack. We start from the bottommost layer, transport, and work my way up one

layer at a time until I reach the final layer, service flow.

Transport layer

As you can see in Figure 2, the transport layer is the foundation of the Web services stack. Web

services must be invoked by a service client so they can be accessible to a network. Web services

that are publicly available run over the Internet. Only the authorized users within an internal

organization can view intranet-available Web services, while unauthorized users in the outsideworld cannot. It is possible to create extranet-based Web services to allow legitimate users access

to them on more than one intranet.


35/72

35

Figure 2. Original Web services stack

The Internet protocols that can be supported by this stack are HTTP and, to a lesser extent, SMTP(for electronic mail) and FTP (for file transfer). Intranet domains use middleware call

infrastructures, such as IBM's MQSeries, and CORBA (the Common Object Request Broker

Architecture). The latter relies on a protocol called the Internet Inter-ORB Protocol (IIOP) for

remote objects.

MQSeries name changes

Note that the following MQSeries products have been renamed as part of the consolidation of

IBM's middleware product portfolio:

y MQSeries has been renamed WebSphere MQ.y MQSeries Integrator has been renamed WebSphere MQ Integrator.y WS BtoBi PAM has been renamed WebSphere Partner Agreement Manager.

XML-based messaging layer

In this layer, SOAP is the messaging protocol for XML. It is built upon the lower layer -- transport--

meaning that SOAP is used singly or in combination with any transport protocols. All SOAP

messages support the publish, bind, and findoperations in the Web services architecture. SOAP

comprises three parts: an envelope to describe the content of a message, a set of encoding rules,

and a mechanism for providing remote procedure calls (RPCs) and responses.

IBM, Microsoft, and others submitted SOAP to the W3C as the basis of the XML Protocol Working

Group. When the W3C releases a draft standard for the XML protocol, the Web services

architecture stack will migrate from SOAP to the XML protocol.

Service description layer


36/72

36

Service description provides the means of invoking Web services. WSDL is the basic standard for

defining, in XML format, the implementations and interfaces of services. This means that WSDL

divides a service description into two parts: service implementation and service interface. You

must create a service interface before you can implement WSDL.

Service publication layer

You need other service description documents to complement WSDL. You can use UDDI data

structures to describe business context, for example. You can make a WSDL document available to

a service client at any stage of the service client's life cycle. When this happens, the stack moves

up to the next layer, service publication. At this layer, the service provider can send a WSDL

document directly to a service client via e-mail, for example. This action is known as direct

publication. The service provider can also choose to publish the WSDL document to a host-local

WSDL registry, or to a public or private UDDI registry. IBM's WSCA specifies how the definitions for

two components of WSDL can be derived from the UDDI entries.

Service discovery layer

Service discovery relies on service publication; if a Web service is not or cannot be published, it

cannot be found or discovered. The service client can make the service description available to an

application at runtime. The service client, for example, can retrieve a WSDL document from a local

file obtained through a direct publish. This action is known as static discovery. The service can also

be discovered at design or run time using either a local WSDL registry or a public or private UDDI

registry.

Service flow layer

Web Services Flow Language (WSFL) is the standard for the service flow layer at the top of the

stack. It differs from other standards in the stack in that it looks at business process modeling and

workflows. WSFL is used to describe how Web services are to interact in workflows and how they

are to perform in service-to-service communications or collaborations. This means that Web

services are components of, or can be dynamically orchestrated into, workflows -- between a

buyer, a seller, and a shipper, for instance.

For example, WSFL allows a workflow manager to call from a composite Web service each

individual Web service with its particular role in a business process; such processes could include

managing financial reports, supporting forecasts and budgets in a five-year IT plan, or making a

hotel reservation. For instance, in making a hotel reservation, workflow components could

include:

y An enterprise's private Web services collaborating to present a single Web serviceinterface to the public.

y Different enterprises providing Web services in a collaborative effort to perform business-to-business transactions.


37/72

37

You need a tool, such as IBM MQSeries Workflow (now called WebSphere Process Manager; see

the sidebar), to define business processes as a series of activities, and to vary the sequence of

these activities as the requirements for business processes change.

Back to top

Suggested Web services stack

The original Web services stack needs to be updated to incorporate IBM's new standards. This is

achieved by the addition of several new layers: a service user interface/presentation layer, a

service agreement layer, and a service security layer.Figure 3 illustrates the suggested stack.

Figure3

. Suggested Web services stack

Let's start with the topmost layer: the service user interface/presentation layer. The standard

associated with this layer is called Web Services Experience Language (WSXL), and is used to

describe how user experiences should be delivered to end users (for example, through a browser,or a portal, or by embedding into a third party interactive Web application). It is independent of

presentation markup.

WSXL logically sits atop the WSFL, as user experiences depend on how Web services are to

interact in workflows. The WSFL uses WSDL for the description of service interfaces and their

protocol bindings. The service description layer for WSDL consists of two components: the service

implementation layer and the service interface layer. The definition for the implementation layer


38/72

38

describes how a service provider implements a service interface. You must create a service

interface before you can implement WSDL.

WSDL, in turn, relies on the WS-Security specification, which, as the specification itself states, is

used to describe "how to attach signature and encryption headers to SOAP messages." (See

Resources for the full specification.) Included in the security specifications are other types ofmessage attachments, such as X.509 and Kerberos tickets. IBM's WSCA 1.0 specifies how the

WSDL description of the service interface definition and the service implementation definition can

be derived from the UDDI entries. This means that UDDI is used as a service registry for WSDL-

based services.

When not using UDDI, you may want to use the alternative WS-Inspection as a parallel to the

service discovery layer. Both standards provide "directory assistance" via third-party sources.

While WS-Inspection primarily supports focused discovery (active search) patterns, along with

some unfocused (open-ended browsing) ones, UDDI (static) is limited to focused discovery

patterns. Additionally, WS-Inspection has two other characteristics that UDDI does not possess:

direct communication (via voice) and simple aggregate token (via business card), both of which are

disseminated by the originator.

As you can see in Figure 3, the service agreement layer has been inserted between the service

flow and service discovery layers. This new layer, TPA (short for Trading Partner Agreement),

describes an agreement between two partners (for example, business IBM Software Group

Architecture Overview partners) on how they should interact regarding a service, as specified in

the service flow layer. In a procurement/purchase order system, the seller (the service provider),

for instance, must have Web services to receive request for quote (RFQ) messages, purchase order

(PO) messages, invitation-for-bid (IFB) solicitation query messages, and payment messages. The

buyer (the service client) must have Web services to receive RFQ quotes, invoice messages, bidaward notification messages, and account summary messages. Between the provider and the

client are many steps involved in the workflow of exchanging messages.

Web Services Stacks

To ensure interoperability when performing the publish, find and bind operations expressed in the

Service Oriented Architecture (SOA) diagram; conceptual and technical standards must be defined

for each role and type of interaction. This section will explore each of roles and interactions in

order identify each relevant stack of technologies.

There are over arching concerns involving security, management and quality of services that must

be addressed at each layer in the conceptual and technical stacks. The various solutions at each

layer may or may not be independent of one other. More of these overarching concerns will

emerge as the web services paradigm is adopted and evolved. What is most important is building


39/72

39

a framework through which all such concerns may be applied to each of the layers in the stack so

that as new concerns emerge they may be dealt with flexibly and consistently.

At the end of this section we assemble the independent stacks into a single stack where each

additional layer builds upon the capabilities provided by those below it. The vertical towers

represent the variety of over arching concerns that must be addressed at every level of each ofthe stacks.

An important point is that, towards the bottom layers of the stack, the technologies and concepts

are relatively more mature and achieve a higher level of standardization than many of the upper

layers. The maturation and adoption of Web services will drive the continued development and

standardization of the higher levels of the stack and the overarching concerns.

3.3.1 Wire "Stack"

The wire stack encapsulates the concepts and technologies dealing with the actual physical

exchange of information between any of the roles in the SOA diagram. This includes the variety

network transport, message packaging and message extensions that may be utilized to facilitate

data exchange.


40/72

40

3.3.1.1 Transport

The foundation of the web services stack is the network. Web services must be network accessible

to be invoked by a service requestor. Web services that are publicly available on the Internet use

commonly deployed network protocols. Because of its ubiquity, HTTP is the de facto standard

network protocol for Internet-available web services. Other Internet protocols may be supported

including SMTP and FTP. Intranet domains may use proprietary or platform and vendor specific

protocols such as MQSeries, CORBA, etc.. The specific choice of network protocol used in any

given scenario depends entirely upon application requirements, including concerns such as

security, availability, performance, and reliability. This allows web services to capitalize on existing

higher function networking infrastructures and message oriented middleware, such as MQSeries.

Within an enterprise with multiple types of network infrastructures, HTTP can be used as a

common, interoperable bridge to connect disparate systems. One of the benefits of web services

is that it provides a unified programming model for the development and usage of private Intranet


41/72

41

as well as public Internet services. As a result, the choice of network technology can be made

entirely transparent to the developer and consumer of the service.

3.3.1.2 Packaging

Moving up the Wire stack, the next layer, Packaging, represents the technologies that may be usedto package information being exchanged. XML has been broadly adopted as the basis for Web

service message packaging protocols.

SOAP is a simple and lightweight XML-based mechanism for creating structured data packages

that can exchanged between network applications. SOAP consists of four fundamental

components: an envelope that defines a framework for describing message structure, a set of

encoding rules for expressing instances of application-defined data types, a convention for

representing remote procedure calls (RPC) and responses, and a set of rules for using SOAP with

HTTP. SOAP can be used in combination with a variety of network protocols; such as HTTP, SMTP,

FTP, RMI/IIOP, or a proprietary messaging protocol.

SOAP is currently the de facto standard for XML messaging for a number of reasons. First, SOAP is

relatively simple, defining a thin layer that builds on top of existing network technologies such as

HTTP that are already broadly implemented. Second, SOAP is flexible and extensible in that rather

than trying to solve all of the various issues developers may face when constructing Web services,

it provides an extensible, composable framework that allows solutions to be incrementally applied

as needed. Thirdly, SOAP is based on XML. Finally, SOAP enjoys broad industry and developer

community support.

3.3.1.3 Extensions

Building on the transport and packaging layers, the final layer in the Wire stack provides a

framework that allows additional information to be attached to Web service messages

representing a variety of additional concerns; such as context, routing, policy, etc. As a key part of

its envelope message structure, SOAP defines a mechanism to incorporate orthogonal extensions

(also known as features) to the message in the form of headers and encoding rules. It is expected

that as Web services are adopted and evolved, a broad collection of such extensions will emerge

and be standardized.

3.3.2 XML Messaging with SOAP

Here is an example of how SOAP, HTTP, and the internet can be used to implement the Wire stack.

The following figure shows how XML messaging (SOAP) and network protocols can be used as the

basis of the web services architecture.


42/72

42

Editorial note

CBF: missing graphic...

The basic requirements for a network node to play the role of requestor or provider in XML

Messaging based distributed computing are the ability to build and/or parse a SOAP message andthe ability to communicate over a network (receive and/or send messages).

Typically, a SOAP Server running in a web application server performs these functions.

Alternatively, a programming language-specific runtime library can be used that encapsulates

these functions within an API. Application integration with SOAP can be achieved by using four

basic steps:


43/72

43

y In the Figure 1 above at (1), a service requestors application creates a SOAP message. ThisSOAP message is the request that invokes the web service operation provided by the

service provider. The XML document in the body of the message can be a SOAP RPC

request or a document-centric message as indicated in the service description. The service

requestor presents this message together with the network address of the service provider

to the SOAP infrastructure (e.g. a SOAP client runtime). The SOAP client runtime interactswith an underlying network protocol (e.g. HTTP) to send the SOAP message out over the

network.

y The network infrastructure delivers the message to the service providers SOAP runtime(e.g. a SOAP server) (2). The SOAP server routes the request message to the service

provider's web service. The SOAP runtime is responsible for converting the XML Message

into programming language specific objects if required by the application. This conversion

is governed by the encoding schemes found within the message.

y The web service is responsible for processing the request message and formulating aresponse. The response is also a SOAP message. The response SOAP message is presented

to the SOAP runtime with the service requestor as the destination (3). In the case of

synchronous request/response over HTTP, the underlying request/response nature of the

networking protocol is used to implement the request/response nature of the messaging.

The SOAP runtime sends the SOAP message response to the service requestor over the

network.

y The response message is received by the networking infrastructure on the servicerequestors node. The message is routed through the SOAP infrastructure; potentially

converting the XML message into objects in a target programming language (4). The

response message is then presented to the application.

This example uses the request/response transmission primitive that is quite common in most

distributed computing environments. The request/response exchange may be synchronous orasynchronous. Other transmission primitives such as one-way messaging (no response),

notification (push style response), publish/subscribe are possible using SOAP.

3.3.2.1 Interactions

y One way: Message sent from requestor to provider. Provider may or may not return aresponse. If the provider returns a response, the requester may have already stopped

listening for it or closed the communications channel. Response will be thrown away and

not processed by the requester

yConversational: Requester and Provider exchange multiple messages. Can be defined bychoreography language.

y Many-to-Many: Requester sends message to many providers. Or, service providerresponds to many requestors. Can be defined by choreography language.


44/72

44

3.3.3 Description "Stack"

Editorial note

The service description layer is actually a stack of description documents defined using XML

Schema.

It is through the service description that the service provider communicates all the specifications

for invoking the Web service to the service requestor. The service description is a key contributorto making the Web services architecture loosely coupled and to reducing the amount of required

shared understanding, custom programming and integration between the service provider and the

service requestor. For example, neither the requestor nor the provider must be aware of the

other's underlying platform, programming language, or distributed object model (if any). The

service description combined with the underlying XML Message infrastructure defined in the Wire


45/72

45

stack sufficiently encapsulates this detail away from the service requestor's application and the

service providers Web service.

We describe the constituent parts of the service description used in the Web services architecture

in two groups, those used to fully describe one Web service and those used to describe

interactions or relationships between sets of Web services.

Discovery Agencies "Stack"

While the bottom three layers of the stack identify technologies for compliance and

interoperability, the service publication and service discovery can be implemented with a range of

solutions.

Any action that makes a WSDL document available to a requestor, at any stage of the service

requestors lifecycle, qualifies as service publication.


46/72

46

Since a web service cannot be discovered if it has not been published, service discovery depends

upon service publication. The variety of discovery mechanisms parallels the set of publication

mechanisms. Any mechanism that allows the service requestor to gain access to the service

description and make it available to the application at runtime qualifies as service discovery. The

simplest, most static example of discovery is static discovery wherein the service requestor

retrieves a WSDL document from a local file. This is usually the WSDL document obtained througha direct publish or the results of a previous find operation. Alternatively, the service may be

discovered at design time or run time using a local WSDL registry, or a public or private registry

such as UDDI. The variety of service discovery mechanisms is discussed in more detail in the

section titled Service Discovery.

3.1 OVERVIEW

Web services are a concept rather than a packaged solution to a well-defined set of problems.

Web services are based on XML and form a

Date post:	30-May-2018
Category:	Documents
Upload:	vijayakumar
View:	217 times
Download:	0 times

Unit 2 Web Services

Documents