a course material on it2401 - service oriented architecture it … · · 2015-08-13a course...

A Course Material on

IT2401 - SERVICE ORIENTED ARCHITECTURE

By

Mrs.S.SHARMILA

ASSISTANT PROFESSOR

DEPARTMENT OF COMPUTER SCIENCE COMMUNICATION ENGINEERING

SASURIE COLLEGE OF ENGINEERING

VIJAYAMANGALAM – 638 056

QUALITY CERTIFICATE

This is to certify that the course material

Subject Code : IT2401

Subject : Service Oriented Architecture

Class : IV Year IT

Being prepared by me and it meets the knowledge requirement of the university curriculum.

Signature of the Author

Name : Mrs.S.SHARMILA

Designation : Assistant Professor

This is to certify that the course material being prepared by Mrs.S.SHARMILA is of adequate

quality. He has referred more than five books among them minimum one is from abroad author.

Signature of HD

Name: Mr.J.Sathish Kumar

SEAL

IT2401 SERVICE ORIENTED ARCHITECTURE L T P C

3 0 0 3

UNIT I

Roots of SOA – Characteristics of SOA - Comparing SOA to client-server and

distributedinternet architectures – Anatomy of SOA- How components in an SOA interrelate -

Principles of service orientation

UNIT II

Web services – Service descriptions – Messaging with SOAP –Message exchange

Patterns – Coordination –Atomic Transactions – Business activities – Orchestration –

Choreography - Service layer abstraction – Application Service Layer – Business

Service Layer – Orchestration Service Layer

UNIT III

Service oriented analysis – Business-centric SOA – Deriving business services- service

modeling - Service Oriented Design – WSDL basics – SOAP basics – SOA composition

guidelines – Entity-centric business service design – Application service design – Taskcentric

business service design

UNIT IV

SOA platform basics – SOA support in J2EE – Java API for XML-based web services

(JAX-WS) - Java architecture for XML binding (JAXB) – Java API for XML Registries

(JAXR) - Java API for XML based RPC (JAX-RPC)- Web Services Interoperability

Technologies (WSIT) - SOA support in .NET – Common Language Runtime - ASP.NET

web forms – ASP.NET web services – Web Services Enhancements (WSE).

UNIT V

WS-BPEL basics – WS-Coordination overview - WS-Choreography, WS-Policy,

WSSecurity

TOTAL: 45 PERIODS

TEXT BOOK: 1. Thomas Erl, “Service-Oriented Architecture: Concepts, Technology, andDesign”,

Pearson Education, 2005.

REFERENCES: 1. Thomas Erl, “SOA Principles of Service Design “(The Prentice Hall Service-Oriented

Computing Series from Thomas Erl), 2005.

2. Newcomer, Lomow, “Understanding SOA with Web Services”, Pearson Education,

2005.

3. Sandeep Chatterjee, James Webber, “Developing Enterprise Web Services, An

Architect’s Guide”, Pearson Education, 2005.

4. Dan Woods and Thomas Mattern, “ Enterprise SOA Designing IT for Business

Innovation” O’REILLY, First Edition, 2006.

TABLE OF CONTENTS

S.NO TOPICS PAGE

NUMBER

UNIT I

1 Roots of SOA 1

2 Characteristics of SOA 1

3 Comparing SOA to client-server and distributedinternet architectures 8

4 Anatomy of SOA 9

5 How components in an SOA interrelate 9

6 Principles of service orientation 12

UNIT II

7 Web services 15

8 Service descriptions 15

9 Messaging with SOAP 16

10 Message exchange Patterns 24

11 Coordination 25

12 Atomic Transactions 25

13 Business activities 25

14 Choreography 27

15 Service layer abstraction 29

16 Application Service Layer,Business Service Layer – Orchestration

Service Layer

29

UNIT III

17 Service oriented analysis 31

18 Business-centric SOA 31

19

Deriving business services- service modeling 32

20 Service Oriented Design 32

21 WSDL basics 33

22 SOAP basics 34

23 SOA composition guidelines 36

24 Entity-centric business service design 36

25 Application service design 37

26 Taskcentric

business service design

37

UNIT IV

27 SOA platform basics 39

28 SOA support in J2EE – Java API for XML 39

29 -based web services

(JAX-WS) - Java architecture for XML binding (JAXB) – Java API for

XML Registries

(JAXR) - Java API for XML based RPC (JAX-RPC)

41,42

30 Web Services Interoperability Technologies (WSIT) 43

31 SOA support in .NET 44

32 Common Language Runtime 45

33 ASP.NET web forms 46

34 ASP.NET web services 47

35 Web Services Enhancements (WSE). 47

UNIT V

36 WS-BPEL basics 50

37 WS-Coordination overview 50

38 WS-Choreography 51

39 WS-Policy 52

40 WSSecurity 53

IT2401-SERVICE ORIENTED ARCHITECTURE IT-IV CSE

1 S.SHARMILA 2015-2016

UNIT-1

ROOTS OF SOA

Introduction:

Pre-requisite Discussion:

Application architecture is to an application development team what a blueprint is to a

team of construction workers. Different organizations document different levels of application

architecture.

An SOA can refer to an application architecture or the approach used to

standardize technical architecture across the enterprise.

Contents:

CHARACTERISTICS OF SOA:

Service-oriented architecture:

An SOA can refer to an application architecture or the approach used to standardize

technical architecture across the enterprise.

The components of the basic (first-generation) Web services framework.

This framework can be applied to implement services in just about any environment.

Services are discoverable and dynamicallybound.

Services are self-contained and modular.

Services stress interoperability.

Services are loosely coupled.

Services have a network-addressable interface.

Services have coarse-grained interfaces. Services are location-transparent.

Services are composable.

Service-oriented architecture supports self-healing.

CONTEMPORARY SOA



• Major software vendors are continually conceiving new Web services specifications and

building increasingly powerful XML and Web services support into current technology

platforms.

• The result is an extended variation of service-oriented architecture we refer to as

contemporary SOA.

