Web Service:
Service computing:
Environment
Demand
What service
computing do?
Relationship
with web
services
Service computing
An uncertain and unpredictable business environment where
customer demands change frequently.
Agility in meet continual change of customer demand:
 Agility in manufacture a product with minimal waste;
 Agility in entire value chain-from the time an order is received to
the time it is fulfilled, including product configuration,
manufacturing, procurement and distribution
Enhance the information architecture adaptability and service-based
communication of an organization so that it can become more agile
along its entire value chain.
Web services provides the latest approach to address the problems in
service computing.
Web Service goals:
 Universal interoperability: all computer programs can communicate with one another from
anywhere at any time;
 Enterprise agility in service computing: to react efficiently and effectively to changes in the
market place;
 A platform(jor new standard) neutral and language independent technology: capable of
enabling new strategic e-business partnerships, creating new service-oriented businesses
and developing a third party software marketplace.
Attributes:
1. Protocol Stack:
1) Transport: network transport protocols (HTTP, SMTP and the like);
2) Messaging: SOAP or non-SOAP messaging(binary);
3) Description: WSDL(Interface + binding(data format and protocol binding) and web
service Policy property(Security, reliability, extensibility and the like));
4) Quality of Service: WS-*(WS-Security, WS-Reliability, WS-Transaction and the like);
5) Components: service composite(BPEL is widely used).
2. Advantages:
 platform-independent and language-independent;
 Most Web Services use HTTP for transmitting messages, This is a major advantage if you
want to build an Internet-scale application, since most of the Internet's proxies and
firewalls won't mess with HTTP traffic (unlike CORBA, which usually has trouble with
firewalls);
 Web Services are more adequate for loosely coupled systems, where the client might
have no prior knowledge of the Web Service until it actually invokes it;
3. Disadvantages:
 Overhead. Transmitting all your data in XML is obviously not as efficient as using a
proprietary binary code, you will probably never find a critical real-time application that
uses Web Services;
4. Service Invocation:
Now, Client stubs and Server stubs are integrate as one single software, the soap engine(ex.
Axis2, see Soap Engine below).
5. Server Side description:
 Web service: First and foremost, we have
our Web service. As we have seen, this is basically a
piece of software that exposes a set of operations.
For example, if we are implementing our Web
service in Java, our service will be a Java class (and
the operations will be implemented as Java
methods). Obviously, we want a set of clients to be
able to invoke those operations. However, our Web
service implementation knows nothing about how
to interpret SOAP requests and how to create SOAP
responses. That's why we need a...
 SOAP engine: This is a piece of software
that knows how to handle SOAP requests and
responses. In practice, it is more common to use a
generic SOAP engine than to actually generate
server stubs for each individual Web service (note,
however, that we still need client stubs for the
client). One good example of a SOAP engine is Apache Axis(this is, in fact, the SOAP
engine used by the Globus Toolkit). However, the functionality of the SOAP engine is
usually limited to manipulating SOAP. To actually function as a server that can receive
requests from different clients, the SOAP engine usually runs within an...
 Application server: This is a piece of software that provides a 'living space' for
applications that must be accessed by different clients. The SOAP engine runs as an
application inside the application server. A good example is the Jakarta Tomcat server, a
Java Servlet and Java ServerPages container that is frequently used with Apache Axis
and the Globus Toolkit.
 HTTP Server: This is more commonly called a 'Web server'. It is a piece of software that
knows how to handle HTTP messages. A good example is the Apache HTTP Server, one
of the most popular web servers in the Internet.
6. Web Service Middleware generations:
 The first generation of Web Services Middleware was written to demonstrate the
validity of Web Services, and performance was hardly a critical concern (for ex. The
Quality of Service);
 The second generation middleware handled the basic scenarios correctly; they focused
on a limited set of scenarios, yet implemented them completely. Users were happy with
synchronous, request-response support and nobody tried to send DVDs over Web
Services;
 At first, Web Services were used as the method to provide XML RPC, but it soon turned
