IT-T72 Web Services and XML UNIT III

UNIT III
Business motivations for web services – B2B – B2C – Technical motivations – limitations of
Component Technologies – Architecting web services – Implementation view – web services
technology stack – logical view – composition of web services – deployment view – from
application server to peer to peer – process view – life in the runtime.

1. Explain the business motivations for web services with detail. (Nov 16, Apr 17)
Web Services are loosely coupled contracted components that communicate via XML-
based interfaces. Let‗s take a closer look at this definition:
• Loosely coupled means that Web Services and the programs that invoke them can be
changed independently of each other. Loose coupling also implies that Web Services are
platform independent.
• Contracted means that a Web Service‘s behavior, its input and output parameters, and
how to bind to it are publicly available.
• A component is encapsulated code, which means that the implementation of each
component is hidden from outside the component. Each component‘s functionality is only
known by the interface it exposes.

Managing Complexity and IT Costs

 Modularity and reusability were touted as the solutions to the problems of legacy
programming.
 Remote procedure call (RPC) architectures arose to address the problems that developed
when components on different systems needed to communicate with each other.
 The two most successful RPC architectures, DCOM and CORBA, have gained
widespread acceptance, but they are still too complex to provide convenient
interoperability among different systems.

Lingua Franca of B2B E Commerce

Need for single business vocabulary for all participants in each trading group (XML is
basis for all this). The Web Services provide a dynamic service description.

Global E-Marketplace Vision

Business requires two different companies to locate, identify, contact and transact with
other companies
Eg: Business Motivations for Web Services

IV Year/VII Sem 1
IT-T72 Web Services and XML UNIT III

Categories
1. Business-to Business (B2B)
2. Business to Consumer (B2C)
3. Application to Application (A2A)
4. Human to Application (H2A)

1. Business-to Business (B2B)

Business-to-business (B2B) is a term commonly) used to describe commerce transactions
between businesses

IV Year/VII Sem 2
 IT-T72 Web Services and XML UNIT III

2. Business to Consumer (B2C)

Business-to-consumer (B2C, sometimes also called Business-to-Customer) describes
activities of businesses serving end consumers with products and/or services.
Main advantages for both the business and consumer are that by opening their market up
to B2C e-commerce trade they are reducing transactions costs.
• The Promise of B2C is avoidance of any middleman.
• Other than increased complexity and potential cost in dealing with customers on a direct
basis using B2C, a company implementation of B2C techniques faces danger of channel conflict
or disintermediation.

2. Discuss about Technical motivations for web services with detail. (Nov 16, Apr 17)
Web Services are loosely coupled contracted components that communicate via
XML-based interfaces. Let‗s take a closer look at this definition:
• Loosely coupled means that Web Services and the programs that invoke them can be
changed independently of each other. Loose coupling also implies that Web Services are
platform independent.
• Contracted means that a Web Service‘s behavior, its input and output parameters, and
how to bind to it are publicly available.
• A component is encapsulated code, which means that the implementation of each
component is hidden from outside the component. Each component‘s functionality is only
known by the interface it exposes.
Let us see the Technical motivations and limitations as following,

1. Limitations of CORBA and DCOM Limitations DCOM

CORBA RMI DCOM

Object Diverse languages Only Java language can be Specification is at the binary
Implementation can be used as long applied, because the Java level. Diverse languages like
as the IDL can be Object Serialization usage. C++, Java, Delphi, and even
mapped to that COBOL can be used.
language.
Client/Server The client stub is The client stub is called The client stub is called
Interface called a stub, and a stub, and the server side a proxy, and the server side is
the server side is is skeleton. called stub.
skeleton.
Remote Internet Inter-ORB Java Remote Method Object Remote Procedure
Protocol Protocol(IIOP) Protocol(JRMP) Call(ORPC)
Object Object A remote server object is Interface pointer is used as a
Identification references(objref) assigned with an ObjID as unique identifier for a remote
are used as the its identification. server object.
object handle at

IV Year/VII Sem 3
IT-T72 Web Services and XML UNIT III