SOA increases quality of service

• Ability for tasks to be carried out in a secure manner, protecting the contents of a

message, as well as access to individual services.

• Reliability so that message delivery or notification of failed delivery can be guaranteed.

• Overhead imposed by SOAP message and XML content processing does not inhibit the

execution of a task.

SOA is based on open standards

Standard open technologies are used within and outside of solution

boundaries.

SOA supports vendor diversity



SOA promotes discovery

SOA encourages intrinsic interoperability

SOA promotes federation



SOA promotes architectural composability

• Different solutions can be composed of different extensions and can continue to

interoperate as long as they support the common extensions required.

SOA encourages intrinsic reusability



SOA emphasizes extensibility

• Extensible services can expand functionality with minimal impact.

SOA supports a service-oriented business modeling paradigm



• Partitioning business logic into services that can then be composed has significant

implications as to how business processes can be modeled

SOA implements layers of abstraction

• Application logic created with proprietary technology can be abstracted through a

dedicated service layer.

SOA promotes loose coupling throughout the enterprise



SOA promotes organizational agility



Client server Architecture:

• Mainframe back-ends served thin clients, are considered an implementation of the single-

tier client-server architecture Mainframe systems natively supported both synchronous

and asynchronous communication. The latter approach was used primarily to allow the

server to continuously receive characters from the terminal in response to individual key-

strokes. Only upon certain conditions would the server actually respond.

Distributed Internet Architecture:

• Distributing application logic among multiple components (some residing on the client,

others on the server) reduced deployment headaches by centralizing a greater amount of

the logic on servers. Server-side components, now located on dedicated application

servers, would then share and manage pools of database connections, alleviating the

burden of concurrent usage on the database server A single connection could easily

facilitate multiple users.

How the components of a service-oriented architecture relate.

How the components of a service-oriented architecture define each other.



ANATOMY OF SOA

Application architecture is to an application development team what a blueprint is to a

team of construction workers. Different organizations document different levels of

application architecture.

Service-oriented architecture:

An SOA can refer to an application architecture or the approach used to standardize

technical architecture across the enterprise.

The components of the basic (first-generation) Web services framework.

This framework can be applied to implement services in just about any environment.

1. Logical components of the Web services framework

Each Web service contains one or more operations. This diagram introduces a new

symbol to represent operations separately from the service.

Each operation governs the processing of a specific function the Web service is capable of

performing.

The processing consists of sending and receiving SOAP messages,


10 S.SHARMILA 2015-2016

The Web services framework provides us not only with a technology base for enabling

connectivity, it also establishes a modularized perspective of how automation logic, as a whole,

can be comprised of independent units.

The following fundamental parts of the framework:

SOAP messages

Web service operations

Web services

activities

The latter three items represent units of logic that perform work and communicate using

SOAP messages.

messages

operations

services

processes (and process instances)

The one exception is the use of "process" instead of "activity."

the word "activity" is used in different contexts when modeling service-oriented business

processes.

Web service activity is typically used to represent the temporary interaction of a group of

Web services,

a process is a static definition of interaction logic. An activity is best compared to an

instance of a process wherein a group of services follow a particular path through the

process logic to complete a task.

messages = units of communication

operations = units of work

services = units of processing logic (collections of units of work)

processes = units of automation logic (coordinated aggregation of units of work)

Figure 4 provides us with a primitive view of how operations and services represent units of

logic that can be assembled to comprise a unit of automation logic.

Figure 4. A primitive view of how SOA modularizes automation logic into units.


11 S.SHARMILA 2015-2016

The messages are a suitable means by which all units of processing logic (services)

communicate. No actual processing of that logic can be performed without issuing units of

communication (in this case, messages).

Figure 5 A primitive view of how units of communication enable interaction between units

of logic.

The purpose of these views is simply to express that processes, services, and operations, on the

most fundamental level, provide a flexible means of partitioning and modularizing logic.

Regardless of the technology platform used, this remains the most basic concept that underlies

service-orientation.


12 S.SHARMILA 2015-2016

3. Components of an SOA

A message represents the data required to complete some or all parts of a unit of work.

An operation represents the logic required to process messages in order to complete a unit

of work (Figure 6).

Figure 6. The scope of an operation within a process.

Components of SOA

A service represents a logically grouped set of operations capable of performing related

units of work.

A process contains the business rules that determine which service operations are used to

complete a unit of automation. In other words, a process represents a large piece of work

that requires the completion of smaller units of work.

Figure 7. Operations belonging to different services representing various parts of

process logic.


13 S.SHARMILA 2015-2016

SIGNIFICANCE:

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.

GLOSSARY:

CSA: client server architecture

DIA: Distributed internet architecture

SOA: service Oriented Architecture

SOAP: Simple object access protocol

REFERENCE:

1. Thomas Erl, ―SOA Principles of Service Design ―(The Prentice Hall Service-Oriented

Computing Series from Thomas Erl), 2005


14 S.SHARMILA 2015-2016

UNIT II

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?


15 S.SHARMILA 2015-2016

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


16 S.SHARMILA 2015-2016

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.


17 S.SHARMILA 2015-2016

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.

mustUnderstand


18 S.SHARMILA 2015-2016

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:


19 S.SHARMILA 2015-2016

<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):



<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.


20 S.SHARMILA 2015-2016

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


21 S.SHARMILA 2015-2016

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):



<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>


22 S.SHARMILA 2015-2016

</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:


23 S.SHARMILA 2015-2016

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

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

http://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


24 S.SHARMILA 2015-2016

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


25 S.SHARMILA 2015-2016

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


26 S.SHARMILA 2015-2016

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.


27 S.SHARMILA 2015-2016

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


28 S.SHARMILA 2015-2016

• 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:


29 S.SHARMILA 2015-2016

– 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>


30 S.SHARMILA 2015-2016

– 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.

REFERENCE:



UNIT 3

SERVICE ORINTED ANALYSIS


31 S.SHARMILA 2015-2016

PRE-REQUISITE DISCUSSION

