Web Services

WEB SERVICES

PRE-REQUISITE DISCUSSION:

SOA is Interoperation issues Heterogeneous network protocols Heterogeneous hardware platforms

Heterogeneous operating systems Heterogeneous application formats

1       Increased Competitions

2       Enhancement of Business Capabilities

3       There must be consensus On Interoperability

CONCEPT:

What is Web Services?

Web Services can convert your applications into Web-applications. Web Services are published, found, and used through the Web.

Web services are application components Web services communicate using open protocols Web services are self-contained and self-describing Web services can be discovered using UDDI Web services can be used by other applications XML is the basis for Web services

·        Web Services can convert your applications into Web-applications. Web Services are published, found, and used through the Web.

·        Web services are application components

·        Web services communicate using open protocols Web,services are self-contained and self-describing, Web services can be discovered using UDDI

·        Web services can be used by other applications XML is the basis for Web services

•         There are five fundamental Web Services standards.

•         Two of them are general standards that existed beforehand and were used to realize the Web Services approach:

•         XML is used as the general format to describe models, formats, and data types.

•         HTTP (including HTTPS) is the low-level protocol used by the Internet.

•         The other three fundamental standards are specific to Web Services and were the first standards specified for them:

Service is component of distinctive functional meaning that typically encapsulate a high-level business concept

1   Lego block

Service contains Contract – message type def, constraint, description (comment)

2       Interface – set of operations

3       Implementation – Logic and data

Web Services refers to a collection of standards that cover interoperability

MESSAGING WITH SOAP:

1 SOAP - Simple Object Access Protocol

2 SOAP Envelope

3 SOAP Header

4 SOAP Body

5 SOAP Fault

6 SOAP Roles

7 SOAP Message Exchange Patterns

SOAP - Simple Object Access Protocol

SOAP is short for Simple Object Access Protocol. SOAP is an XML based message format used in the client - service communication popularly called web services. SOAP XML Format includes

SOAP Message Styles

SOAP MEP (Message Exchange Patterns)

SOAP Message Routing

SOAP via HTTP

SOAP Message Format

Here is a simple sample SOAP message:

<?xml version=‖1.0‖?>

<soap:Envelope xmlns:soap=‖http://www.w3.org/2001/12/soap-envelope" > <soap:header>

</soap:header>

<soap:body>

<soap:fault>

This element is optional </soap;fault> </soap:body> </soap:envelope>

A SOAP message consists of a Envelope element, inside which a Header and a Body element can be nested.

Inside the Body element a Fault element can be nested, if an error occurs in the web service. Each of these SOAP elements will be explained on the following pages of this SOAP trail.

SOAP Requests and Responses Both Use Envelope's

The SOAP message format as shown earlier is used both to send requests from the client to the web service, and to send responses back to the client from the web service.

Thus the SOAP request and response message format is the same. It is not like in HTTP where the request and response formats are different.

SOAP Envelope

The SOAP Envelope element is the root element in a SOAP message.

Inside the SOAP Envelope you find a Header (optional) and a Body element.

The name space declaration inside the Envelope element: xmlns:env="http://www.w3.org/2002/06/soap-envelope"

This name space declaration must always be present in a SOAP Envelope element. The prefix (env) can change as you see fit.

SOAP Header Table of Contents

Header Child Element Attributes o mustUnderstand

o encodingStyle o role

o relay

The SOAP Header element is an optional child element of the Envelope element. Inside the Header element you can put information that is not part of the body of a SOAP message.

Whatever that information could be, is up to you. For instance, it could be information about the maximum time the SOAP request may take to process, or something similar which is not directly related to the message itself.

Here is a sample SOAP Header element (Header element marked in bold): <?xml version="1.0"?>

<env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope" > <env:Header>

<jj:maxTime value="10000" xmlns:jj="http://jenkov.com"/> </env:Header>

<env:Body>

</env:Body>

</env:Envelope>

Header Child Element Attributes

The Header child elements has a list of standard attributes you can use inside them:

mustUnderstand encodingStyle role

relay

Each of these attributes are described in the following sections.

Must Understand

The mustUnderstand attribute means that any node (computer) processing the SOAP message must understand the given header block. A "node" may not alway be the final of the SOAP message. The message might be routed via intermediate nodes before ending up at the receiving / processing node (the final web service).

Here is an example: <env:Header>

<jj:maxTime value="10000" xmlns:jj="http://google.com" mustUnderstand="true"

/>

</env:Header>

encodingStyle

The encodingStyle attribute is skipped here.

role

A node processing / forwarding a SOAP message is said to act in one or more SOAP roles. Header blocks (elements) can be targeted at nodes acting in specific roles. In other words, if a header block is targeted for nodes acting in the "ultimateReceiver" role, then only nodes acting as ultimate receivers must process that header block. All other nodes should leave it unprocessed.