out that Web Services can be used to build loosely coupled(asynchronous and other
messaging) systems that can be decoupled in time as well as space(Performance).
Furthermore, Web Service extensions , such as security, are more layered down and
understood. The third generation of Web Services is evolving to meet these
requirements.
7. Web Service Messaging:
The following three parameters describe a given web service's messaging interaction (refer
to the Messaging in Axis2 entry in Axis2.docx):
 Message exchange pattern;
 Synchronous and asynchronous client API;
 One-way/two-way behavior of the transport( SMTP and JMS are one-way, while HTTP
and TCP are two-way).
The synchronous request-response type of interaction is a very small subset of
messaging scenarios. Messaging is very important in constructing loosely coupled systems,
and as a result, this limitation is critical.
BPEL:
Also BPEL4WS, is the acronym for Business Process Execution Language for Web Services;
It is a XML-based workflow definition language that allows businesses to describe sophisticated
business processes that can both consume and provide Web services.
BPEL documents are executable scripts that can be interpreted by business process engines
(for example, BPEL4J) to implement the described process. Each step in the process corresponds
to a single business activity. Each activity is implemented as an interaction with a Web service
provided either by the original(source) service or by one of its business partners.
(BPEL 所描述的 business process 是 internal 的，也就是说，它关注的是 business process
在其 service 内部的调用过程，包括内部调用与被调用顺序，如何与 external service 交互等。
也就是说每个 service 都只关注整个总体的 business process 在其内部那部分的分 business
process 那部分，而这些分 business process 通过相互的调用实现了一个整体的 business
process。)
BPEL 模型可以帮助我们更好地理解如何使用 BPEL 描述的业务流程，如图所示。流程
（Process）由一系列活动（Activity）组成； 流程通过伙伴链接（Partner Link）来定义与流
程交互的其他服务；服务中可以定义一些变量（Variable，在 BPEL4WS 中被称为
Container）；流程可以是有状态的 长时间运行过程，流程引擎可以通过关联集合
（Correlation Set）将一条消息关联到特定的流程实例。


Why Partner Link?
Why and how using Corelation Set?
o Since there might be multiple business-process instances active at the same time in the
BPEL Engine, all messages sent to the business process have to be delivered to the
correct business process instance.
BEPL4People:
a specification authored by BEA, IBM, Oracle, SAP and other companies that defines BPEL
extensions for human workflow functionality.
BPMN:
Business Process Modeling Notation is a standardized graphical notation for drawing business
processes in a workflow.
The primary goal of BPMN is to provide a standard notation that is readily understandable by
all business stakeholders. These business stakeholders include the business analysts who create
and refine the processes, the technical developers responsible for implementing the processes,
and the business managers who monitor and manage the processes. Consequently BPMN is
intended to serve as common language to bridge the communication gap that frequently occurs
between business process design and implementation.
BTP:
Business Transaction Protocol, is OASIS’s approach for web service transaction. See <<
Approaching Web services transactions>> on IBM’s developer’s site for the distinction between
BTP and WS-C/WS-T.
Business process:
A business process specifies the potential execution order of operations from a collection of
Web services, the data shared between these Web services, which partners are involved and
how they are involved in the business process, joint exception handling for collections of Web
services, and other issues involving how multiple services and organizations participate. This
especially allows specifying long-running transactions between Web services, increasing
consistency and reliability for Web services applications.
Aspects:
 Execution order of operations;
 Data shared between services;
 Which and how partners are involved;
 Joint exception handling for collection of web services;
Correlation levels:

Transport protocol level: Protocol binding of SOAP can provide the correlation between
request and respond;



SOAP level: application-specific information included in SOAP header, for example, an RPCbased application could choose to put a correlation ID relating a call and its return in a SOAP
header to provide correlation between request and respond; or , additional information
should be provided in SOAP header to correlate message to service instance;(MEP doesn’t
mandate any correlation support)
Business process level: using the concept of Correlation Set to provide correlation between
messages exchanged and business process instance;
Application level: application provide the correlation directly;
Distributed Computing:
1. Inter-process communication:
Almost all of the solutions for the problem of distributing computer power emerge from two
conceptual bases: remote procedure calls (RPC) and messaging.
 RPC:
the more popular technique among developers, partly due to its resemblance to using
local procedure calls.
 Messaging:
messaging provides certain advantages over RPC systems in certain scenarios, although
it’s not remarkably popular.
 Their Differences:
o Messaging has no notion of client and server, RPC always has the concepts of the
service requester and service provider;
o Messaging is time-independent, to a certain extent, RPC, however, fails instantly
when one party goes down;
o Messages can be duplicated and delivered to multiple peers quite easily, while RPC
is essentially a one-with-one communication strategy.
DIME:
Direct Internet Message Encapsulation, is a Microsoft-proposed internet standard for the
transfer of binary and other encapsulated data over SOAP. The standard was supposed to be a
simplified version of MIME, and Microsoft now describes it as "superseded by the SOAP
Message Transmission Optimization Mechanism (MTOM) specification".
DSN:
(Delivery Status Notification), A bounce message, or Delivery Status Notification (DSN) message
or, simply, a bounce is an automated electronic mail message from a mail system informing the
sender of another message about a delivery problem. The original message is said to have
bounced.
EAI:
(Enterprise Application Integration) Refers to various techniques used to share data and
business processes in large enterprises. When companies acquire another organization,
disparate information systems have to be made to work together. Even within a company, many
systems have been developed separately and run in isolation, as well as on different platforms.
EAI allows multiple systems to be merged and monitored, and business intelligence can be
gleaned across the entire enterprise.
EAI software may function as a central distribution hub, providing data and command
conversions where necessary between applications. It is also a major component of a business
process management suite (BPMS).
(W3C Message Transmission Optimization Mechanism):
a method of efficiently sending binary data to and from web services. It uses XOP (XML-binary
Optimized Packaging) to transmit binary data and is intended to replace both MIME and DIME
attachments.
Information Model:
An information model is an abstract but formal representation of entities including their
properties, relationships and the operations that can be performed on them.
The entities being modeled may be real-world, such as devices on a network, or they may
themselves be abstract, such as the entities used in a billing system. Typically, though, they are
used to model a constrained domain that can be completely described by a closed set of entities,
properties, relationships and operations.
The main driving force behind the definition of an information model is to provide formalism
to the description of a problem domain without constraining how that description is mapped
to an actual implementation in software. There may be many mappings of the information
model.
Interaction of WS:
The following five parameters define an interaction.
1. Message exchange pattern
2. Transport with which the service can be accessed
3. Transport used by the related messages
4. Behavior of the transport
5. Synchronous/asynchronous behavior of the client API
The service provider declares the first two, and the client is free to define the other parameters.
The client-level synchronous/asynchronous behavior is completely transparent to the service
provider, and the client uses WS-addressing to explain the web service messaging.
JAX-RPC:
Java API for XML-based RPC allows invoking from a Java application a Java based Web Service
with a known description while still being consistent with its WSDL description. It can be seen as
Java RMIs over Web Services. JAX-RPC 2.0 was renamed to JAX-WS 2.0 (Java API for XML Web
Services).
It works as follows:
1. A Java program invokes a method on a stub (local object representing the remote service)
2. The stub invokes routines in the JAX-RPC Runtime System (RS)
3. The RS converts the remote method invocation into a SOAP message
4. The RS transmits the message as an HTTP request
The advantage of such a method is that it allows the Web Service to be implemented at serverside as a Servlet or EJB container. Thus, Servlet or EJB applications are made available through
Web Services.
JAXTX:
Java API for XML Transactions, JAXTX provides an API for packaging and transporting ACID
transactions (as in JTA) and extended transactions (e.g., the BTP from OASIS) using the protocols
being defined by OASIS, W3C.
JAX-WS:
Java API for XML Web Services;
JSRs:
Java Specification Requests, they are to Java what RFCs to the internet world;
Service aggregator:
Service aggregators group services provided by other providers into a distinct value-added
service and can themselves act as providers.
SOAP
Message format:
Base-URI:
If the env:role attribute has an empty value, i.e., env:role="", it means that the relative URI
identifying the role is resolved to the base URI for the SOAP message in question. SOAP Version
1.2 does not define a base URI for a SOAP message, but defers to the mechanisms defined in
[XMLBase] for deriving the base URI, which can be used to make any relative URIs absolute. One
such mechanism is for the protocol binding to establish a base URI, possibly by reference to the
encapsulating protocol in which the SOAP message is embedded for transport. (In fact, when
SOAP messages are transported using HTTP, SOAP 1.2 defines the base URI as the Request-URI
of the HTTP request, or the value of the HTTP Content-Location header.)
Soap Engine:
a piece of software that knows how to handle SOAP requests and responses, it aids both
consumers of Web services and their providers to accomplish their task without having to worry
about the intricacies of SOAP message handling.. In practice, it is more common to use a generic
SOAP engine than to actually generate server stubs for each individual Web service (note,
however, that we still need client stubs for the client). To actually function as a server that can
receive requests from different clients, the SOAP engine usually runs within an Application
Server(see Server Side description above);
MDN:
(Message Disposition Notification), return receipts for E-mail. A return receipt is a postal service
document confirming the arrival of a message or parcel at its intended destination.
Messaging in WS:
1. Compare Messaging with RPC:
 Messaging has no notion of client and server, all nodes that accept and emit messages