run-time.
Object The ORB is used to The object location and Use the Service Control
Location and locate an object, activation are on Java Manager (SCM) to locate and
Activation and Object Adapter Virtual Machine (JVM) activate an object.
is used for
activation.
Inheritance Support multiple Support multiple Supports multiple interfaces
inheritance at the inheritance at the interface for objects. Every object
interface level. level. Every object implements IUnknown.
Every interface implements
inherits from java.rmi.Remote
CORBA.Object
On-demand A client can bind to A client can do A client can do
Activation a naming or a trader a lookup() on the remote aCoCreateInstance()to
service to activate a server object‘s URL name activate a server object.
server object by to obtain the object
obtaining a server reference.
reference.
Exception Exceptions are Exceptions are thrown at Exceptions are thrown out
Handle thrown at the the interface definition. toHRESULT to be handled.
interface definition. Exceptions are serialized For richer exception handling,
Exception handling and marshaled back across it uses Error Objects,
is taken care of the wire. andISupportErrorInfointerface
by Exception has to be implemented.
Objects.
Garbage Does not attempt to Attempts to perform Attempts to perform
Collection perform general distributed garbage distributed garbage collection
purpose distributed collection of remote server on the wire by pinging. The
garbage collection. objects using the DCOM wire protocol uses a
mechanisms bundled in the Pinging mechanism to
JVM. garbage collect remote server
object references.

2. Problems with Business Modeling

 Business modeling takes distributed computing with objects to its logical extreme, where
objects are rolled into business components that correspond to coarse-grained business
concepts or processes.

 A business component consists of all the software artifacts necessary to implement a

business concept (such as ―customer‖ or ―order‖) as an autonomous, reusable element of
a distributed information system.

IV Year/VII Sem 4
IT-T72 Web Services and XML UNIT III

 Business modeling is a way to apply object-oriented principles to large, enterprise

systems in a recursive manner, where component systems are made up of business
components, which in turn consist of individual distributed software components, which
in turn contain object classes.

• Limit complexity and costs by developing coarse-grained software units.

• Support high levels of reuse of business components.
• Speed up the development cycle by combining preexisting business components and
continuous integration.
• Deliver systems that can easily evolve.
• Allow different vendors to provide competing business components that serve the same
purpose, leading to a market in business components.

3. Problems with Vendor Dependence

 When market matures other vendors offer high quality packages.
 Shift in the strategic direction or business problems at the vendor can affect the
purchasing company.
 It is difficult to integrate a ―one-stop shop vendor s product with other vendor s products -
shop‖ vendor‘s
 ERP systems were essential to companies‘ operations, because the only cost-effective
way to get all the operational components that make up ERP systems to work together
was to get them from the same company.

Several disadvantages to obtaining software from a single vendor.

 As the market matures, other vendors will offer individual packages that are of a higher
quality than the single vendor, making a ―best-of-breed‖ approach more attractive.
 The purchasing company‘s business grows to depend on the business strategy of the
vendor. Shifts in strategic direction or business problems at the vendor can filter down to
the vendor‘s customers (the―all-the-eggs-in-one-basket‖ problem).

IV Year/VII Sem 5
IT-T72 Web Services and XML UNIT III

 It is very difficult to integrate a ―one-stop shop‖ vendor‘s product with other vendors‘
products at other companies. As a result, a single vendor approach limits the potential of
e-business.

Vendor-independent software strategy solves the problems of vendor dependence but is

only cost effective when certain conditions are met:
• A ―best-of-breed‖ approach makes sense because the market is mature enough to offer
competing packages of sufficient quality.

• There is a broadly accepted integration framework that allows for inexpensive

integration of different packages, both within companies and between companies.

4. Reuse and Integration Goals

 Software reuse has been a primary goal of object-oriented architectures
 Creating objects and components to be reusable takes more development time and design
skill, and therefore more money up front.

Why isn’t coding for reusability more prevalent?

 The problem is that the goal of software reuse presupposes a world with stable business
requirements, and such a world just doesn‘t exist. Building a component so that it can
handle future situations different from the current ones tends to be wasted work, because
the future always brings surprises.

 This problem is especially onerous in the area of legacy integration. Today‘s approach to
integrating legacy systems into component architectures is to create a ―wrapper‖ for the
legacy system so that it will expose a standard interface that all the other components
know how to work with.

 Maybe 90 percent of your software is easy to integrate, but the remaining 10 percent
takes up most of your budget

3. Explain in detail about Service-oriented architecture (SOA) with block diagram.