SOAP roles are explained in more detail in the SOAP Roles text.

relay

The relay attribute determines if a header block is allowed to be relayed if not processed. In other words, if an intermediary node forwards the SOAP message without processing the header element in which the relay attribute is found, should that header element then be forwarded (relayed) in the message, or taken out?

The relay attribute only has two valid values: 1. true 2. false

If the attribute is set to true then this header element can be forwarded even if not processed.If the attribute is set to false then this header element should be removed if the message is forwarded. Omitting the relay attribute is equivalent to setting it to false.

Here is an example header using a relay attribute:

<env:Header>

<jj:maxRelayTime value="10000" xmlns:jj="http://jenkov.com" role="http://www.w3.org/2003/05/soap-envelope/role/next" relay="true"

/>

</env:Header

SOAP Body

The SOAP Body element is the element in a SOAP message that contains the main part to be processed by either client or web service. While a Header element is optional, a Body element is mandatory. You MUST have a Body element in a SOAP message.

Here is a sample SOAP Body element (Body element marked in bold): <?xml version="1.0"?>

<env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope" > <env:Header>

</env:Header>

<env:Body>

</env:Body>

</env:Envelope>

The body of a SOAP message can consist of pretty much whatever XML you feel like putting inthere, as long as it is valid. However, you cannot put text inside the Body element. Text should be nested inside child elements of the Body element.

It is recommended that child elements of the Body element are name space qualified. Here are two Body element examples. The first example sends 4 parameters (elements)

separately inside the Body element. The second example nest these 4 parameters inside a <service> element.

These standards define both the protocols that are used to communicate and the format of the interfaces that are used to specify services and service contracts Fundamental Web

Services Standards

– WSDL is used to define service interfaces. In fact, it can describe two different aspects of a service: its signature (name and parameters) and its binding and deployment details (protocol and location).

– SOAP is a standard that defines the Web Services protocol. While HTTP is the low-level protocol, also used by the Internet, SOAP is the specific format for exchanging Web Services data over this protocol.

– UDDI is a standard for managing Web Services (i.e., registering and finding services).

Message exchange patterns

SOAP Fault

Table of Contents

SOAP Fault Structure

o Code

Reason

Node

Role

Detail

The SOAP Fault element is returned inside the Body element from a web service (or intermediary node) in case an error occurs while processing the received SOAP message.

Here is a sample SOAP Fault element (Fault element marked in bold):

<?xml version="1.0"?>

<env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope" >

<env:Body>

<env:Fault>

<env:Code>

<env:Value>env:Sender</env:Value>

</env:Code>

<env:Reason>

<env:Text xml:lang="en-US">Processing error</env:Text>

<env:Text xml:lang="da">Processerings-fejl</env:Text>

</env:Reason>

</env:Fault>

</env:Body>

</env:Envelope>

xmlns:jj="http://jenkov.com" >10000</jj:MaxRelayTime>

</env:Detail>

</env:Fault>

SOAP Roles

Table of Contents

Predefined SOAP Roles Custom SOAP Roles

SOAP Roles in Header Elements SOAP Roles in Fault Element

A node processing / forwarding a SOAP message is said to act in one or more SOAP roles. Here is a simple diagram showing 3 nodes (computers) involved in the processing of a SOAP message:

Nodes acting in different SOAP roles during SOAP message processing.

The first node is the sender. This role is not mentioned in the SOAP specification though. The second node is an intermediary node which forwards the SOAP message. Intermediary nodes may also alter the SOAP message. For instance, they may add, modify or remove header elements, or even change the body. Intermediary nodes are set to act in the next role.

The last node in the diagram is the "ultimateReceiver" of the SOAP message. The ultimate receiver is the node that actually processes the SOAP message. It is the "web service" in other words. Clever minds may claim though, that the "web service" actually consists of the whole chain of SOAP message processing nodes, and not just the ultimate receiver.

Predefined SOAP Roles

The SOAP specification predefines three roles:

SOAP Roles Role Name Role URI next www.w3.org/2003/05/soap-envelope/role/next none www.w3.org/2003/05/soap-envelope/role/none ultimateReceiver www.w3.org/2003/05/soap-envelope/role/ultimateReceiver

The next role are assumed by both intermediary nodes, and the ultimate receiving node.

The none role is special. No node should act in the "none" role. Header blocks targeted at this role should usually either be left unprocessed, or is used when processing some other header block.

The ultimateReceiver role is reserved for the ultimate receiver of the SOAP message. Header blocks without this role attribute value should not process that header block.

Custom SOAP Roles