are considered equal in status and termed peers. RPC always has the concepts of the
service requester (AKA client) and service provider;
 Messaging is time-independent, to a certain extent, MOM takes care of delivering a
message to the relevant peer when it is available; RPC, however, fails instantly when
one party goes down.
 Messages can be duplicated and delivered to multiple peers quite easily. While RPC is
essentially a one-with-one communication strategy, messaging is far more flexible and
can deliver copies of the same message to multiple peers without any effort from the
emitter.
2. Syn and asyn messaging explanation:
There are well-known trade-offs between synchronous and asynchronous messaging. The
trade-offs roughly mean a choice between coupling in time versus coupling in space.
In synchronous messaging, resources are dedicated in one party while the other party
and/or network are processing the message. The classic is obviously request-response
where the client keeps a connection open, and probably a thread for the connection, while
waiting for the response. These two systems are coupled in time.
Asynchrony relaxes the coupling in time but adds a coupling in space. The simplest is a
one-way message, where the sender puts the message into the transport and continues.
Request-response is often layered onto asynchronous messaging by using of a "callback",
sometimes called asynchronous request-response. A request contains an address for the
receiver to send a message to. There is further coupling in space because the state of the
system is spread across two machines. To re-use the resources on the sender, the "state" of
the sender must somehow be passivated, so that it can be reified when the response comes
back. The correct instance of state on the server, often called correlation, must also be
identifiable from the response message. The protocol between the two systems must
necessarily be more complicated for asynchrony, because it requires the correlation
between messages and/or instances to be in the messages. FWIW, these correlations are
why WS-Addressing has MessageIds, RelatesTo and Reference Parameters.
3. How asyn-messages correlates:
WS-addressing defines four headers: To, ReplyTo, RelatesTo, FaultTo, and a special address
that is called the Anonymous address.
Transports, together with WS-addressing, define a mechanism to find interrelated
messages. Messages are related either because they share the same transport channel, or
because they all share common information that links them to each other. The RelateTo
header of the web service addressing provides precisely this relationship.
The following table shows different values of the addressing headers for a few well-defined
message interactions.
Asynchronous
Pattern
Applicable
Transports
Usage Examples
Comments and
Considerations
1. One-way and
notification
operations
HTTPR, JMS,
MQSeries
Messaging,
HTTP, HTTPS,
RMI/IIOP,
SMTP
Pub/sub; event
notification
Inherently supported by
asynchronous transports.
When delivery of a request
or response does not need to
be guaranteed, synchronous
transports can be used.
2.
Request/reply
operations
HTTPR, JMS,
MQSeries
Messaging,
HTTP, HTTPS,
RMI/IIOP,
SMTP
General service
with a single
response;
transactional
services
Inherently supported by
asynchronous transports.
When delivery of a request
or response does not need to
be guaranteed, synchronous
transports can be used.
3.
Request/reply
operations with
HTTP, HTTPS*,
RMI/IIOP**
Self-service
The simplest client-side
implementations.
Application-level
polling
4.
Request/reply
operations with
posting
acknowledgements easily
supported with synchronous
transports (for example, by
HTTP response).
HTTP, HTTPS*,
RMI/IIOP**
Pub/sub; event
notification
Simpler client-side
implementations. Similar to
Pattern 1, but with explicit
application-level
acknowledgements for use
with synchronous transports.
*
: Supported by current Web services tooling.
: Though you can also use asynchronous transports for these patterns, it would be
impractical to do so, since the asynchronous transports provide mechanisms that make
Patterns 1 and 2 easier to implement.
**
4.
MIME:
Multipurpose Internet Mail Extensions is an Internet Standard that extends the format of e-mail
to support:
* text in character sets other than US-ASCII;
* non-text attachments;
* multi-part message bodies;
* header information in non-ASCII character sets.
MOM:
Messaging Oriented Middleware;
MPI:
Message Passing Interface is computer software that allows many computers to communicate
with one another. It is used in computer clusters.
MTOM:
SOAP Message Transmission Optimization Mechanism, is a SOAP binding to HTTP, describes a
mechanism for optimizing the transmission and/or wire format of a SOAP message by selectively
re-encoding portions of the message while still presenting an XML Infoset to the SOAP
application. MTOM also describes an Inclusion Mechanism that operates in a bindingindependent way, plus a specific binding for HTTP. Loosely Coupled Thinking web site provides
more details on MTOM[17]. MTOM is very important strategically because it enables
composition of attachments with WS-Security, which SOAP with Attachments does not.
The content types defined by MIME standards are also of importance outside of e-mail, such as
in communication protocols like HTTP for the World Wide Web. HTTP requires that data be
transmitted in the context of e-mail-like messages, even though the data may not actually be email. In most cases, the MIME types are used for categorizing and describing binary contents of
a file or an electronic message.
Paas:
Platform as a service;
REST:
REpresentational State Transfer, it’s resource-oriented, while SOAP is service-oriented. a design
pattern for implementing networked systems. REST is neither a technology nor a standard; it's
an architectural style for exposing resources over the Web.The key principles are:
 Give every “thing” an ID(URI)
 Link things together(by url references)
 Use standard methods(http PUT,POST,GET,DELETE)
 Resources with multiple representations(client can specify the kind of representation it
can interpret in HTTP Header Accept.)
 Communicate statelessly