Service-oriented analysis establishes a formal analysis process completed jointly by

business analysts and technology architects. Service modeling, a sub-process of service-oriented

analysis, produces conceptual service definitions called imodeling processes result in the gradual

creation of a service inventory blueprint.

DERIVING BUSINESS SERVICES

With the detailed example explain about the entity- centric business layer. Case Study

This is only TLS's second service-oriented solution.

The first was created to establish an external interface with their accounting system via a

B2B environment.

That solution was built according to the top-down delivery strategy and therefore resulted

in a collection of entity-centric business services.

Architects involved with the service design for this new Timesheet Submission

application are pretty confident that the new set of services in no way overlaps with the existing

ones.

However, because the B2B solution was built by a completely different project team,

they agree that it is worth the effort to review existing services before commencing with the

design process.

Their investigation reveals that the following entity-centric business services were

delivered as part of the B2B project: Accounts Payable Service, Purchase Order Service, Ledger

Service, and Vendor Profile Service

STEP 1..

The Employee Service candidate.

Step2.

The existing inventory of TLS services. project architects then conclude that no overlap

exists, which gives them the green light to proceed with the design of the Employee Service.

TLS invested in creating a standardized XML data representation architecture (for their

accounting environment only) some time ago. As a result, an inventory of entity-centric XSD

schemas representing accounting-related information sets already exists.

At first, this appears to make this step rather simple. However, upon closer study, it is

discovered that the existing XSD schema is very large and complex. After some discussion, TLS

architects decidefor better or for worsethat they will not use the existing schema with this service

at this point.

Instead, they opt to derive a lightweight (but still fully compliant) version of the schema

to accommodate the simple processing requirements of the Employee Service.

They begin by identifying the kinds of data that will need to be exchanged to fulfill the

processing requirements of the "Get weekly hours limit" operation candidate. They end up

defining two complex types: one containing the search criteria required for the request message


32 S.SHARMILA 2015-2016

received by the Employee Service and another containing the query results returned by the

service.

The types are deliberately named so that they are associated with the respective

messages. These two types then constitute the new Employee.xsd schema file.

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"

targetNamespace= "http://www.xmltc.com/tls/employee/schema/accounting/">

<xsd:element name="EmployeeHoursRequestType"> <xsd:complexType>

<xsd:sequence> <xsd:element name="ID" type="xsd:integer"/> </xsd:sequence>

</xsd:complexType> </xsd:element> <xsd:element name="EmployeeHoursResponseType">

<xsd:complexType> <xsd:sequence> <xsd:element name="ID"

type="xsd:integer"/> <xsd:element name="WeeklyHoursLimit"

type="xsd:short"/> </xsd:sequence> </xsd:complexType> </xsd:element>

</xsd:schema>

Example 15.2. The EmployeeHistory schema, with a different targetNamespace to identify its

distinct origin. <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"

targetNamespace= "http://www.xmltc.com/tls/employee/schema/hr/"> <xsd:element

name="EmployeeUpdateHistoryRequestType"> <xsd:complexType> <xsd:sequence>

<xsd:element name="ID" type="xsd:integer"/> <xsd:element name="Comment"

type="xsd:string"/> </xsd:sequence> </xsd:complexType> </xsd:element>

<xsd:element name="EmployeeUpdateHistoryResponseType"> <xsd:complexType>

<xsd:sequence> <xsd:element name="ResponseCode" type="xsd:byte"/>

</xsd:sequence> </xsd:complexType> </xsd:element> </xsd:schema>

To promote reusability and to allow for each schema file to be maintained separately from the

WSDL, the XSD schema import statement is used to pull the contents of both schemas into the

Employee Service WSDL types construct.

The WSDL types construct being populated by imported schemas. <types> <xsd:schema

targetNamespace= "http://www.xmltc.com/tls/employee/schema/"> <xsd:import

namespace= "http://www.xmltc.com/tls/employee/schema/accounting/"

schemaLocation="Employee.xsd"/> <xsd:import namespace=

"http://www.xmltc.com/tls/employee/schema/hr/"

schemaLocation="EmployeeHistory.xsd"/> </xsd:schema> </types>

The TLS architects decide on the following operations names: GetEmployeeWeeklyHoursLimit

and UpdateEmployeeHistory

They subsequently proceed to define the remaining parts of the abstract definition, namely the

message, and portType constructs.


33 S.SHARMILA 2015-2016

Example 15.4. The message and portType parts of the Employee Service definition that

implement the abstract definition details of the two service operations. <message

name="getEmployeeWeeklyHoursRequestMessage"> <part name="RequestParameter"

element="act:EmployeeHoursRequestType"

WSDL BASICS

CONTENTS:

WSDL stands for Web Services Description Language.

WSDL is a language for describing web services and how to access them.

WSDL is written in XML.

WSDL stands for Web Services Description Language

WSDL is written in XML

WSDL is an XML document

WSDL is used to describe Web services

WSDL is also used to locate Web services

WSDL is a W3C recommendation

WSDL stands for Web Services Description Language.

WSDL is a document written in XML. The document describes a Web service. It specifies the

location of the service and the operations (or methods) the service exposes.

he WSDL Document Structure

A WSDL document describes a web service using these major elements:

Element Description

<types> A container for data type definitions used by the web service

<message> A typed definition of the data being communicated

<portType> A set of operations supported by one or more endpoints

<binding> A protocol and data format specification for a particular port type

The main structure of a WSDL document looks like this:

<definitions>

<types>

data type definitions........

</types>

<message>

definition of the data being communicated....

</message>


34 S.SHARMILA 2015-2016

<portType>

set of operations......

</portType>

<binding>

protocol and data format specification....

</binding>

</definitions>

SOAP BASICS:

A WSDL document can also contain other elements, like extension elements, and a

service element that makes it possible to group together the definitions of several web services in

one single WSDL document.

WSDL Ports

The <portType> element is the most important WSDL element.

It describes a web service, the operations that can be performed, and the messages that are

involved.