SOAP roles are not limited to the three predefined roles listed in the previous section. SOAP roles can be any role you define yourself. If you define your own roles, you will also have to define the semantics of those roles yourself. In other words, you will have to decide what it means to act in these roles you make up yourself.

SOAP Roles in Header Elements

SOAP roles can be used in SOAP Header elements.

Here is a Header example using the role attribute:

<env:Header>

<jj:maxTime value="10000" xmlns:jj="http://jenkov.com"

role="http://www.w3.org/2003/05/soap-envelope/role/ultimateReceiver"

/>

</env:Header>

When a SOAP Header child element contains a role attribute, only nodes acting in that role must process that element. All other nodes should leave it be.

SOAP Roles in Fault Element

SOAP roles can also be used in SOAP Fault elements. When used in a Fault element the role tells which role the faulting node was acting in, when the fault occurred.

Here is a Fault element example using a Role element:

<env:Fault>

<env:Code>

<env:Value>env:Sender</env:Value>

</env:Code>

<env:Reason>

<env:Text xml:lang="en-US">Error in Input Data</env:Text>

</env:Reason>

<env:Node>http://jenkov.com/theNodeThatFailed</env:Node>

<env:Role>

http://www.w3.org/2003/05/soap-envelope/role/ultimateReceiver

</env:Role>

</env:Fault>

SOAP MESSAGE EXCHANGE PATTERNS :

Request - Response

Response

The SOAP specification mentions a concept called "message exchange patterns" (MEP). There are two basic message exchange patterns described in the SOAP specification:

1. Request - Response 2. Response 3. These two message exchange patterns are described in the following sections. 4. Request - Response 5. In a request - response message exchange the SOAP client sends a SOAP request message to the service. The service responds with a SOAP response message. 6. A request - response message exchange patterns is necessary when the SOAP client needs to send data to the SOAP service, for the service to carry out its job. For instance, if the client request that data be stored by the service, the client needs to send the data to be stored to the service. 7. Here is an illustration of a request - response message exchange:

A SOAP request - response

message exchange.

Response

In a response message exchange the SOAP client connects to the service, but does not send a SOAP message through. It just sends e.g. a simple HTTP request. The service responds with with a SOAP message.

This message exchange pattern is similar to how a browser communicates with a web server. The browser sends an HTTP request telling what page it wants to access, but the HTTP request does

not carry any additional data. The web server responds with an HTTP response carrying the requested page.

Here is an illustration of the response message exchange pattern:

A SOAP response message exchange.

ATOMIC TRANSACTIONS & BUSINESS ACTIVITIES:

Transactions as Atomic Actions                                             Two Phase Commit Transactions                                               A Two Phase Commit

Weakness

Transaction Coordination      One Service Per Transaction

A bank application needs to transfer money from one account to another. Currently the bank system has two services:

Deposit Service   Withdrawal Service

Here is an illustration of the bank system:

Service Transactions - a simple bank application using two services.

Transactions as Atomic Actions

A transaction groups one or more actions together, and makes sure they are executed as if it was just a single action. If one of the actions fail, all of the actions fail. Only if all actions succeed will the result of the actions be "committed" (permanently stored) to the system.

Here is an illustration of the withdrawal and deposit service being grouped into a transaction:

Service Transactions - two services grouped into a single transaction.

Two Phase Commit Transactions Services participating in a transaction needs to be coordinated in order to assure that either all or non of the services called "commit" their actions within that transaction. A popular way to coordinate such distributed transactions is the "Two Phase Commit" protocol.

The two phase commit protocol consists of three steps:

1. Begin Transaction

2. Prepare Phase

3. Commit Phase

First all participants are told to participate in a transaction. From this point on, all actions carried out by each participant refering to this transaction, must be carried out as a single action (all or non).

The actions cannot be committed to the main system yet, but must be kept internally in the participant (service), until the participant is instructed to commit the actions.

Second, once all actions are executed successfully by all participants, all participants (e.g. services) are ordered to move to the "prepare phase".

Once a participant is successfully in prepare phase, the participant must guarantee that all actions carried out inside the transaction are ready to be committed.

If the participant fails after it has successfully moved into the prepare phase, it must be able to commit the actions once the participant is functioning correctly again. In other words, the actions executed inside the transaction must be able to survive even a participant crash / reboot. This is usually done by writing a transaction log to a durable medium , e.g a hard disk. If one of the participants cannot move to the prepare phase, all participants are ordered to rollback (abort) the transaction. If all participants successfully move to the prepare phase, then all participants are now ordered to commit their actions. Once committed, the actions are then visible in the system, and permently executed.