• The SOA organizes Web Services into three basic roles: the service provider, the
service requester, and the service registry.
Fig : Web Service roles and relationships.

IV Year/VII Sem 6
IT-T72 Web Services and XML UNIT III

 Service providers publish (and un publish) their services to a service registry. Then,
service requesters can find the desired Web Services by searching for their descriptions at
the service registry.
 Once the requester locates the desired service, its client binds with the service at the
service provider and then invokes the service.

1. Flexibility of E-Business Services

 The ability of Web Services to discover, bind to, and invoke other services automatically
at runtime— what we call Just In Time (JIT) integration—is actually a tall order for any
component in a distributed system to fill.
Fig : Hierarchy of Web Services integration

 Lowest level, Web Services is ―hardwired‖ at design time. This option essentially mimics
a tightly coupled distributed architecture such as a client/server or n-tier architecture. The
developer handles the discovery manually and codes the interface to the desired service
into the service requester.

 Next level, the desired Web Service is also identified beforehand, but the service
requester is smart enough to bind to it dynamically at runtime. In this way, the service
requester can vary its request to the service provider, depending on the particular
situation. In addition, the service provider can change its interface from time to time (say,
as part of a functionality upgrade), and service requesters will be able to adjust to the
Change on-the-fly.

 Third level indicates JIT integration to the service provider: The service requester can
search a registry dynamically for a provider and then bind to the one it selects. This is the
only level that requires the participation of a service registry.

IV Year/VII Sem 7
IT-T72 Web Services and XML UNIT III

2. Key Functional Components

1. Service Implementation
2. Publication
3. Discovery
4. Invocation
5. Just in Time Integration

2.1 Service Implementation

• There are two basic approaches to building a Web Service: Build one from scratch, or
provide a wrapper to an existing application or service so that it exposes a Web Service
interface.
• The choice of service interface with the two basic approaches to building a Web Service
gives developers four methods for building Web Services:
1. Develop a new Web Service and a new service interface
2. Develop a new Web Service when there is an existing service interface.
3. Develop a new service interface for an existing application.
4. Create a Web Service that wraps an existing application when you have an
existing service interface.

2.2 Publication
There are three steps to publishing a Web Service:
1. Author the Web Service description document. Written in the Web Services
Description Language (WSDL), this document describes what the Web Service will do,
where it can be found, and how to invoke it.

2. Publish the Web Service description document on a Web server so that it is

accessible to your desired audience (typically the Internet or one company‘s intranet, but
it might also be published to a private emarketplace). It is also possible to ―directpublish‖
the Web Service description to the service requester via e-mail, FTP, or even sneakernet.
Direct publication is only possible when the access to the Web Service will be hardwired.

3. Publish the existence of your document in a Web Services registry using the
Universal Description, Discovery, and Integration (UDDI) specification, which describes
how Web Service registries are organized and how to work with them. A key aspect to
UDDI is the UDDI registry, which acts as a repository for information about published
Web Services. UDDI registries can be global, public registries, or they can be restricted
to an individual enterprise (for a single application or department or for an enterprise
portal) or to a closed group of companies (say, an e-marketplace or a partner catalog).

2.3 Discovery
 Once your Web Service appears in a registry, any application can discover your service
and therefore locate the Web Service description document you published. UDDI
registries support pattern queries for automated lookups and return the location of the
WSDL file for the desired service.

IV Year/VII Sem 8
IT-T72 Web Services and XML UNIT III

 Once you have obtained the location of this file in the form of a Uniform Resource
Indicator (URI), which is a generalization of the familiar Uniform Resource Locator
(URL), you are able to download the WSDL file itself.

2.4 Invocation
There are two steps to invoking a Web Service:
1. Author a client using the Simple Object Access Protocol (SOAP). The WSDL
file you downloaded contains the information you need to create a client using SOAP.
Because you are authoring clients on-the-fly based on information you found in the Web
Service description document, you are able to invoke the Web Service dynamically at
runtime.
2. Make a SOAP call. Your client then creates a SOAP message describing what
it wants the remote Web Service to do and then sends it to the URI specified in the
WSDL document. Typically, the Web Service returns a SOAP message in the format
detailed in the Web Service description document.

