3012673 understanding and using the web services architecture
TRANSCRIPT
8/14/2019 3012673 Understanding and Using the Web Services Architecture
http://slidepdf.com/reader/full/3012673-understanding-and-using-the-web-services-architecture 1/8
1
Understanding and Using The Web Services
ArchitectureIsık Barıs Fidaner,
Bogazici University
Abstract— This is a study about Web Services, what thistechnology is, how it is used, what problems and possibilitiesdoes it bring, and how its problems are solved.
In the first part, basic concepts and standards about WebServices are described. These are XML file format, message
format SOAP, the HTTP, service description standard WSDL,the registry of services UDDI, workflow standard BPEL, and theREST principles.
Second part is about understanding what Web Services are,and main design points for Web Service programming. It startsby a description and a simple core model of Web Services. Theroles and layers of the conceptual Web Services programmingstack are explained. Some common misconceptions about WebServices are considered.
Third and last part is about the problems of using WebServices. Possible business requirements about Web Servicesare listed, and standards solving them are considered. Thensecurity problems and different solutions such as SSL, TLS,SAML are explained. Then comes the problems concerningapplication integration. There are both non-technical integration
problems about business strategy, and technical problems for theverification of asynchronous interactions in Web Services. Thereare recent papers proposing solutions to both types of problems.
Index Terms— web services, http, xml, soap, wsdl, uddi, bpel,rest.
I. INTRODUCTION
THE INTERNET has become something it never has been.
We are connected to every other in a way that has
never been in human history. This is a web of information,
interaction, but at the same time it is a web of possibilities.
Possibilities of friends, collaboration, learning and also a
possibility of service providing and consuming. Business-to-business (B2B) relations through computer networks have a
comparably long history, but a history with a separation of
protocols, languages, standards. But The Web is one. With
its user and producer-friendliness, HTML became universal,
as well as XML that is similar. And a technology of a more
connected world is being developed: Web Services.
Web Services are simple in theory. Simply put, they are
service requesting and providing, by sending and receiving
messages of some format. The messages are commonly XML
formatted. Most desired features of Web Services are inter-
operability between different systems, perfect security and
quality (as it is for business use), easy interpretation and
implementation.
II. BASIC CONCEPTS
Before focusing on details of Web Services, let us look at
some basic concepts concerning this technology.
A. A human friendly format: XML
In Web Services, many message formats are based on
Extensible Markup Language (XML). XML is a very general-
purpose markup language that is used in variety of applica-
tions. In every XML file, there are entities that are structuredas a tree. It is a method of representing information that is both
human readable and machine readable. Positive attributes of
XML are:
• Being both human and machine-readable
• Unicode support, thus supporting nearly every human
language
• The tree structure is very appropriate for computer sci-
ence abstractions
• Names and values are openly written, making it a self-
documenting format
• The format allows efficient parsing
And its weaknesses:• Its redundant, unnecessarily long format is a problem for
efficient storage and transmission
• With the same reason, every XML parser must check a
file’s format thoroughly to prevent errors
• In XML there is no data type such as int or float,
everything must be expressed through strings
• The hierarchical model of XML is limited, compared to
relational models such as databases. Representing non-
hierarchical data in XML is difficult.
B. Message format: SOAP
Web Services generally use SOAP as a message envelopeformat. Simple Object Access Protocol (SOAP) is a messaging
protocol that is based on Extensible Markup Language (XML)
used usually with Hypertext Transfer Protocol (HTTP). The
original acronym was dropped with version 1.2 as it was
misleading, it became only SOAP. [1]
SOAP forms the second layer of Web services protocol
stack, more abstract layers build on it. These are, “service
description” protocols such as WSDL, and “service discovery
protocols” such as UDDI.
Most widely used messaging pattern of SOAP is Remote
Procedure Call (RPC). In fact, SOAP evolved from XML-RPC
that was only capable of RPC messaging.
SOAP was designed by Dave Winer, Don Box, Bob Atkin-son, and Mohsen Al-Ghosein in 1998. Its specifications are
currently maintained by XML Protocol Working Group of
W3C. It was intended to be a protocol to allow software
applications to interact on the internet or any network.
8/14/2019 3012673 Understanding and Using the Web Services Architecture
http://slidepdf.com/reader/full/3012673-understanding-and-using-the-web-services-architecture 2/8
2
Let us look at an example SOAP request and response:
<soap:Envelope xmlns:soap="http://schemas
.xmlsoap.org/soap/envelope/">
<soap:Body>
<getProductDetails xmlns="http://ware
house.example.com/ws">
<productID>827635</productID>
</getProductDetails>
</soap:Body>
</soap:Envelope>
Above is a SOAP formatted request example. It uses the
operation “getProductDetails” to get information about the
product with ID 827635. This message is independent of the
operating system or any inner structure of the server.
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<getProductDetailsResponse xmlns="http
://warehouse.example.com/ws">
<getProductDetailsResult>
<productName>Toptimate 3-Piece Set
</productName>
<productID>827635</productID>
<description>3-Piece luggage set.
Black Polyester.</description>
<price>96.50</price>
<inStock>true</inStock></getProductDetailsResult>
</getProductDetailsResponse>
</soap:Body>
</soap:Envelope>
This is the response of the server. The operation is realized,
and product details are returned to the client. SOAP messages
are text based and very easy to read. This is also a weakness as
a limitation to transfer speed, because the messages are very
long and this may affect network performance. Some other
technologies such as CORBA use binary format and do not
bear this weakness. This is a general problem of XML-based
protocols.
C. Transferring messages: HTTP
SOAP messages are transferred using Hypertext Transfer
Protocol (HTTP). HTTP is a method used to transfer or convey
information on the World Wide Web. Its original purpose was
to provide a way to publish and retrieve HTML pages. It is
also used to transfer XML files and XML-based file formats
such as SOAP.
HTTP is used between clients and servers as a re-
quest/response protocol. The connecting agent, a client, a
web browser, or any other end-user application, is described
as the “user agent”. The destination server, is called theorigin server. Resources such as HTML files and images are
stored or created in the server. In between the user agent and
origin server may be several intermediaries, such as proxies,
gateways, and tunnels.
D. Service description: WSDL
Web Services Description Language (WSDL) is an XML-
based language for communicating descriptions of Web Ser-
vices. WSDL defines services as a collection of “ports” thatreceive and send “messages”. But these are taken as abstract
concepts and separated from their concrete use or instance.
A “port” is a network address that can be reused through
binding. A “port type” is an abstract collection of supported
operations. A “service” is a collection of ports. “Message”
is defined as abstract definitions of data that is transferred.
WSDL describes the public interface for a particular Web
Service by using these concepts.
WSDL is generally used with SOAP. If a client program
connects to a Web Service, it can get the WSDL to understand
what operations are available on the server. Special data types
are written in WSDL in XML Schema format. Then SOAPmessages are used for calling the functions on the server.
Although a WSDL specification defines the public interface
of a Web Service, it does not provide any information about
its behavior. Behavioral descriptions of Web Services are
defined using higher level standards such as Business Process
Execution Language for Web Services (BPEL). The Web
Service Choreography Description Language (WS-CDL) is
used to specify the interactions among multiple Web Services.
E. A universal registry: UDDI
There is a standard registry for Web Services. It is Universal
Description, Discovery, and Integration (UDDI). UDDI is anXML-based list of businesses. It was written in August 2000,
and it is sponsored by OASIS. It is like a platform or market
that different businesses find each other’s services and interact
over the Internet. Every business registers on the following:
• White Pages that include addresses, contact information
• Yellow Pages that include sectoral categorizations based
on standard classifications
• Green Pages that include technical information about the
services proposed
UDDI is queried by SOAP messages. Clients send SOAP
messages to the UDDI to get service descriptions in WSDL.
And then, using the protocol bindings and message formats
described in WSDL documents, the client can use any service
that is offered in UDDI by several businesses.
F. Programming in the large with BPEL
Being grown out of WSFL and XLANG, Business Process
Execution Language (BPEL) is a XML-based business pro-
cess language that aims to enable programming in the large.
“Programming in the large” generally refers to the high-level
state transitions and interactions between sides of a business
process. This concept is given as an “abstract process”. Every
abstract process provides information about the system states
to wait for messages, send messages, or to compensate for
failed transactions. In contrast, “programming in the small”is about short-lived programmatic behavior, often ran as a
single transaction that involves access to resources such as files
and databases. An important motivation behind BPEL is that
programming in large and small require different approaches.
8/14/2019 3012673 Understanding and Using the Web Services Architecture
http://slidepdf.com/reader/full/3012673-understanding-and-using-the-web-services-architecture 3/8
3
G. The logic of the design of Web: REST
REST is a set of architectural design principles formulated
by Roy Fielding. It is best summed up in its designer’s
words (from his book, Architectural Styles and the Design
of Network-based Software Architectures).
“Representational State Transfer (REST) is intended to
evoke an image of how a well-designed Web application
behaves: a network of web pages (a virtual state-machine),
where the user progresses through an application by selecting
links (state transitions), resulting in the next page (representing
the next state of the application) being transferred to the user
and rendered for their use.”
The REST principles are:
1) Application state and functionality are divided into re-
sources
2) Every resource is uniquely addressable using a universalsyntax for use in hypermedia links
3) All resources share a uniform interface for the transfer
of state between client and resource, consisting of
• A constrained set of well-defined operations
• A constrained set of content types, optionally sup-
porting code-on-demand
4) A protocol that is:
• Client/Server
• Stateless
• Cacheable
• Layered
There is a fundamental difference between RPC and REST-
ful (a system that incorporates REST principles) systems. In
REST, there are mainly resources, such as web pages. Main
operations are GET, PUT, POST, and DELETE. In contrast,
object-oriented or RPC systems have functions and procedures
for calling. For example, in a RESTful system, we acquire
information about a certain user by “getting” the resource with
address “users/001”. Whereas in an RPC system, we have to
call a function like “getUser(id)”.
III . UNDERSTANDING WEB SERVICES
A. What Are Web ServicesWeb Service is defined by W3C as a software system
for making different computers interact. The computers may
have different operating systems, different inner structure, but
the logic of Web Service should make it possible for them
to interact and make operations. This is the most general
definition. But in practice, Web Services usually make use
of following:
• SOAP as messaging envelope format
• WDSL as service description format
• UDDI for defining metadata that is used for service
discovery
• WS-Security that defines standards for security issues• WS-ReliableMessaging as the protocol for reliable mes-
saging
These are the standards proposed by Organization for the
Advancement of Structured Information Standards (OASIS)
and W3C. Web Services Interoperability Organization (WS-
I) also creates some applications and tools to enhance Web
Services interoperability. Web Service development based on
these standards is supported by different implementation plat-forms such as .Net and J2EE (see [2] for Sun One Web
Services Framework).
In short, Web Services are a combination of a discovery
system (UDDI), a description system (WSDL) and the Web
Services themselves.
The discovery system (UDDI) is used by a hosting busi-
ness to enter information describing themselves, publishing
taxonomy along with the descriptions (WSDL) of services they
provide. This allows another business to find their service by
searching with some criteria. It also supports category-based
search options.
After an appropriate service is found, a description (WSDL)
is demanded. This description contains:
• Operations included in the service
• Input and output messages for each operation
The use of WSDL powers a service-oriented architecture
enabling enterprise application integration (EAI), business-to-
business application integration (B2B), and grid computing.[3]
The main benefits of the Web Services are:
• Decoupling of service interfaces from implementations
and platform considerations
• The enablement of dynamic service binding
• Increase in cross-language, cross platform interoperability
B. A Minimalist Model of A Web Service
In the core of Web Services, there are three basic elements:
• The Service. This is a software that is able to process an
XML document it receives through some combination of
transport and application protocols. The inner structure
of the service is irrelevant. It is only necessary that it
responds to a special format of XML files.
• For the service to interpret the information in XML
documents, there must be a shared description of an XML
request-response format. This is described in an XML
Schema. WSDL is commonly used but not necessary.
• The address of the service using a certain protocol. Thisis necessary to access the service. It can be an address
for TCP or HTTP protocol but not necessarily is.
The fourth element is an envelope for the XML document. It
is optional but very helpful, for example for putting additional
information such as security and routing. Soap envelopes are
commonly used standard. Soap has two parts: A header that
keeps all system information, and a body that contains the
XML document to be processed by the Web Service.[4] If we
look at this simplistic model of the Web Services technology,
it seen that this technology is very simple in its core.
C. The RolesIn Web Services, there are three roles and their operations.
A service registry keeps track of recorded services.
A service provider can create a Web Service and its service
definition; or publish the service with a service registry.
8/14/2019 3012673 Understanding and Using the Web Services Architecture
http://slidepdf.com/reader/full/3012673-understanding-and-using-the-web-services-architecture 4/8
4
Fig. 1. The roles and operations in Web Services
A service requester can find the service from registry to get
WSDL service description and a service URL; or bind to the
service and invoke it.
D. Web Services programming stack
To understand the operations of Web Services, let us have a
look at The Web Services programming stack. This stack is a
collection of standardized protocols and application program-
ming interfaces (APIs) that lets individuals and applications
locate and utilize Web Services. Layers in the stack correspond
to operations made by one of three roles above. First three
layers are crucial to the system. The remaining layers are
optional and will be used as business needs require them.[5]
Below is a list of Web Services programming stack layers:
1) Network layer is at the bottom of the stack. It is the
place of the protocol to transfer messages. Most often
used such protocol is HTTP.2) Messaging layer comes after the network layer. It is
the communication platform between Web Services and
their clients. All operations, publishing, finding, bind-
ing, and invoking is accomplished by sending mes-
sages. Most widespread message protocol is XML-based
SOAP.
3) Service description layer. This is where service descrip-
tion rules are applied. WSDL is used for this purpose.
Service providers describe their available Web Services
to clients.
4) Service publication layer. This layer is about a service
provider making its WSDL document available. UDDI
can be used, but it is not necessary. Just sending an e-mail attaching your WSDL document is considered as
publishing.
5) Service discovery layer. This layer is where a service
requester gets someone’s WSDL document. UDDI is a
possible interface, but receiving an e-mail with a WSDL
document is also considered as discovery.
6) Service flow layer. This is the highest layer that facil-
itates the composition of Web Services into workflowsand the representation of this aggregation of Web Ser-
vices as a higher-level Web Service. Web Services Flow
Language (WSFL) was offered by IBM as a standard
to be used in service flow layer. Similarly XLANG
was offered by Microsoft. Then these were combined
to form Business Process Execution Language (BPEL)
that superseded WSFL and XLANG.
There are also higher level layers that are yet to be com-
monly used and standardized.[6]
• Policy description layer. Its purpose is to define service-
specific information beyond mechanics, such as own-
ing business, taxonomy, security requirements, timeouts,costs, and quality of service (QoS) parameters.
• Presentation layer. How a user interface is generated for
this service.
• Composition layer. Related services are expressed here.
Groupings, containment, dependencies, and parent-child
relationships between Web Services are determined.
• Orchestration layer. The ordering of operations, choreog-
raphy, workflows, and business processes.
• Service-level agreement layer. The specific performance,
usage, costs, metrics, and thresholds to which a service
is expected to adhere.
• Business-level agreement layer. A contractual agreement
between the two business partners who will be transacting
business using Web Services.
E. Common Misconceptions
As Web Services gained popularity, there appeared several
misunderstandings about the concept. We are going to focus
on main misconceptions about Web Services below.[4]
1) Web Services are message oriented: There are two main
middleware approaches in terms of interaction models. One
is message-oriented middleware (MOM), which includes Web
Services. The other is object-oriented middleware that is very
Fig. 2. Web Services programming stack
8/14/2019 3012673 Understanding and Using the Web Services Architecture
http://slidepdf.com/reader/full/3012673-understanding-and-using-the-web-services-architecture 5/8
5
different in nature. Applications that are based on Corba or
Enterprise Java Beans belong to this category. The interaction
models determine most things about a system.[7]
Recently, there was a debate in W3C Web Services Archi-tecture working group forum about applying representational
state transfer (REST) principles to Web Services architectures.
Representational State Transfer (REST) is a term to describe
the Web’s architectural style. In contrast to objects and func-
tions, REST is based on resources and only four operations on
them: Put, Get, Post and Delete. As it is simple and platform-
neutral, it well suits to the field of Web Services and its
interoperability needs.[8]
2) Web Services are not distributed objects: Web Services
are very similar to distributed objects in the sense that they
both have a certain description language, they incorporate
well-defined network interactions, and they bear similar mech-
anisms for registering and discovering available components.
However, Web Services are not distributed objects.
In a distributed object system, every object, with the excep-
tion of singleton objects, go through the following life cycle:
• On demand, a factory creates the object instance
• The consumer who wanted the creation performs various
operations on the object instance
• Sometime later, either the consumer releases the instance
or the runtime system garbage collects it
Furthermore, another attribute of objects is being identified
through a reference. It also carries references to other objects.
Several reference handling techniques are developed for this
kind of (object-oriented) architecture. Web Services do notrequire any of these concepts.
In Web Services, there are no life cycles. Also no notion
of objects, object references or factories. There are no method
interfaces, no serialization of data-structures, or garbage col-
lection of references. Distributed object systems enable stateful
distributed computing, though Web Services cannot offer any
of the stateful distributed computing facilities. Web Services
are solely about sending and receiving XML documents and
document encapsulation.
The difference is obvious if we look at how information
flows between client and server or producer and consumer in
these systems. In distributed object systems, the informationtravels in the form of interfaces an object supports. Whereas,
in Web Services the design of the XML documents determine
everything. Of course there are also contexts of interactions
in Web Services. But these contexts are also identified as an
ongoing conversation in the form of document transfer rather
than any states at the services.
Distributed objects are mature and robust systems. But their
application is usually limited to the corporate intranets, which
are often characterized by platform homogeneity and pre-
dictable latencies. The strength of Web Services is in Internet-
style distributed computing, where interoperability and support
for platform and network heterogeneity are essential. In time,
Web Services are probably going to gain similar properties as
distributed object systems such as having guaranteed, in-order,
exactly-once message delivery.
3) Web Services are not RPC for the Internet: Remote
Procedure Calling is done through a network abstraction for
remotely executing procedure calls in a certain programming
language.
This low level operation requires the caller to identify the
remote procedure, to decide which state must be provided tothe procedure at invocation time, and what form to use to
present the results to the caller at completion time. The RPC
systems also include extensive mechanisms for handling errors
at both the runtime and programming levels.
In Web Services, there is no concept of procedure calling
and caller. There is the notion of actor or role that consumes
the service. But there are no predefined semantics with the
XML document’s content. We could implement a Web Service
that runs RPC, but it would be a very specific Web Service and
it would force a certain fixed rules for encoding the arguments
in an XML document and rules for returning the results to the
caller.
Internet-wide RPC was a failure. This has several reasons.
Synchronous interactions over wide-area networks are not
scalable, for example, and large-scale versioning of procedure
interfaces is extremely difficult. Web Services neither have the
functionalities of RPC nor bear these difficulties.
4) Web Services do not need HTTP: Web Services do not
depend on the transport protocol that is used. SOAP messages
may well be transported through plain TCP or UDP, or even
SMTP by e-mail. There are also alternatives such as MQ-
Series or Java messaging service (JMS) to name a few. These
technologies can also be combined. For example a SOAP
package that comes to the system through HTTP may be
automatically forwarded to a certain server through TCP orJMS.
Web Services are not specifically designed for HTTP,
though HTTP is most commonly used. It is easier for the de-
velopers to leave the request parsing and message dispatching
duties to the Web servers. These features were present in the
infrastructure offered by the major Web servers: Apache, IBM
WebSphere, and Microsoft IIS. Therefore, since first Web Ser-
vices, HTTP was used. These servers still provide best service
exercise tools, supporting WSDL and other standards. They
make very useful environments for Web Service development.
Nevertheless, they are not necessary.
5) Web Services does not need Web Servers: There wasa discussion whether to drop the “Web” from Web Services.
Terms such as service-oriented architectures, service-oriented
integration, or services bus do not mention “Web”, because
they are independent of Web Servers. Early Web Services
have exploited Web servers’ application-server functionality,
but now there are several toolkits that let you develop and
integrate Web Services without using Web server infrastruc-
tures. Examples are: Simon Fell’s Pocket-Soap, Systinet’s
Web Applications and Services Platform (WASP), IBM’s
Emerging Technologies Toolkit, Microsoft’s Web Services
Enhancements (WSE).
6) Web Services are not reliable because they use TCP:
Web Services are believed to be reliable, and capable of in-order message delivery, because TCP guarantees these fea-
tures. In fact, TCP itself does not completely guarantee these
features. In a few situations, the protocol cannot completely
deliver a message to a remote party, and if the local participant
8/14/2019 3012673 Understanding and Using the Web Services Architecture
http://slidepdf.com/reader/full/3012673-understanding-and-using-the-web-services-architecture 6/8
6
disconnects, it won’t receive an error notification.
What is more, in Web Services, there are usually inter-
mediaries that makes things even more problematic. In the
condition of network, node, or component failures, it is verypossible that even the document reaches the first station, it
might not be delivered to the server and not processed. These
problems are to be solved by reliable messaging techniques,
WS-ReliableMessaging standard, to be precise.
7) Debugging Web Services is possible: It is believed that
it is impossible to debug Web Services. Traditional debugging
tools depend on a complete knowledge of a system, but as the
requester and provider of a Web Service are usually different
organizations, a different debugging paradigm is necessary.
Most difficult problems are cross-vendor interoperability and
WSDL versioning.
There are new diagnostic tools such as SOAPscope forissues of development and deployment of Web Services. As
development toolkits for Web Services are more commonly
used, interoperability problems between parties using dif-
ferent toolkits are appearing. SOAPscope has features for
trying “what if” scenarios against a server to isolate problem
requests. It has visualizing capabilities for viewing SOAP
messages more abstractly. It can also make WSDL analysis
and WSDL version checking for the detection of errors and for
helping to resolve potential interoperability problems before
service deployment.
IV. USING WEB SERVICES
In Web Services, enterprise-class infrastructure must be sup-
plied, including security, management, and quality-of-service
management to meet the stringent demands of today’s e-
businesses.[5]
The requirements of an e-commerce business would be:
• Exchanging information programmatically with users.
• Sharing common formats with users for data and mes-
sages.
• Users and business must understand the same thing from
the contents of the messages.
• An information mechanism for the merchants to bring
potential buyers• A discovery mechanism for potential buyers themselves
• A way of integrating in workflows its own service appli-
cations with those of its merchants
• Ensuring security in every transaction
Web Services use generally accepted standardized APIs to
communicate at each level of the programming stack
8) Networking standard: Internet and HTTP has greatly
extended the ability of companies to easily and automatically
communicate with its users, whether these users are computers
or human beings
Within the corporation itself, multiple networking protocols
may be used, but in this case adapters will convert betweenthese protocols and HTTP for messages that pass through the
enterprise boundary to and from users.
9) Messaging standard: Two main types of messages exist:
• Message of a document that is to be processed remotely
• Commands and parameters that are used to directly
invoke a remote procedure (RPC)
For a long time, there was no common protocol for handling
both types of messages. Multiple protocols were being used tohandle messages of each type. Now, SOAP is the standardized
mechanism for communicating document-centric messages
and remote procedure calls using XML.
10) Service description standard: Service requesters must
be able to know what services are available from the provider,
what message format is used to invoke them, and what
costs are involved. WSDL is the standard way of giving this
information.
11) Service publication and service discovery standards:
UDDI is the standard for publication and discovery. There are
public and private UDDI registries.
Public UDDI registries are located at http://www.uddi.organd are maintained and synchronized by companies such as
IBM and Microsoft.
There are also private registries maintained by individual
companies or industry consortiums that have controlled per-
mission for access. For example, an enterprise may create its
private registry to accept only merchants and users at some
quality standards to facilitate trust among its clients.
12) Service flow standards: This area is for defining com-
plex Web Services by combining simpler ones. For example,
a company may want to specify that when a client enters an
order over a certain amount of money, the system must get the
approval of a manager before proceeding. WS-BPEL is used
for this purposes.
A. Security Problems
For Web Services to be used securely, following issues must
be solved
• Authentication: Establishing identity for requesters and
providers.
• Authorization: Establishing permissions for users.
• Confidentiality: Making sure that only the intended re-
cipient reads the message. This is accomplished with
encryption.
• Integrity: Ensuring the message hasn’t been changed.
Generally accomplished with digital signatures.
1) SSL and TLS: For transporting security, Secure Sockets
Layer (SSL) is commonly used. SSL is a public-private key
security system that works with digital certificates and operates
between HTTP and TCP network layers. Transport Layer
Security (TLS) protocol was then developed and succeeded
SSL. The web browsers generally support these systems, but
they do not work well with complex, high-volume transactions
like Web Services. This is because these systems do decryption
followed by an encryption at every Web server.
There are also security problems introduced by SOAP.
World Wide Web Consortium’s original SOAP version pro-
vided no security.2) SAML: OASIS created Security Assertion Markup Lan-
guage (SAML) for solving the security problems in XML
transmission by defining security related schemas for structur-
ing documents. These schemas include information related to
8/14/2019 3012673 Understanding and Using the Web Services Architecture
http://slidepdf.com/reader/full/3012673-understanding-and-using-the-web-services-architecture 7/8
7
user identity and access or authorization rights. The standard
transmission of these security information allows companies
using different inner security systems to communicate.[9]
SAML also tell which authentication method is to be used.For example, it may be a password, Kerberos authentication
ticket, hardware token, or X.509 digital certificate. Thus,
SAML can either work with a centralized certificate authority,
or directly between individual users. It can also be used to
share authentication of a requester between providers, so that
a single authentication (e.g. logging in) is adequate.
3) WS-Security: Web Services Security protocol (WS-
Security) was developed by IBM, Microsoft, and VeriSign.
It allows Web Services to run on different security models
by extending SOAP message format. Security data is attached
to the headers of SOAP messages. This information contains
metadata found in specifications of XML Encryption and XMLSignature. It also allows using digital signatures in SOAP
messages.
• XML Encryption provides ways to encrypt whole or
parts of an XML message using common encryption
algorithms.
• XML Signature defines processing rules and syntax for
representing digital signatures.
There are also other higher level standards that are on top
of WS-Security.
• WS-SecurityPolicy is a general framework for defining
security, privacy, and other policies on machines used for
Web Services• WS-Privacy lets providers and users state privacy prefer-
ences and practices
• WS-Trust is a framework of models for establishing both
direct and brokered trust relationships
• WS-SecureConversation establishes sessions in which
SOAP acts like a connection-based approach
• WS-Authorization define how to manage authorization
policies
• WS-Federation standardizes the way companies share
user and machine identities among their disparate authen-
tication and authorization systems.
B. Application Integration
1) Loose Coupling: For a robust and platform-neutral ap-
plication integration, loose coupling is very important. In the
particular area of Web Services, it is crucial to remember that
SOAP XML messages are documents, not remote procedure
calls. Loose coupling ensures that other applications relying
on your service does are not affected by your changes in im-
plementation. In the ideal model, every incoming and outgoing
message taken from the queue should be well-defined.
XML format is very appropriate for loosely coupled access.
For example, if you change the table structure of a database,
clients must change their queries respectively. Even in object-oriented techniques, changes to the implementations of objects
over time tend to break the clients. The Web is an exception to
this, eventhough publishers change web sites fundamentally,
users can always view HTML through their browsers. Because
browsers make no assumptions of a site’s implementation, it
only knows the “wire format” (HTML).
Like Web itself, Web Services also have this goal to be
totally independent to implementation. It only depends on a“public contract” about expected XML to be generated or
received. Object oriented approaches and remote procedure
calling do not work for services-based application integration,
because they are not loosely coupled. For establishing loose
coupling, a message-oriented, document-based approach and
XML model is necessary for Web Services. [10]
2) Application Service Strategies: There are several re-
search papers on the business implications of Web Services
technology. In a very recent paper by Cheng et al., [11], three
application service strategies were compared for providing
Web services of complementary functionalities. These are:
• Independent Service Vendors (ISVs): In this applicationservice strategy, there are two independent vendors and
two different services, but these services combine to make
a third service. Some of the customers demand only one
of two services, some need the third service and demand
the first two for this reason. In this scenario, combining
services is not by by vendors but the consumers. Price of
third service is not regulated.
• Joint venture (JV): In JV, these two vendors join into
a single company to sell the third service at the price
they determine. And the customers of the combined
product cannot divide the product/service to get the two
component services.• Strategic Alliance (SA): SA is the combination of ISV
and JV strategies. In this case, third service is both created
by consumers and sold by the company. Thus, the price
of third service cannot exceed the consumers’ cost of
forming it from first two services.
These events occur in product bundling in other sectors. But
software bundling have distinct features such as low integra-
tion cost and possibility of creating an integrated Web service
with new functionalities. The authors analysed three strategies
and obtained interesting conclusions. They found that optimal
application service strategy depends on several factors. These
factors include the integration cost, the valuations, and market
potentials of individual and integrated Web Services. Their
conclusions tell that SA is in general more profitable to ISV,
showing that interoperability between Web Service vendors is
benefitable. In most cases, SA is the best option. But in some
cases where the integrated Web Service is highly valuated and
the integration cost is small, JV becomes the best application
service strategy.
3) Web Service Interaction and Collaboration: In a 2005
study by Y. Baghdadi, [12], a business interactions per-
spective is conceptualized in terms of the business pro-
cesses among business functions and objects, and customer-to-
business (C2B) and business-to-business (B2B) requirements
for Web Services.He specifies and categorizes the business interactions into
enterprise, customers, suppliers, and partners’ interactions,
in terms of activities. Then he makes a crucial distinction
between “core business activities” and “interaction activities”.
8/14/2019 3012673 Understanding and Using the Web Services Architecture
http://slidepdf.com/reader/full/3012673-understanding-and-using-the-web-services-architecture 8/8