Resource :
refers to not only those traditionally understanded resources such as data, web pages etc. but
also virtual objects sucha as operations , requests etc.
How does it works:
Server provides a set of links to the client enables the client to move the application from one
state to the next by following a link. With calling HTTP standard methods list above on URI links,
client can achieve these goals. Every client understands HTTP can make use of these resources.
Moreover, the representations of a resource returned should be in standard formats(xml,
text and etc.). REST mandates that state be either turned into resource state, or kept on the
client.
Sample:
http://www.ibm.com/developerworks/webservices/library/ws-rest1/
http://www.ibm.com/developerworks/webservices/library/ws-restajax/
Defining Web Service HTTP binding in WSDL2.0
WSDL binding operation
<description>
<binding whttp:methodDefault="xs:string"?
whttp:queryParameterSeparatorDefault="xs:string"?>
<operation ref="xs:QName"
whttp:location="xs:anyURI"?
whttp:method="xs:string"?
whttp:inputSerialization="xs:string"?
whttp:outputSerialization="xs:string"?
whttp:faultSerialization="xs:string"?
whttp:queryParameterSeparator="xs:string"?>
</operation>
</binding>
</description>
An HTTP binding extension is designed to minimize what needs to be explicitly declared for
common cases. As you can see, this is achieved by defining default values. Take a look at what
the above WSDL fragment tries to express:
 Binding element — You can define the default HTTP method that should be used using
whttp:methodDefault and the separator for query parameters using
whttp:queryParameterSeparatorDefault.
 Operation element — For each and every operation you have the option of defining
following parameters.
1. location — Location of this operation. Most of the time this is a relative URI that
needs to be combined with the endpoint base URI (Defined in the Endpoint
element of the WSDL 2.0 document) to form a full URI. You can define a
template for the URI here. This will be combined with the endpoint base to form
a full URI to send the request.
2. method — The HTTP method that can be used to invoke this operation. Value
should be one of GET, POST, PUT, or DELETE.
3. inputSerialization — How data should be serialized in sending a request to the
service. This is defined by providing the proper content type.
4. outputSerialization — How the response will be serialized to be sent. This is
defined by providing the proper content type.
5. faultSerialization — If a fault occurs, this is the serialization mechanism for that.
6. queryParameterSeparator — The separator for query parameters.
The following are the default input and output serialization values available for GET and POST
operations.
Table 2. Default input and output serializations
HTTP
Default output
Default input serialization
method
serialization
application/x-www-formGET
application/xml
urlencoded
POST
application/xml
application/xml
SAAJ:
The SOAP with Attachments API for Java provides a standard way to send XML documents over
the Internet from the Java platform.
SAAJ enables developers to produce and consume messages conforming to the SOAP 1.1
specification and SOAP with Attachments note.
Developers can also use it to write SOAP messaging applications directly instead of using JAXRPC.
Transaction:
Transactions refer to all discreet tasks that must be performed in unison to accomplish a
goal.Transactions may involve tasks that are done by one or more participant. When more than
one participant is involved, it must be ensured that all the participants do their tasks as
promised.To ensure this, there is some kind of transaction manager that all the involved
participants trust, that controls the actions taken by various participants and ensures that either
all the participants do what they promise or none of the participants do anything.
Transactions are important because there are some tasks that make sense only if done in
unison with other tasks. For example, in a bank transaction, when transferring money from one
account to another it is very important to do the task of debiting one account at this same time
as the task of crediting another account.
1) Traditional:
in tightly coupled systems, short lived. Resources are locked for the duration of the transaction.
Participants have a high degree of trust on each other and are willing to cooperate under a
transaction manager. And has the ACID properties:
 Atomicity -- All participants must confirm or cancel.
 Consistency -- A consistent result is obtained.
 Isolation -- Effects are not visible until all participants confirm or cancel. Intermittent