The <portType> element can be compared to a function library (or a module, or a class)

in a traditional programming language.

WSDL Messages

The <message> element defines the data elements of an operation.

Each message can consist of one or more parts. The parts can be compared to the

parameters of a function call in a traditional programming language.

WSDL Types

The <types> element defines the data types that are used by the web service.

For maximum platform neutrality, WSDL uses XML Schema syntax to define data types.

WSDL Bindings

The <binding> element defines the data format and protocol for each port type.

WSDL Example

This is a simplified fraction of a WSDL document:

<message name="getTermRequest">

<part name="term" type="xs:string"/>

</message>


35 S.SHARMILA 2015-2016

<message name="getTermResponse">

<part name="value" type="xs:string"/>

</message>

<portType name="glossaryTerms">

<operation name="getTerm">

<input message="getTermRequest"/>

<output message="getTermResponse"/>

</operation>

</portType>

The TLS architect in charge of the Employee Service design decides to make adjustments

to the abstract service interface to apply current design standards. Specifically, naming

conventions are incorporated to standardize operation names

The revised Employee Service operation names.

Example

The two operation constructs with new, standardized names.

<operation name="GetWeeklyHoursLimit">

<input message="tns:getWeeklyHoursRequestMessage"/>

<output message="tns:getWeeklyHoursResponseMessage"/>

</operation>

<operation name="UpdateHistory">

<input message="tns:updateHistoryRequestMessage"/>

<output message="tns:updateHistoryResponseMessage"/>

</operation>

As explained in the Apply naming standards guideline, the use of naming standards

provides native support for intrinsic interoperability, a key contemporary SOA characteristic.

If entirely new tasks are defined, then they can be incorporated by new operations that

follow the same design standards as the existing ones.

If new functional requirements are identified that relate to existing operations, then a

common method of extending these operations is to add input and output values.

This allows an operation to receive and transmit a range of message combinations. Care

must be taken, though, to not overly complicate operations for the sake of potential reusability.

It often is advisable to subject any new proposed functionality to a separate analysis

process. Also, while it is desirable and recommended to produce entity-centric services that are


36 S.SHARMILA 2015-2016

completely self-sufficient at managing data associated with the corresponding entity domain,

there is a key practical consideration that should be factored in.

SOA COMPOSITION GUIDELINES

Service composability is a design principle, applied within the service-orientation design

paradigm, which encourages the design of services that can be reused in multiple solutions that

are themselves made up of composed services. The ability of the service to be recomposed is

ideally independent of the size and complexity of the service composition.

This principle is directly responsible for the agility promised by SOA as it promotes composing

new solutions by reusing existing services.

ENTITY-CENTRIC BUSINESS SERVICE DESIGN (A STEP-BY-STEP PROCESS):

Entity-centric business services represent the one service layer that is the least influenced

by others. Its purpose is to accurately represent corresponding data entities defined within an

organization's business models.

These services are strictly solution- and business process-agnostic, built for reuse by any

application that needs to access or manage information associated with a particular entity.

Be

cause they

exist

rather


37 S.SHARMILA 2015-2016

atomically in relation to other service layers, it is beneficial to design entity-centric business

services prior to others. This establishes an abstract service layer around which process and

underlying application logic can be positioned.

APPLICATION SERVICE DESIGN – TASKCENTRIC BUSINESS SERVICE DESIGN


38 S.SHARMILA 2015-2016

project architects then conclude that no overlap exists, which gives them the green light to

proceed with the design of the Employee Service. TLS invested in creating a standardized XML

data representation architecture (for their accounting environment only) some time ago. As a

result, an inventory of entity-centric XSD schemas representing accounting-related information

sets already exists. At first, this appears to make this step rather simple. However, upon closer

study, it is discovered that the existing XSD schema is very large and complex. After some

discussion, TLS architects decidefor better or for worsethat they will not use the existing schema

with this service at this point. Instead, they opt to derive a lightweight (but still fully compliant)

version of the chema to accommodate the simple processing requirements of the Employee

Service. They begin by identifying the kinds of data that will need to be exchanged to fulfill the

processing requirements of the "Get weekly hours limit" operation candidate. They end up

defining two complex types: one containing the search criteria required for the request message

received by the Employee Service and another containing the query results returned by the

service. The types are deliberately named so that they are associated with the respective

messages. These two types then constitute the new Employee.xsd schema file.

SIGNIFICANCE

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.

REFERENCE:




39 S.SHARMILA 2015-2016

UNIT IV

SOA platform basics


Development environment

Runtime

APIs

Operating system

The WS-Coordination framework exposes an Activation Service which supports the

creation of coordinators for specific protocols and their associated contexts. The process of

invoking

Message Processing Logic The part of a Web service and its surrounding environment that

executes a variety of SOAP message processing tasks. Message processing logic is performed by

a combination of runtime services, service agents , as well as service logic related to the

processing of the WSDL definition.

Business Logic The back-end part of a Web service that performs tasks in response to the

receipt of SOAP message contents. Business logic is application-specific and can range

dramatically in scope, depending on the functionality exposed by the WSDL definition. For

example, business logic can consist of a single component providing service-specific functions,

or it can be represented by a legacy application that offers only some of its functions via the Web

service.

SOA support in J2EE:

It is important for application development to allow Internet communication between programs.

Today's applications communicate using Remote Procedure Calls (RPC) between objects

like DCOM and CORBA, but HTTP was not designed for this. RPC represents a compatibility

and security problem; firewalls and proxy servers will normally block this kind of traffic.

A better way to communicate between application-specific

A better way to communicate between applications is over HTTP, because HTTP is

supported by all Internet browsers and servers. SOAP was created to accomplish this. SOAP

provides a way to communicate between applications running on different operating systems,

with different technologies and programming languages.


40 S.SHARMILA 2015-2016

SOAP Building Blocks

A SOAP message is an ordinary XML document containing the following elements:

An Envelope element that identifies the XML document as a SOAP message

A Header element that contains header information

A Body element that contains call and response information

A Fault element containing errors and status information