2.5 Just In Time Integration

 The JIT integration capabilities of the SOA provide new organizing principles for the
world of IT. Imagine an Internet full of Web Services: some globally available, and
others available on intranets or other closed networks.
 This global set of Web Services grows and changes organically; the owner of each one
determines what functionality the service will have and what interface it exposes, as well
as which registries to submit the service to. In this global picture there is no master
architect or executive committee who is responsible for maintaining the system.

3. Semantic Issues and Taxonomies

• Semantics refers to the meaning, in human and business terms, of a Web Service‘s
actions and parameters. Semantics have always been a sticking point for any distributed system.

• Object-oriented (OO) systems address the problem of semantics when the systems are
small, but ambiguity creeps in when OO systems are scaled up. In a small OO implementation,
the naming conventions of the methods as well as their signatures (the parameters the methods
take in different situations) often connote to the developer the meaning of the methods and
arguments.

• In a large-scale system, however, the semantics of a given class cannot typically be

deduced by its interface alone. The problem only gets worse when many companies (possibly in
different countries) attempt to participate in a distributed e-business system.

• While the work on semantic issues is ongoing, some of the developments have been
incorporated into the Web Services arena in the form of taxonomies.

• A taxonomy is a hierarchical representation of a set of concepts: Think of an area of

interest (say, a vertical market) organized like a Yahoo! directory. UDDI registries take
advantage of taxonomies, which can either be based on standard classifications of businesses or

IV Year/VII Sem 9
IT-T72 Web Services and XML UNIT III

custom built to serve special purposes. The simplest taxonomy used in UDDI registries is
geographical: country followed by political division—for example, United States,

4. Security and Quality of Service Issues

4.1 Security
There are four basic requirements that a Web Services security
Confidentiality - The contents of the messages must not be available to
unauthorized parties.
Authentication - The sender of a message must be authorized to send a message,
and the recipient of the message must be able to confirm the identity of the sender of the
message.
Data integrity - The recipient of a message must be able to guarantee that the
message hasn‘t been tampered with in transit.
Nonrepudiation - The recipient of a message must be able to guarantee the
circumstances surrounding the sending of the message.

There are three access control models that Web Service registries
•A promiscuous registry doesn‘t authenticate the publishers or the requesters.
Such registries don‘t make any claims about the correctness of the data in the registry or
the integrity of the participants. Although a promiscuous registry is the simplest form of
registry to set up, its usefulness is limited by its lack of access control.

•An authenticated registry authenticates both service requesters and service

publishers. Because it knows the identities of the parties involved in the registry, it can
set up coarse-grained access control for specific categories of data within the registry.
Typically, such a registry would require communication via SSL and might also include
support for XML Digital Signatures so that it can validate the XML messages it receives.

•A fully authorized registry goes beyond the security offered by authenticated

registries by implementing a fine-grained authorization paradigm, allowing it to secure
individual data entries by storing access information for each one. Such a registry would
have to support a more complex management and administration infrastructure in order to
enforce such complex security. A fully authorized registry might also act as a public key
authority, providing the individual authority (often called certificates) to both Web
Services publishers and requesters necessary to generate the asymmetric keys.

Quality of Service and Reliable Messaging

The sending of messages to and from Web Services will fall into three basic modes:

• Best effort.
• The service requester sends the request message, and neither the requester nor
the message infrastructure attempts a retransmission in the case of a failure to deliver the
message.

IV Year/VII Sem 10
IT-T72 Web Services and XML UNIT III

• At least once.
• The service requester continues to attempt to send the request until it receives
acknowledgment from the service provider that the message was received. As a result,
the service provider might receive more than one copy of the message.
• If the request is a simple query, this duplication isn‘t a major problem (although
it will contribute to network overhead). However, in other cases, each message may need
to carry a unique ID so that the service provider can recognize a duplicate message.
Along with its acknowledgment, the service provider either sends the requested response
or a ―cannot process message‖ exception.

• Exactly once
• The service requester makes its request, and the service provider guarantees in
its reply that the request has been executed (or it sends an error message, if necessary).
The ―exactly once‖ mode of messaging requires an endpoint manager at either end of the
message to relay messages and guarantee responses (which may simply be a timeout
exception should the service provider fail to respond).
• Endpoint managers also frequently support the queuing of messages or more
complex behaviors such as forwarding messages to other service providers. The exactly
once mode is only applicable when both endpoints participate in the appropriate
messaging infrastructure—for example, within an enterprise or between two companies
who have configured their joint messaging infrastructure beforehand.