A Two Phase Commit Weakness o The two phase commit protocol is not 100% secure. Imagine if a service crashes after entering the prepare phase. Now all services are requested to commit. Imagine that the failed service is the last service in the chain to be ordered to commit. But the commit order fails, because the service has crashed. o All other services in this transaction would already have committed their actions, but not this last one. Normally, the service would have to commit it's part of the transaction once the service is operational again. Here is an illustration of a two phase commit transaction where the last service fails to commit:

Service Transactions - A two phase commit transaction failing.

Transaction Coordination

When multiple services are to participate in a transaction, some entity must coordinate the transaction. In other words someone has to say when the transaction begins, and when to move to the prepare and commit phases entity, the transaction coordinator, can be either:

The application    An enterprise service bus        A separate transaction manager / service

One Service Per Transaction

A way to simplify transaction management in a service oriented architecture is to design the services so each transaction is contained within a single service.

For instance, in the example at the beginning of this text the money transfer would be implemented as a separate service, instead of a transaction involving two services.

ORCHESTRATION AND CHOREOGRAPHY

Used to standardize enterprise application integration as well as to extend the integration to previously isolated systems

•  Between enterprises, BPEL enables easier and more effective integration with business

partners

• Definitions of business processes described in BPEL do not affect existing systems

•   Is the key technology in environments where functionalities are already or will be exposed via Web services.

Orchestration

• Usually used in private business processes

• A central process (which can be another Web service) takes control of the involved

Web services

•  Coordinates the execution of different operations on the Web services involved in the operation.

•   The involved Web services do not "know" (and do not need to know) that they are involved in a composition process and that they are taking part in a higher-level business process.

•    Only the central coordinator of the orchestration is aware of this goal, so the orchestration is centralized with explicit definitions of operations and the order of invocation of Web services

Markup language for composing a set of discrete services into an end-to-end process flow

The Top Down Perspective

Choreography

• Does not rely on a central coordinator

•  Each Web service involved in the choreography knows exactly when to execute its operations and with whom to interact

• Collaborative effort focusing on the exchange of messages in public business processes

•  All participants in the choreography need to be aware of the business process, operations to execute, messages to exchange, and the timing of message exchanges.

Orchestration versus Choreography

• From the perspective of composing Web services to execute business processes, orchestration is a more flexible paradigm and has the following advantages over choreography:

The coordination of component processes is centrally managed by a known coordinator.

Web services can be incorporated without their being aware that they are taking part in a larger business process. – Alternative scenarios can be put in place in case faults occur.

• BPEL supports two different ways of describing business processes that support orchestration and choreography:

– Executable processes allow you to specify the exact details of business processes. They follow the orchestration paradigm and can be executed by an orchestration engine.

– Abstract business protocols allow specification of the public message exchange between parties only. They do not include the internal details of process flows and are not executable. They follow the choreography paradigm.

BUILDING A BUSINESS PROCESS

• Specifies the exact order in which participating Web services should be invoked – sequentially or in parallel.

• Express conditional behaviors. – an invocation of a Web service can depend on the value of a previous invocation.

•         Construct loops, declare variables, copy and assign values, define fault handlers, etc.

•         By combining all these constructs, you can define complex business processes in an algorithmic manner

•         Because business processes are essentially graphs of activities, it might be useful to express them using Unified Modeling Language (UML) activity diagrams. BPEL Steps consists of steps; each step is called an "activity."

•         supports primitive as well as structure activities.

•   Primitive ActivitiesPrimitive activities represent basic constructs and are used for common tasks, such as the following:

– Invoking other Web services, using <invoke>

– Waiting for the client to invoke the business process by sending a message, using <receive> (receiving a request)

– Generating a response for synchronous operations, using <reply>

– Manipulating data variables, using <assign>

– Indicating faults and exceptions, using <throw>

– Waiting for some time, using <wait>

– Terminating the entire process, using <terminate> Combining Primitives

•  Combine these and other primitive activities to define complex algorithms that specify exactly the steps of business processes

•  To combine primitive activities, BPEL supports several structure activities. The most important are: – Sequence (<sequence>), which allows us definition of a set of activities that will be invoked in an ordered sequence – Flow (<flow>) for defining a set of activities that will be invoked in parallel

•  Structure Activities – Case-switch construct (<switch>) for implementing branches – While (<while>) for defining loops – The ability to select one of several alternative paths, using <pick> – Each BPEL process will also define partner links, using <partnerLink>, and declare variables, using <variable>.

SIGNIFICANCE:

Improved Integration, intrinsic interoperability

•         Organizational agility

•         Loosely-coupled with reusable assets and services

•         Drives business processes closer to end users

•         Leverage and integrate existing applications

•         Provide standard connections between systems

•         Abstract complexity for developers

The SOA is important because without this no service can be provided to the user easy and efficiently

APPLICATION AREA:

•         The service oriented architecture is used in all the web oriented service application in internet.