Syntax Rules

Here are some important syntax rules:

A SOAP message MUST be encoded using XML

A SOAP message MUST use the SOAP Envelope namespace

A SOAP message MUST use the SOAP Encoding namespace

A SOAP message must NOT contain a DTD reference

A SOAP message must NOT contain XML Processing Instructions


<soap:Envelope

xmlns:soap="http://www.w3.org/2001/12/soap-envelope"

soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">

<soap:Header>

...

</soap:Header>

<soap:Body>

...

<soap:Fault>

...

</soap:Fault>

</soap:Body>

</soap:Envelope>

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

The SOAP Envelope Element

The required SOAP Envelope element is the root element of a SOAP message. This

element defines the XML document as a SOAP message.

Example


41 S.SHARMILA 2015-2016

<?xml version="1.0"? >

<soap:Envelope

xmlns:soap="http://www.w3.org/2001/12/soap-envelope"

soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding" >

...

Message information goes here

...

</soap:Envelope >

The xmlns:soap Namespace

Notice the xmlns:soap namespace in the example above. It should always have the value

of: "http://www.w3.org/2001/12/soap-envelope".

The namespace defines the Envelope as a SOAP Envelope.

If a different namespace is used, the application generates an error and discards the message.

The encodingStyle Attribute

The encodingStyle attribute is used to define the data types used in the document. This

attribute may appear on any SOAP element, and applies to the element's contents and all child

elements.

A SOAP message has no default encoding.

Java API for XML-based web services (JAX-WS):

Any application can have a Web Service component.

Web Services can be created regardless of programming language.

ASP.NET is a development framework for building web pages and web sites with

HTML, CSS, JavaScript and server scripting.

ASP.NET supports three different development methods:

Web Pages, MVC (Model View Controller), and Web Forms.

A Web Service Example

In the following example we will use ASP.NET to create a simple Web Service that

converts the temperature from Fahrenheit to Celsius, and vice versa:

<%@ WebService Language="VBScript" Class="TempConvert" %>

Imports System

Imports System.Web.Services

Public Class TempConvert :Inherits WebService

<WebMethod()> Public Function FahrenheitToCelsius

(ByVal Fahrenheit As String) As String

dim fahr

fahr=trim(replace(Fahrenheit,",","."))

if fahr="" or IsNumeric(fahr)=false then return "Error"

return ((((fahr) - 32) / 9) * 5)

end function


42 S.SHARMILA 2015-2016

<WebMethod()> Public Function CelsiusToFahrenheit

(ByVal Celsius As String) As String

dim cel

cel=trim(replace(Celsius,",","."))

if cel="" or IsNumeric(cel)=false then return "Error"

return ((((cel) * 9) / 5) + 32)

end function

end class

The first line in the example states that this is a Web Service, written in VBScript, and

has the class name "TempConvert":

<%@ WebService Language="VBScript" Class="TempConvert" %>

The next lines import the namespace "System.Web.Services" from the .NET framework:

Imports System

Imports System.Web.Services

The next line defines that the "TempConvert" class is a WebService class type:

Public Class TempConvert :Inherits WebService

The next steps are basic VB programming. This application has two functions. One to

convert from Fahrenheit to Celsius, and one to convert from Celsius to Fahrenheit

The only difference from a normal application is that this function is defined as a

"WebMethod()".

Use "WebMethod()" to convert the functions in your application into web services:

<WebMethod()> Public Function FahrenheitToCelsius

(ByVal Fahrenheit As String) As String

dim fahr

fahr=trim(replace(Fahrenheit,",","."))

if fahr="" or IsNumeric(fahr)=false then return "Error"

return ((((fahr) - 32) / 9) * 5)

end function

<WebMethod()> Public Function CelsiusToFahrenheit

(ByVal Celsius As String) As String

dim cel

cel=trim(replace(Celsius,",","."))

if cel="" or IsNumeric(cel)=false then return "Error"

return ((((cel) * 9) / 5) + 32)

end function

Then, end the class:

Java architecture for XML binding (JAXB) &Java API for XML Registries (JAXR) - Java

API for XML based RPC (JAX-RPC):


43 S.SHARMILA 2015-2016

ASP.NET Web Forms is a part of the ASP.NET web application framework and is

included with Visual Studio.

It is one of the four programming models you can use to create ASP.NET web

applications, the others are ASP.NET MVC, ASP.NET Web Pages, and ASP.NET Single Page

Applications.

Web Forms are pages that your users request using their browser.

These pages can be written using a combination of HTML, client-script, server controls,

and server code.

When users request a page, it is compiled and executed on the server by the framework,

and then the framework generates the HTML markup that the browser can render.

An ASP.NET Web Forms page presents information to the user in any browser or client

device.

Using Visual Studio, you can create ASP.NET Web Forms.

The Visual Studio Integrated Development Environment (IDE) lets you drag and drop

server controls to lay out your Web Forms page.

These properties, methods, and events are used to define the web page's behavior, look

and feel, and so on.

To write server code to handle the logic for the page, you can use a .NET language like

Visual Basic or C#.

ASP.NET and Visual Studio documentation spans several versions. Topics that highlight

features from previous versions may be useful for your current tasks and scenarios using the

latest versions.

Web Services Interoperability Technologies (WSIT):

Web Services Interoperability Technology (WSIT) is an open-source project started by

Sun Microsystems to develop the next-generation of Web service technologies. It provides

interoperability between Java Web Services and Microsoft's Windows Communication

Foundation (WCF).[1]

It consists of Java programming language APIs that enable advanced WS-* features to be

used in a way that is compatible with Microsoft's Windows Communication Foundation as used

by .NET. The interoperability between different products is accomplished by implementing a

number of Web Services specifications, like JAX-WS that provides interoperability between

Java Web Services and Microsoft Windows Communication Foundation.[2]

WSIT is distributed under the terms of the CDDL open-source license, and is currently

under development as part of project Metro.

WSIT is a series of extensions to the basic SOAP protocol, and so uses JAX-WS and