status of various participants is not visible to the external world.
 Durability -- Effects of the transaction are stored.
2) Present:
Web services introduce a different set of requirements on a transaction infrastructure:
a). transactions should be able to encompass systems that need not be in a trusted domain;
b). do not want their resources to be locked;
c). do not care if the transaction runs for a short time or stretches for days;
d). There is a need for a different kind of transaction, which instead of relying on the commit
and rollback features of traditional transactions uses compensations;
e). Some of the ACID properties of traditional transactions are not mandatory;
f). A transaction may succeed even if only some of the participants choose to confirm and others
cancel;
g). All participants may choose to have their own coordinator (Transaction Manager), because of
lack of trust;
h). All activities are logged;
i). Transactions that have to be rolled back have the concept of compensation.
UDDI:
(Universal Description, Discovery and Integration) An industry initiative for a universal business
registry (catalog) of Web services turned over to the stewardship of OASIS in 2002 as the version
3 specification of UDDI was released. Originally developed by Ariba, IBM, Microsoft and others,
UDDI is designed to enable software to automatically discover and integrate with services on the
Web. Using a UDDI browser, humans can also review the information contained in the registry,
which is a network of servers on the Internet similar to the Domain Name System (DNS).
WSIF:
Web service invocation Framework, it closely based upon WSDL.
WS-Coordination:
It describes an extensible framework for providing protocols that coordinate the actions of
distributed applications. Such coordination protocols are used to support a number of
applications, including those that need to reach consistent agreement on the outcome of
distributed transactions.
The framework defined in this specification enables an application service to create a context
needed to propagate an activity to other services and to register for coordination protocols. The
framework enables existing transaction processing, workflow, and other systems for
coordination to hide their proprietary protocols and to operate in a heterogeneous environment.
Additionally WS-Coordination describes a definition of the structure of context and the
requirements for propagating context between cooperating services.
However, this specification isn't enough to coordinate web services. It only provides a
coordination framework, and need other specification like WS-AtomicTransaction or WSBusinessActivity.
Coordinator consists of the following three services:
1. Activation service -- The service has an operation that allows an application to create
coordination content.
2. Registration service -- This allows an application to register for coordination protocols.
A participant can register with the coordinator for multiple coordination protocols by
calling the "Register" operation on the coordinator multiple times with different
coordination protocol URI.
The process of a set of messages becoming available to the participant on registering for
a coordination protocol is analogous to the participant implementing an interface in a
programming language. The interface may have a set of methods that need to be
implemented.
A participant may choose to register for more than one coordination protocol at the
same time for a given transaction.
3. Coordination protocols -- Coordination protocols that are specific to coordination types.
A Problem with WS-Coordination:
The process of registration between participant and coordinator doesn’t involve any information
about the transaction instance (transaction identifier).
Solution: include a transaction identifier within the ParticipantProtocolService element in
registered message and the CoordinatorProtocolService element in register-response message.
WS-Policy:
WS-Policy is a specification that allows web services to use XML to advertise their policies (on
security, Quality of Service, etc.) and for web service consumers to specify their policy
requirements.
Policies are not exchange using SOAP message, but either specified in metadata in service
WSDL file or got in other ways. SOAP engine use these policy information to manage the
exchange of soap messages or do some job on some relative message headers.
WS-Policy provides a flexible and extensible grammar for expressing the capabilities,
requirements, and general characteristics of entities in an XML Web services-based system. WSPolicy defines a framework and a model for the expression of these properties as policies. Policy
expressions allow for both simple declarative assertions as well as more sophisticated
conditional assertions.
WS-Policy defines a policy to be a collection of one or more policy assertions. Some
assertions specify traditional requirements and capabilities that will ultimately manifest on the
wire (for example, authentication scheme, transport protocol selection). Some assertions
specify requirements and capabilities that have no wire manifestation yet are critical to proper
service selection and usage (for example, privacy policy, QoS characteristics). WS-Policy provides
a single policy grammar to allow both kinds of assertions to be reasoned about in a consistent
manner.
WS-Transaction:
The WS-Transaction specification describes coordination types that are used with the
extensible coordination framework described in the WS-Coordination specification. It defines
two coordination types: Atomic Transaction (AT) for individual operations, and Business Activity
(BA) for long running transactions. Developers can use either or both of these coordination
types when building applications that require consistent agreement on the outcome of
distributed activities.
Business activity can be partitioned in scopes. A scope can be defined as a collection of
operations that need to be executed to finish a task. The operations executed may be on
different participants who participate to finish the task. A hierarchy of scopes can be created to
finish a business activity. Nesting of scopes allows several things:
 The parent can select what result it propagates further to its controlling application or