4. Write in detail the Architecting Web Services (4+1 View Model) with a neat diagram.
(Nov 16, Apr 17)

• The 4+1 View Model of Software Architecture, popularized by Philippe Kruchten of

Rational Software. Whereas the four blind men each touch the elephant in a different place and
therefore come to different understandings of it, the architect has clear vision, seeing the elephant
from all four views.
As a result, the architect has a comprehensive picture of the elephant
Fig : The 4+1 View Model of Software

IV Year/VII Sem 11
IT-T72 Web Services and XML UNIT III

• Each of the four main views takes the perspective of key stakeholders in the
development process. The fifth view, the Use-Case View, overlaps the other views and
plays a special role with regard to the architecture.

1. The Implementation Architectural View: The Web Services Technology Stack

 The Implementation View (also called the Development or Component View) describes
the organization of the software artifacts and also addresses issues of software
management.
 Each layer on the left builds upon the capabilities of the layer beneath it. The vertical
columns on the right represent capabilities that the architect must address at every level
of the stack.
 The base stack includes those technologies necessary to create and invoke Web Services.
At the bottom is the network layer, which fundamentally allows Web Services to be
available to service requesters.
 HTTP is the de facto standard network protocol, the architect may consider any of a
number of other options, including SMTP (for e- mail), FTP, IIOP, or messaging
technologies such as MQ.
 In the next two layers, SOAP is the XML-based messaging protocol that forms the basis
for all interactions with Web Services.
 When running on top of HTTP, SOAP messages are simple POST operations with
SOAP‘s XML envelope as the payload. SOAP messages support the publish, find, and
bind operations that form the basis of the SOA.

Fig : The Web Services technology stack.

IV Year/VII Sem 12
IT-T72 Web Services and XML UNIT III

 On top of the SOAP layer comes three layers that together form the service description.
WSDL is the de facto standard for service descriptions, with the addition of the still
tentative WSEL for endpoint descriptions.
 The service interface definition contains the binding, portType, message, and type
elements, which form the portion of the service description that is reusable from one
implementation to another.
 The service implementation definition, however, contains those elements that are specific
to each implementation: the service and port elements.
 Next comes the endpoint description, which introduces semantics to the service
descriptions that apply to a particular implementation. Endpoint descriptions can contain
security, QoS, and management attributes that help to define the policies for each of these
vertical columns.
 Only when the architect has dealt with the issues of service publication and discovery can
he move on to the more complex issues regarding the interaction of multiple Web
Services.
 WSFL and WSCL are still in development, and it‘s not clear how these layers will be
handled in the future.
 Securing the base stack is relatively straightforward, because it is internal to the
enterprise; securing Web Services involved in publication and discovery across the
Internet is another issue entirely.
 QoS, as well, means different things at each layer. Network QoS involves network
uptime, packet delivery, and valid HTTP messages. Reliable messaging, however,
depends heavily on the capabilities of the endpoint manager, which uses WSEL or
another endpoint description language.
 Transactions, in fact, must be handled on multiple levels of the service stack, because of
the complexity of handling rollbacks in a multi-enterprise Web Services environment. To
roll back a particular conversation, each operation within that conversation may need to
be reversed.

This management application must be able to do the following:

 Determine the availability and health of the Web Services infrastructure, including the
network as well as the physical systems that support the execution of the Web Services.
 Determine the availability and health of the internal Web Services themselves. Web
Services may need to be built with a management interface in order to support this level
of management.
 Determine the availability and health of the service registries. Some of these registries
may be internal to the enterprise, allowing for direct access to their inner workings, but
other registries are external and may only expose a minimal interface for external
management.
 Determine the availability and health of external Web Services, once they are discovered,
attempt to invoke them. Again, these services are external and may not provide a
management interface.
 Control and configure all internal systems, including the infrastructure as well as the Web
Services themselves.

IV Year/VII Sem 13
IT-T72 Web Services and XML UNIT III

The Logical Architectural View: Composition of Web Services

 The Logical (or Design) Architectural View starts with the end user‘s functional