JAXB. It is not a new protocol such as the binary DCOM.

WSIT implements the WS-I specifications, including:


44 S.SHARMILA 2015-2016

Metadata

WS-MetadataExchange

WS-Transfer

WS-Policy

Security

WS-Security

WS-SecureConversation

WS-Trust

WS-SecurityPolicy

Messaging

WS-ReliableMessaging

WS-RMPolicy

Transactions

WS-Coordination

WS-AtomicTransaction

SOA support in .NET:

Based on Microsoft ASP.NET technology, in which code that runs on the server

dynamically generates Web page output to the browser or client device.Compatible with any

browser or mobile device. An ASP.NET Web page automatically renders the correct browser-

compliant HTML for features such as styles, layout, and so on.

Compatible with any language supported by the .NET common language runtime, such as

Microsoft Visual Basic and Microsoft Visual C#. Built on the Microsoft .NET Framework. This

provides all the benefits of the framework, including a managed environment, type safety, and

inheritance.

Flexible because you can add user-created and third party controls to them.Separation of

HTML and other UI code from application logic. A rich suite of server controls for common

tasks, including data access.

Powerful data binding, with great tool support.

Support for client-side scripting that executes in the browser.

Support for a variety of other capabilities, including routing,security,

performance, internationalization, testing, debugging, error handling and state management.

Web application programming presents challenges that do not typically arise

whenprogramming traditional client-based applications. Among the challenges are:

Implementing a rich Web user interface - It can be difficult and tedious to design and


45 S.SHARMILA 2015-2016

implement a user interface using basic HTML facilities, especially if the page has a complex

layout, a large amount of dynamic content, and full-featured user-interactive objects.

Separation of client and server - In a Web application, the client (browser) and server are

different programs often running on different computers (and even on different operating

systems). Consequently, the two halves of the application share very little information; they can

communicate, but typically exchange only small chunks of simple information.

Stateless execution - When a Web server receives a request for a page, it finds the page,

processes it, sends it to the browser, and then discards all page information. If the user requests

the same page again, the server repeats the entire sequence, reprocessing the page from scratch.

Put another way, a server has no memory of pages that it has processed—page are

stateless. Therefore, if an application needs to maintain information about a page, its stateless

nature can become a problem. Unknown client capabilities - In many cases, Web applications are

accessible to many users using different browsers. Browsers have different capabilities, making

it difficult to create an application that will run equally well on all of them.

Complications with data access - Reading from and writing to a data source in traditional

Web applications can be complicated and resource-intensive.

Complications with scalability - In many cases Web applications designed with existing

methods fail to meet scalability goals due to the lack of compatibility between the various

components of the application. This is often a common failure point for applications

under a heavy growth cycle.

Meeting these challenges for Web applications can require substantial time and effort.

ASP.NET Web Forms and the ASP.NET framework address these challenges in the following

ways:

Intuitive, consistent object model - The ASP.NET page framework presents an object

model that enables you to think of your forms as a unit, not as separate client and server pieces.

In this model, you can program the page in a more intuitive way than in traditional Web

applications, including the ability to set properties for page elements and respond to events.

In addition, ASP.NET server controls are an abstraction from the physical contents of an

HTML page and from the direct interaction between browser and server. In general, you can use

server controls the way you might work with controls in a client application and not have to

think about how to create the HTML to present and process the controls and their contents.

Common Language Runtime:


46 S.SHARMILA 2015-2016

The Common Language Runtime (CLR), the virtual machine component of Microsoft's

.NET framework, manages the execution of .NET programs. A process known as just-in-time

compilation converts compiled code into machine instructions which the computer's CPU then

executes.[1] The CLR provides additional services including memory management, type safety,

exception handling, garbage collection, security and thread management. All programs written

for the .NET framework, regardless of programming language, are executed by the CLR. All

versions of the .NET framework include CLR.

CLR implements the Virtual Execution System (VES) as defined in the Common

Language Infrastructure (CLI) standard, initially developed by Microsoft itself. A public

standard defines the Common Language Infrastructure specification.

ASP.NET web forms:

ASP.NET Web Forms are:

Based on Microsoft ASP.NET technology, in which code that runs on the server

dynamically generates Web page output to the browser or client device.

Compatible with any browser or mobile device. An ASP.NET Web page automatically

renders the correct browser-compliant HTML for features such as styles, layout, and so on.

Compatible with any language supported by the .NET common language runtime, such as

Microsoft Visual Basic and Microsoft Visual C#. Built on the Microsoft .NET Framework. This

provides all the benefits of the framework, including a managed environment, type safety, and

inheritance.

Flexible because you can add user-created and third party controls to them.

ASP.NET Web Forms offer:

Separation of HTML and other UI code from application logic.

A rich suite of server controls for common tasks, including data access.

Powerful data binding, with great tool support.

Support for client-side scripting that executes in the browser.

Support for a variety of other capabilities, including routing, security, performance,

internationalization, testing, debugging, error handling and state management.

ASP.NET Web Forms Helps You Overcome Challenges

Web application programming presents challenges that do not typically arise when

programming traditional client-based applications. Among the challenges are: Implementing a

rich Web user interface - It can be difficult and tedious to design and implement a user interface

using basic HTML facilities, especially if the page has a complex layout, a large amount of

dynamic content, and full-featured user-interactive objects.


47 S.SHARMILA 2015-2016

Separation of client and server - In a Web application, the client (browser) and server are

different programs often running on different computers (and even on different operating

systems). Consequently, the two halves of the application share very little information; they can

communicate, but typically exchange only small chunks of simple information.

Stateless execution - When a Web server receives a request for a page, it finds the page,

processes it, sends it to the browser, and then discards all page information. If the user requests

the same page again, the server repeats the entire sequence, reprocessing the page from scratch.

Put another way, a server has no memory of pages that it has processed—page are stateless.

Therefore, if an application needs to maintain information about a page, its stateless

nature can become a problem.

Unknown client capabilities - In many cases, Web applications are accessible to many

