unit 2 web services
TRANSCRIPT
-
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
-
8/9/2019 Unit 2 Web Services
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.
-
8/9/2019 Unit 2 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:
-
8/9/2019 Unit 2 Web Services
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.
-
8/9/2019 Unit 2 Web Services
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
-
8/9/2019 Unit 2 Web Services
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,
-
8/9/2019 Unit 2 Web Services
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/9/2019 Unit 2 Web Services
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.
-
8/9/2019 Unit 2 Web Services
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
-
8/9/2019 Unit 2 Web Services
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.
-
8/9/2019 Unit 2 Web Services
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.
-
8/9/2019 Unit 2 Web Services
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
-
8/9/2019 Unit 2 Web Services
13/72
-
8/9/2019 Unit 2 Web Services
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
-
8/9/2019 Unit 2 Web Services
15/72
-
8/9/2019 Unit 2 Web Services
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.
-
8/9/2019 Unit 2 Web Services
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.
-
8/9/2019 Unit 2 Web Services
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.
-
8/9/2019 Unit 2 Web Services
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
-
8/9/2019 Unit 2 Web Services
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
-
8/9/2019 Unit 2 Web Services
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
-
8/9/2019 Unit 2 Web Services
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
-
8/9/2019 Unit 2 Web Services
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 -
META Group Consulting 10
Reliability
Transactions
-
8/9/2019 Unit 2 Web Services
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.
Enterprise Criterion Ratings
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.
META Group Consulting 11
-
8/9/2019 Unit 2 Web Services
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
-
8/9/2019 Unit 2 Web Services
26/72
26
Reliability CORBA DCOMMessaging 0 -
META Group Consulting 12
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
Reliability CORBA DCOM
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.
META Group Consulting 13
CORBA
-
8/9/2019 Unit 2 Web Services
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
Reliability CORBA DCOM
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
-
8/9/2019 Unit 2 Web Services
28/72
28
the 1 COM Reliability FAQ; http://akpublic.research.att.com/~ymwang/resources/COM-R-
FAQ.htm
META Group Consulting 14
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
Reliability CORBA DCOM
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
-
8/9/2019 Unit 2 Web Services
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.
META Group Consulting 15
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.
Enterprise Criterion Ratings
Viability CORBA DCOM
Product Maturity 0 -
Vendor Outlook
-
8/9/2019 Unit 2 Web Services
30/72
-
8/9/2019 Unit 2 Web Services
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.
-
8/9/2019 Unit 2 Web Services
32/72
-
8/9/2019 Unit 2 Web Services
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.
-
8/9/2019 Unit 2 Web Services
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.
-
8/9/2019 Unit 2 Web Services
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
-
8/9/2019 Unit 2 Web Services
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.
-
8/9/2019 Unit 2 Web Services
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
-
8/9/2019 Unit 2 Web Services
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
-
8/9/2019 Unit 2 Web Services
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.
-
8/9/2019 Unit 2 Web Services
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
-
8/9/2019 Unit 2 Web Services
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.
-
8/9/2019 Unit 2 Web Services
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:
-
8/9/2019 Unit 2 Web Services
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.
-
8/9/2019 Unit 2 Web Services
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
-
8/9/2019 Unit 2 Web Services
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.
-
8/9/2019 Unit 2 Web Services
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