its parent based on the results that its child tasks return in a scope.
 The parent can catch the exception thrown by its child scope, apply an exception
handler and continue doing processing.
XML Information Set:
Reference the XML Information Set definition in XML.docx.
XOP:
(XML-binary Optimized Packaging ) is a W3C recommended convention, defined for efficient
serialization of XML Infosets that have a mix of binary and textual data, and, more generally for
storing binary data in XML tags. XOP defines an XOP Infoset, which becomes the container for
the mixed XML document. When an XML document is encapsulated in an XOP Infoset, all chunks
of binary data are separated from the XML document and stored separately. In the XML
document, an xop::Include element is added which references the new location of the binary
data. When reading the original document back from the XOP Infoset, the XOP processor
replaces the xop::Include tags with the actual binary data they reference.
SOA:
1. Core components:
 Business services:
 Integration services:
 Enterprise service bus:
 Infrastructure services:
2. Characters:
 Process driven application integration(also model-driven application integration);
 A workflow engine operating as a hub or exchange;
 A process model driving the flow of applications.
3. ESB:
Enterprise Service Bus. It contains a service registry, but not a service container.
Functionalities:
 Routing: Service discovery, selection etc.
 Conversion: protocol and interaction pattern mismatches handling
 Transformation:interface mismatches
 Mediation: management, logging, auditing, security, validation
 Standard adapter to interact with legacy system
Preferences:
 Manage service metadata and further take care of the matchmaking between service requesters
and providers, dynamically select services, connect requestors and provicers
 Decoupling requestor and provider in terms of message format, network location, transport
protocol etc.
 Eliminate concerns such as security
 Mediation
Service registry:
 holds service meta-data
 information about domain models, which are used to establish semantics of the practical metadata artifacts that the ESB cares about
 holds details of links and mediations.
Meta-data:
 interface


policy
behavioral constrains
ESB link:
Between service endpoints that enable basic interconnectivity with a configurable quality of service;
It has two ends , one for attachment of BSRs and the other for attachment of BSPs. Each end is
qualified by interface declarations and policies and can be designed to provice an exact match for
some registered BSPs or BSRs.
Both endpoints of a link as well as the link itself can carry policy declarations.
Mediation:
Process on messages. And further mediate with information about the ESB configuration by means of
access to the ESB registry.
Mediation point:
At the requestor end; at the provider end; associated with a link;
Patterns
 monitor
 transcoder: change message paload without changing its logical content
 modifier: updates the message payload without any change to the context information. Change
message format
 validator:
 cache: cache the response message
 router: change the intended route of a message
 discovery: queries the ESB registry to discover the set of service providers the matches the
requester’s requirements, select one of them and routes the message to it.
 Clone: useful when associated with the monitor pattern for monitoring purpose, in which cloned
messages are routed to monitors, for example.
 Aggregator: generate a new message or event from one or more messages received.
ESB Usage Patterns:
 Broker application pattern: distribution rules are separated from applications.
 Service and event-routing pattern: service selection based on context or content of message and
systems selection based on availability, workload or error conditions.
 Protocol switch pattern: requestor and provicer use different network protocols
 Proxy or gateway pattern: provider security functions, logging or auditing capabilities or message
disaggregation
 Event distribution: used in pub/sub transmitions
 Service transformation pattern: transform messages when requestor and provider have different
interfaces
 Matchmaking pattern: dynamically discover target services
 Process-oriented interaction pattern used in conjuction with broker interaction pattern where
process focus exclusively on business process requirements, delegating issues of matchmaking,
routing, and service selection to ESB
Concerns:
 ESB is connectivity-Fist, but contract-first. This may be crucial for business usage. Some claimed
that ESB-oriented architecture builds things people may never use, and things must be
implemented when actually needed.
 Service containers [are] used to adapt a wide variety of IT assets to the ESB
and an ESB:
has a reliable messaging system, used to allow the service containers to interact.
provides message transformation services
provides message routing services
provides security features to control access to services
is centrally administered, despite being a distributed system.
allows incremental changes to services without requiring shutdown or other disturbance to
system availability.
 Many features of ESB are pretty useful but they may be of no use in the intial stages of a SOA
project. ESB is a later-stage purchase.
My personal point of view:
 First, for a ESB to be practical, a large set of service implements should be available in the