users using different browsers. Browsers have different capabilities, making it difficult to

create an application that will run equally well on all of them. Complications with data

access - Reading from and writing to a data source in traditional Web applications can be

complicated and resource-intensive. Complications with scalability - In many cases Web

applications designed with existing methods fail to meet scalability goals due to the lack of

compatibility between the various components of the application. This is often a common failure

point for applications under a heavy growth cycle.

Meeting these challenges for Web applications can require substantial time and effort.

ASP.NET web service:

ASP.NET Web Forms and the ASP.NET framework address these challenges in the following

ways:

Intuitive, consistent object model - The ASP.NET page framework presents an object model that

enables you to think of your forms as a unit, not as separate client and server pieces.

In this model, you can program the page in a more intuitive way than in traditional Web

applications, including the ability to set properties for page elements and respond to events.

In addition, ASP.NET server controls are an abstraction from the physical contents of an

HTML page and from the direct interaction between browser and server. In general, you can use

server controls the way you might work with controls in a client application and not have to

think about how to create the HTML to present and process the controls and their contents.

Web Services Enhancements (WSE):

ASP.NET Web Forms bring to Web applications the familiar model of writing event handlers for

events that occur on either the client or server.


48 S.SHARMILA 2015-2016

The ASP.NET page framework abstracts this model in such a way that the underlying

mechanism of capturing an event on the client, transmitting it to the server, and calling the

appropriate method is all automatic and invisible to you.

The result is a clear, easily written code structure that supports event-driven development.

Intuitive state management - The ASP.NET page framework automatically handles the task of

maintaining the state of your page and its controls, and it provides you with explicit ways to

maintain the state of application-specific information.

This is accomplished without heavy use of server resources and can be implemented with or

without sending cookies to the browser.

Browser-independent applications - The ASP.NET page framework enables you to create all

application logic on the server, eliminating the need to explicitly code for differences in

browsers.

However, it still enables you to take advantage of browser-specific features by writing

client-side code to provide improved performance and a richer client experience. .NET

Framework common language runtime support - The ASP.NET page framework is built on the

.NET Framework, so the entire framework is available to any

ASP.NET application.

Your applications can be written in any language that is compatible that is with the runtime.

In addition, data access is simplified using the data access infrastructure provided by the

.NET Framework, including ADO.NET.

.NET Framework scalable server performance - The ASP.NET page framework enables you to

scale your Web application from one computer with a single processor to a multi-computer Web

farm cleanly and without complicated changes to the application's logic.

Features of ASP.NET Web Forms

Server Controls - ASP.NET Web server controls are objects on ASP.NET Web pages that run

when the page is requested and that render markup to the browser. Many Web server controls are

similar to familiar HTML elements, such as buttons and text boxes. Other controls encompass

complex behavior, such as a calendar controls, and controls that you can use to connect to data

sources and display data.

Master Pages - ASP.NET master pages allow you to create a consistent layout for the pages in

your application.

Deployment and Hosting - Visual Studio, ASP.NET, Azure, and IIS provide tools that help you

with the process of deploying and hosting your Web Forms application


49 S.SHARMILA 2015-2016

SIGNIFICANCE:

The runtime provides the following benefits:

Performance improvements.

The ability to easily use components developed in other languages.

Extensible types provided by a class library.

Language features such as inheritance, interfaces, and overloading for object-oriented

programming.

Support for explicit free threading that allows creation of multithreaded, scalable applications.

Support for structured exception handling.

Support for custom attributes.

Garbage collection.

Use of delegates instead of function pointers for increased type safety and security. For more

information about delegates, see Common Type System.

APPLICATION AREA:

the .net forms are used in all the online applications

REFERENCE:



UNIT V


50 S.SHARMILA 2015-2016

WS-BPEL basics


One can describe Web-service interactions in two ways: as executable business processes

and as abstract business processes.

A executable business process: models an actual behavior of a participant in a business

interaction.

An abstract business process: is a partially specified process that is not intended to be

executed. Contrary to Executable Processes, an Abstract Process may hide some of the required

concrete operational details. Abstract Processes serve a descriptive role, with more than one

possible use case, including observable behavior and/or process template.

WS-BPEL aims to model the behavior of processes, via a language for the specification

of both Executable and Abstract Business Processes. By doing so, it extends the Web Services

interaction model and enables it to support business transactions. It also defines an interoperable

integration model that should facilitate the expansion of automated process integration both

within and between businesses. Its development came out of the notion that programming in the

large and programming in the small required different types of languages.

WS-Coordination overview:

WS-Coordination is a Web Services specification developed by BEA Systems, IBM, and

Microsoft and accepted by OASIS Web Services Transaction TC in its 1.2 version. 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.


51 S.SHARMILA 2015-2016

However, this specification isn't enough to coordinate transactions among web services.

It only provides a coordination framework, and other specifications like WS-Atomic Transaction

or WS-BusinessActivity are needed for this purpose.

WS-Choreography:

Service choreography is a form of service composition[clarification needed] in which the

interaction protocol between several partner services[clarification needed] is defined from a

global perspective. The intuition underlying the notion of service choreography can be

summarised as follows:

―Dancers dance following a global scenario without a single point of control"

That is, at run-time each participant in a service choreography executes its part of it (i.e.

its role) according to the behavior of the other participants.[2] A choreography's role specifies

the expected messaging behavior of the participants that will play it in terms of the sequencing

and timing of the messages that they can consume and produce

Service choreography is better understood through the comparison with another paradigm

of service composition: service orchestration.

On one hand, in service choreographies the logic of the message-based interactions

among the participants are specified from a global perspective. In service orchestration, on the

other hand, the logic is specified from the local point of view of one single participant, called the

orchestrator.

In the service orchestration language BPEL, for example, the specification of the service

orchestration (e.g. the BPEL process file) can be deployed on the service infrastructure (for

example a BPEL execution engine like Apache ODE).

The deployment of the service orchestration specification creates the composed service.

In a sense, service choreography and orchestrations are two flips of the same coin.