requirements and provides a top-down abstraction of the overall design of the system.
 In the case of B2B functionality (say, in the case of processing a purchase order), the user
interface may be handled separately from the Web Services; therefore, the ―end users‖ in
this case are the businesses themselves.
 In the B2B case, the functional requirements of a Web Services–based system will
typically involve complex conversations among Web Services that participate in multi-
step business processes.

Fig : Simple e-commerce workflow

 This workflow consists of two separate workflows: a public workflow as well as one
private to the seller. From the buyer‘s point of view, the seller is exposing a single public
Web Service that is composed of separate Web Services in succession.
 The interfaces to the two public services are both written in WSDL. The buyer has
obtained the seller‘s service description beforehand—either by looking it up in a registry
or through a prearranged relationship between the buyer and the seller.

The architect must work with several different elements in a complex workflow
 The sequencing rules that describe how the Web Services interact over time.
 The information flows between each of the services (including the necessary data
mapping).
 The service providers responsible for executing each step. Is the inventory-management
service responsible for executing any of its internal steps, or are they taken care of by the
component services?
 The associations between activities in the workflow.

IV Year/VII Sem 14
IT-T72 Web Services and XML UNIT III

 The operations offered by each service provider.

 The three component services within the inventory-management service may also
represent applications that are not themselves Web Services.
 In such a case, the inventory management service is responsible for communicating with
each component via a preexisting framework, such as CORBA, DCOM, or J2EE.

Synchronous system
 There is a single, closed loop starting and ending at the buyer that every request follows
to completion.
 In reality, however, some of the processes will be synchronous whereas others will be
asynchronous.
 The inventory-management service will likely communicate with the buyer through the
public ecommerce service to determine whether or not the product is in stock, and then
the pick, pack, and ship process will take place asynchronously. As a result, the architect
must also consider how the buyer (as well as the seller) will be able to monitor and
control the asynchronous inventory service.

The user context contains information about the user as well as information about the
user’s session,
 Demographic information, credit card information, and so on
 The user‘s physical location
 The user‘s locale (the user‘s language, currency, number format, and so on)
 The user‘s security level and permissions
 Personalization information that pertains to the Web site the user is visiting, including
merchandise preferences, calendar information, buddy lists, and so on

The Deployment Architectural View: From Application Servers to Peer-to-Peer

 The Deployment (or Physical) Architectural View maps the software to its underlying
platforms, including the hardware, the network, and the supporting software platforms.
 Now a days, Web Services are hosted on application server platforms such as IBM‘s
WebSphere, BEA‘s WebLogic, and Microsoft‘s Windows 2000.

Benefits to building Web Services on top of platforms

 They handle database access, load balancing, scalability, and interface support as well as
provide a familiar environ ment for dealing with hardware and network issues.
 Because Web Services typically exchange messages over HTTP, a Web server is
typically the desired host for supporting a Web Service.

IV Year/VII Sem 15
IT-T72 Web Services and XML UNIT III

Fig : Web Services developer model.

 This model follows a traditional n-tier architecture, except that the Web server is also
responsible for sending and receiving the XML messages that form the Web Services
interface.
 It is also possible to build Web Services on a peer-to-peer (P2P) developer model. P2P,
popularized by the Napster music service, is a distributed architecture that does not rely
on central servers but rather distributes responsibility to systems (called peers) in the
network.

The Process Architectural View: Life in the Runtime

 The Process Architectural View addresses all runtime issues, including processes,
concurrency, and scalability.
 Applications of Web Services move up the hierarchy of Web Service integration options
to JIT integration (as shown previously in Figure 14.3), the Process Architectural View
will take on increasing importance.
 The architect must be able to plan and structure processes where individual Web Services
might be selected, queried, and invoked dynamically at runtime. Therefore, the Process
View is the most important, and yet the least understood, of the architectural views of the
SOA.
 JIT integration also complicates scalability and redundancy issues. Many of these issues
can be handled by the underlying software platform that supports the Web Services.
However, with JIT integration, it is not necessarily possible to predict at design time
which Web Services will be invoked or what service implementations they will expose.

IV Year/VII Sem 16
IT-T72 Web Services and XML UNIT III

Fig : JIT e-commerce workflow.

IV Year/VII Sem 17