implementing scope. To be more accurate, those service implements should be actually needed
and provided;
 Base on the assumption above, ESB can provider various of benefits lists above in the second
point below concerns.
 Finally, it make sense for an ESB to bring additional benefits to business.
4. Goal of SOA:
The ability to connect a wide variety of systems without proprietary software in order to
achieve truly open interoperability;
5. SESA:
Sematically enabled SOA, using semantics to describe both services capabilities and client
requirements.
6. SOA Definition:
 From service-architecure.com:
A Service-Oriented Architecture is essentially a collection of services. These services
communicate with each other. The communication can involve either simple data
passing or it could involve two or more services coordinating some activity. Some means
of connecting services to each other is needed;
 From IBM:
Service Oriented Architecture (SOA) is a business-centric IT architectural approach that
supports integrating your business as linked, repeatable business tasks, or services. SOA
helps users build composite applications, which are applications that draw upon
functionality from multiple sources within and beyond the enterprise to support
horizontal business processes.
7. Web-extended SOA:
is a subset of SOA focused on Hypertext Transfer Protocol (HTTP) and basic RESTful
principles. Web-extended SOA advocates the use of design patterns that have made the
Web a success
8.
WS&SOA relations:
From the service
computing’s point
of view:
Web service
SOA
Both technologies applied in service computing


Technology in architecture;
Doesn’t dpend on a specific
technology such as web
services
REST
HTTP as an application, that is, the
web is seen as the universal
medium for publishing globally
accessible information, resources
is identified by uri and operations
on such resources using HTTP
verbs.
Not much heterogeneity, may be
the competition among different
browser vendors
WS-*
HTTP as a transport protocol,
without using any semantics
of its verbs.
Provide a new standard or
platform which is platform
neutral and language
independent
More adventageous:
1. Comparison between REST and WS-*:
Protocol Layering
P
r
I
c
i
p
l
e
Heterogeneity
Loose
Coupli
ng
Time
(allow
temporary
downtime
on the
server side)
Location
Not available
DNS address translation
Through the use of SOAP,
communication among
distributed,
autonomous,heterogeneous
systems made possible, which
may be of either RPC or
asynchronous messaging style.
use underlying message bus
to provide persistent, reliable
queue.
Service registry lookup APIs
Uniform
Interface
Parameter
data model
Decisions to make
when adopting these
architectures
Transport Protocol
Payload Format
Service identification
Service description
Reliability
Same HTTP verbs allow service
evolution and complete
decoupling of clients from servers
Both support XML
1. Resource Identification;
2. URI design;
3. Resource Interation Sematics,
which of the four http verbs to
choose;
4. Resource Relationships, so that
clients can follow links to drill
down for more detailed resource;
5. Data representation: data
format
HTTP, waka(?)
SOAP, POX, RSS, JSON, YAML,
MIME
URI
Testual Document, XMLSchema,
WSDL(2.0), WADL(recently
proposed, stands for Web
Application Description Language)
HTTPR(R stands for reliability),Doit-yourself
Security
Transaction
HTTPS
Do-it-yourself
Service composition
Service Discovery
Mashups, Do-it-yourself
Do-it-yourself
1. Data Modeling(type design
using XML Schema);
2. Message Exchange Patterns;
3. Service Operations
enumeration(interface
design);
HTTP, TCP, SMTP, JMS, MQ,
BEEP, IIOP
SOAP
URI, WS-Addressing
XML Schema, WSDL
HTTPR, WS-Reliablility, WSReliableMessaging, Do-ityourself
HTTPS, WS-Security
WS-AT, WS-BA, WS-CAF, Do-ityourself
WS-BPEL, Do-it-yourself
UDDI, Do-it-yourself
Which architecture to choose if advanced features are not required:
REST
WS-*
Flexibility and control
Better
Development efforts
requires a lot more low level
coding
Technical risk
Degree of opensource
Better but introduces a
and vendor tool
dependency on vendors an open
support
source projects
Programming interface
better
convenience
Conclusion:
RESTful service is more suitable for tactical, ad hoc integration over the web(Mashup), while
WS-* services is more preferred in professional enterprise application integration scenarios with
a longer lifespan and advanced Qos requirements
2. BPEL vs. ESB:
For orchestration:
process
Message processing(routing,
transformation, mediation)
Time Span
Process logic
Conclusion
BPEL
Stateful
ESB
stateless
Weak
powerful
Long term
Complex
Process-centric
short
simple
Data-centric