On one hand, the roles of a service choreography can be extracted as service

orchestrations through a process called projection.

Through projection it is possible to realize skeletons, i.e. incomplete service

orchestrations that can be used as baselines to realize the web services that participate to the

service choreography.


52 S.SHARMILA 2015-2016

On the other hand, already existing service orchestrations may be composed in service

choreographies.

WS-Policy,:

Web Service Choreography (WS-Choreography) is a specification by the W3C defining

an XML-based business process modeling language that describes collaboration protocols of

cooperating Web Service participants, in which services act as peers, and interactions may be

long-lived and stateful. (Orchestration is another term with a very similar, but still different

meaning.)

The main effort to get a choreography, The W3C Web Services Choreography Working

Group, leaving WS-CDL as a Candidate Recommendation.

"Many presentations at the W3C Workshop on Web services of pointed to the need for a

common interface and composition language to help address choreography. The Web Services

Architecture Requirements Working Draft created by the Web Services Architecture Working

Group also lists the idea of Web service choreography capabilities as a Critical Success Factor,

in support of several different top-level goals for the nascent Web services architecture"

The problem of choreography was of great interest to the industry during that time efforts

such as WSCL (Web Service Conversation Language) and WSCI (Web Service Choreography

Interface) were submitted to W3C and were published as Technical Notes. Moreover

complementary efforts were launched

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.

WS-Policy is a W3C recommendation as of September 2007.

WS-Policy represents a set of specifications that describe the capabilities and constraints

of the security (and other business) policies on intermediaries and end points (for example,

required security tokens, supported encryption algorithms, and privacy rules) and how to

associate policies with services and end points.

If both provider and consumer specify a policy, an effective policy will be computed

which usually consists of the intersection of both policies.


53 S.SHARMILA 2015-2016

The new policy contains those assertions made by both sides which do not contradict

each other. However, synonymous assertions are considered incompatible by a policy

intersection.

This can easily be explained by the fact that policy intersection is a syntactic approach,

which does not incorporate the semantics of the assertions. Furthermore it ignores the assertion

parameters.

Opposed to what the name might suggest, a policy intersection is (although quite similar) not a

set-intersection.

WSSecurity:

Web Services Security (WS-Security, WSS) is an extension to SOAP to apply security to

Web services. It is a member of the Web service specifications and was published by OASIS.

The protocol specifies how integrity and confidentiality can be enforced on messages and

allows the communication of various security token formats, such as Security Assertion Markup

Language (SAML), Kerberos, and X.509. Its main focus is the use of XML Signature and XML

Encryption to provide end-to-end security.

1 Features

2 Use cases

2.1 End-to-end security

2.2 Non-repudiation

2.3 Alternative transport bindings

2.4 Reverse proxy/common security token

WS-Security describes three main mechanisms:

How to sign SOAP messages to assure integrity. Signed messages also provide non-

repudiation.

How to encrypt SOAP messages to assure confidentiality.

How to attach security tokens to ascertain the sender's identity.

The specification allows a variety of signature formats, encryption algorithms and

multiple trust domains, and is open to various security token models, such as:

X.509 certificates,

Kerberos tickets,

User ID/Password credentials,


54 S.SHARMILA 2015-2016

SAML Assertions, and

custom-defined tokens.

The token formats and semantics are defined in the associated profile documents.

WS-Security incorporates security features in the header of a SOAP message, working in

the application layer.

These mechanisms by themselves do not provide a complete security solution for Web

services. Instead, this specification is a building block that can be used in conjunction with other

Web service extensions and higher-level application-specific protocols to accommodate a

wide variety of security models and security technologies. In general, WSS by itself does not

provide any guarantee of security. When implementing and using the framework and syntax, it is

up to the implementor to ensure that the result is not vulnerable.

Key management, trust bootstrapping, federation and agreement on the technical details

(ciphers, formats, algorithms) is outside the scope of WS-Security.

End-to-end security

If a SOAP intermediary is required, and the intermediary is not or is less trusted,

messages need to be signed and optionally encrypted. This might be the case of an application-

level proxy at a network perimeter that will terminate TCP connections.

Non-repudiation

The standard method for non-repudiation is to write transactions to an audit trail that is

subject to specific security safeguards. However, if the audit trail is not sufficient, digital

signatures may provide a better method to enforce non-repudiation. WS-Security can provide

this.

Alternative transport bindings

Although almost all SOAP services implement HTTP bindings, in theory other bindings

such as JMS or SMTP could be used; in this case end-to-end security would be required.

Reverse proxy/common security token

Even if the web service relies upon transport layer security, it might be required for the

service to know about the end user, if the service is relayed by a (HTTP-) reverse proxy. A WSS

header could be used to convey the end user's token, vouched for by the reverse proxy.


55 S.SHARMILA 2015-2016

SIGNIFICANCE:

WS-Security adds significant overhead to SOAP processing due to the increased size of

the message on the wire, XML and cryptographic processing, requiring faster CPUs and more

memory and bandwidth.

An evaluation in measured 25 types of SOAP messages of different size and complexity

processed by WSS4J with both WS-Security and WS-SecureConversation on a Pentium 4/2.8

GHz CPU. Some findings were:

Encryption was faster than signing.

APPLICATION AREA:

Encryption and signing together were 2–7 times slower than signing alone and produced

significantly bigger documents.

Depending on the type of message, WS-SecureConversation either made no difference or

reduced processing time by half in the best case.

It took less than 10 milliseconds to sign or encrypt up to an array of 100 kilobytes, but it

took about 100~200 to perform the security operations for SOAP.

REFERENCE:


Computing Series from Thomas Erl), 2005.

GLOSSARY:

SOA: Service Oriented architecture

CPU: Central Processing Unit

SOAP:Simple Object Access Protocol

WS: Web Services

BPEL: Business Process Execution Language.

WSE: Web Service Enhancements


56 S.SHARMILA 2015-2016

a course material on it2401 - service oriented architecture it … · · 2015-08-13a course...

Documents