Unit-4 IT6801 SOA - unit 4 notes PDF

Preview

Summary

unit 4 notes...

Description

IT6801 SERVICE ORIENTED ARCHITECTURE

S.No.

Name of the Topic

Reference Book (Text Book)

UNIT IV - WEB SERVICES 1. Service descriptions – WSDL

Thomas Erl - Chapter 5.3

3.

Messaging with SOAP

Thomas Erl - Chapter 5.4

4.

Service discovery – UDDI

Thomas Erl - Chapter 5.3

5.

Message Exchange Patterns

Thomas Erl - Chapter 6.1

6.

Orchestration

Thomas Erl - Chapter 6.6

7.

Choreography

Thomas Erl - Chapter 6.7

WS Transactions

Thomas Erl - Chapter 6.3, 6.4, 6.5

Contents beyond syllabus

REST

2.

8. 9.

UNIT 4 - CSE/RMKCET

1

IT6801 SERVICE ORIENTED ARCHITECTURE

Web Services A Web service is a software designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages.

 Web applications are meant for application to human communication It uses HTML & Browsers.  Web services are for program to program communication It is based on XML & uses XML Technologies (SOAP, WSDL, UDDI). They also use Internet Protocols.

Fig: Core Web Service Standards

Service Roles (Temporary Classification of Web Services) It is based on the roles it assumes during the runtime processing of a message Service Requestor (Message Initiator) Intermediary Service (Message Relayer) Service Provider (Message recipient) Service Composition Member

UNIT 4 - CSE/RMKCET

2

IT6801 SERVICE ORIENTED ARCHITECTURE

Service Provider •

It is comparable to that of server in traditional distributed architecture.

•

A Service is a provider under the following conditions: – The service is invoked via an External source, such as service requestor. – The service provides a published service description offering information about its features and behavior.

•

Service Provider entity – the organization providing the Web service

•

Service Provider agent – the Web service itself, acting as an agent of the entity

Service Requestor •

It is comparable to that of client in traditional distributed architecture. Any unit of logic that issues a request message that is understood by a service provider.

•

A Web service takes on the service requestor role when: – Web service invokes a service provider by sending it a message – The Web service searches for and accesses the most suitable service provided by examining available service descriptions

•

Service requestor entity – the organization of individual requesting the service

•

Service requestor agent – the Web service itself, acting as an agent of the entity

Sometime service requestors are referred to as “service consumer”

Note: Same service can be a requestor and a provider in different message exchanges.

Fig: Service Provider (As the recipient of a request message) UNIT 4 - CSE/RMKCET

3

IT6801 SERVICE ORIENTED ARCHITECTURE

Fig: Service Requestor (As the sender of the request message)

Intermediaries •

Web service communications uses point-to-* paths. Messages can be processed by multiple intermediate routing and processing agents before arriving at destination

•

Services and Agents that do this are intermediaries

•

Passive intermediary simply routes without modifying the message

•

Active intermediary process and alter message contents before routing the message

Fig: Passive Intermediary UNIT 4 - CSE/RMKCET

4

IT6801 SERVICE ORIENTED ARCHITECTURE

Fig: Active Intermediary Service

Initial Sender •

Initial senders are simply service requestors that initiate the transmission of a message. They are the first web service in a message path.

Ultimate Receiver •

Ultimate Receiver is the last web service along a message path.

Service Compositions Any service can enlist one or more additional services to complete a given task. Further, any of the enlisted services can call other services to complete a given sub-task. Therefore, each service that participates in a composition assumes an individual role of service composition member.

Fig: A service composition consisting of four members UNIT 4 - CSE/RMKCET

5

IT6801 SERVICE ORIENTED ARCHITECTURE

Service Models (Permanent Classification of Web Services) It is based on the roles it assumes during the runtime processing of a message. Business Service Model Utility Service Model Controller Service Model

Business Service Model •

It encapsulates a distinct set of business logic.

•

It is ideally autonomous (but can participate in compositions).

•

Business Services are used within SOAs as: – As fundamental building blocks for the representation of business logic – To represent a corporate entity or information set – To represent business process logic – As service composition members

Utility Service Model •

It provides generic functionality usually not associated with business logic.

•

Utility services are used within SOAs as: – As services that enable characteristic reuse within SOA – As solution-agnostic intermediary services – As services that promote intrinsic interoperability – As the services with the highest degree of autonomy

Controller Service Model •

It assembles and coordinates other services to supply a business function.

•

It acts as a parent service to service composition members.

•

It is used within SOAs as: – To support and implement the principle of composability – To leverage reuse opportunities – To support autonomy in other services

UNIT 4 - CSE/RMKCET

6

IT6801 SERVICE ORIENTED ARCHITECTURE

SERVICE DESCRIPTIONS

Service Descriptions Service descriptions describes list of operations (and their specifications) supported by the web service, the input message accepted by the service and the output message returned by the service. It also describes the location of the web service. The primary service description document is WSDL (Web Service Description Language).

Fig: WSDL definitions enable loose coupling between services

Service Endpoints and Descriptions A WSDL describes the point of contact for a service provider, also known as the service endpoint or just endpoint. It provides a formal definition of the endpoint interface (so that requestors wishing to communicate with the service provider know exactly how to structure request messages) and also establishes the physical location (address) of the service. A WSDL service description (also known as WSDL service definition or just WSDL definition) can be separated into two categories: abstract description concrete description

WSDL Abstract Description It defines the interface characteristics of web service. Three main parts: 

portType (or interface) – It provides a high-level view of service interface. Sorts messages into groups of functions called operations.

UNIT 4 - CSE/RMKCET

7

IT6801 SERVICE ORIENTED ARCHITECTURE



Operation – It is a specific action performed by the service. (Similar to public method for components in traditional distributed applications).



Message – The parameters are represented as messages. An operation consists of a set of input and output messages.

Fig: WSDL Definition

WSDL Concrete Description The concrete description defines the transport and location information of the web service. The physical transport protocol is described in three parts: •

Binding – A binding represents one possible transport technology the service can use to communicate. SOAP is the most common form of binding, but others also are supported.

•

Port (or endpoint)– It represents physical address for the service

•

Service – The service represents a group of related ports or endpoints.

Metadata and Service Contracts •

WSDL definitions usually rely on XSD schemas to formalize the structure of messages. Policies provide rules, preferences, and processing details beyond what is expressed in the WSDL and schema.

UNIT 4 - CSE/RMKCET

8

IT6801 SERVICE ORIENTED ARCHITECTURE

•

The three service description documents WSDL Definition, XSD Schema and Policy can be classified as service metadata. A service contract is comprised of a collection of service descriptions and possibly additional documents.

Semantic Descriptions •

Most metadata focuses on technical information regarding data representation and processing requirements. Semantic descriptions refer to service’s behavioral characteristics.

•

Examples of service semantics include: – How a service behaves under certain conditions – How a service will respond to a specific condition – What specific tasks the service is best suited for

Description Advertisement and Discovery •

Advertisement refers to publishing service description by a service provider in registry. Discovery refers to finding suitable service description by a service requestor in registry. UDDI formed the first generation of Web service standard for registry or directory.

•

Central directories and registries allow humans and service requestors to: – Locate the latest versions of known service descriptions – Discover new Web services

UNIT 4 - CSE/RMKCET

9

IT6801 SERVICE ORIENTED ARCHITECTURE

Registries •

Public – They accept registrations from any organizations with or without Web services.

•

Private – It can be implemented within an organization to provide a central repository for descriptions of all services the organization develops, leases, or purchases.

UDDI Components •

Business Entities: It contains the descriptive information about the organization (or service provider entity) and about list of services it offers. This would include information such as names and descriptions in multiple languages, contact information and classification information.

•

Business services: The business service structure represents an individual web service provided by the business entity.

•

Binding Templates: It provides the technical information needed by applications to bind and interact with the Web service being described. It must contain either the access point for a given service or an indirection mechanism that will lead one to the access point.

•

tModels (Technical Model): It is used to represent unique concepts or constructs. Each distinct specification, transport, protocol or namespace is represented by a tModel. It contains addresses (URLs) and metadata about the technical documents.

UNIT 4 - CSE/RMKCET

10

IT6801 SERVICE ORIENTED ARCHITECTURE

MESSAGING WITH SOAP

The SOAP specification is universally accepted as the standard transport protocol for messages processed by Web services. The SOAP messaging framework fulfills the need for SOA's reliance on "independent units of communication," by supporting the creation of intelligence-heavy, document-style, and highly extensible messages.

SOAP It originally stood for Simple Object Access Protocol. Now SOAP is a standalone term. The main parts of SOAP are: Envelope: It is a container housing all parts of the message. Header: It contains metadata. Body: It contains the actual message contents (also referred to as the message payload). They are XML formatted data.

Fig: Basic Structure of SOAP Message

Header Blocks •

Header blocks outfit a message with information needed by all the services which process the message.

•

This relieves services from having to store message-specific logic.

•

Almost all WS-* extensions are implemented with header blocks

Examples of message features outfitted with using header block:

UNIT 4 - CSE/RMKCET

11

IT6801 SERVICE ORIENTED ARCHITECTURE

•

Processing instructions that may be executed by service intermediaries or ultimate receiver.

•

Routing or workflow information.

•

Security measures implemented in the message.

•

Reliability rules related to the delivery of the message.

•

Context and transaction management information.

•

Correlation information to associate request and response messages.

Message Styles Two messaging styles are supported by SOAP. They are: 

RPC-style Messages: The RPC calls between distributed components are serialized into XML documents, transported, and then deserialized into the native component format upon arrival. It is synchronous and tightly-coupled.



Document-style Messages: SOA relies on document-style messages to enable larger payloads, coarser interface operations, and reduced message transmission volumes between services. It is asynchronous and loosely-coupled.

Attachments To facilitate requirements for the delivery of data not so easily formatted into an XML document, the use of SOAP attachment technologies exist. Each provides a different encoding mechanism used to bundle data in its native format with a SOAP message. SOAP attachments are commonly employed to transport binary files, such as images.

Faults Finally, SOAP messages offer the ability to add exception handling logic by providing an optional fault section that can reside within the body area. The typical use for this section is to store a simple message used to deliver error condition information when an exception occurs.

Nodes •

Programs that services use to transmit and send SOAP messages are SOAP nodes

•

SOAP nodes must conform to SOAP specification, as a result SOAP messages are vendor-neutral

UNIT 4 - CSE/RMKCET

12

IT6801 SERVICE ORIENTED ARCHITECTURE

Node Types •

SOAP sender – a SOAP node that transmits a message

•

SOAP receiver – a SOAP node that receives a message

•

SOAP intermediary – a SOAP node that receives and transmits a message with optional processing

•

Initial SOAP sender – the first SOAP node to transmit the message

•

Ultimate SOAP receiver – the last SOAP node to receive a message

SOAP Intermediaries Forwarding intermediary: It is responsible for relaying the contents of a message to a subsequent SOAP node. Active intermediary: It is distinguished by the type of processing they perform above and beyond forwarding-related functions. It can alter existing header blocks, insert new ones, and execute a variety of supporting actions.

Fig: Different types of SOAP nodes involved with processing a message. Message Paths 

A message path refers to the route taken by a message from when it is first sent until it arrives at its ultimate destination. Therefore, a message path consists of at least one initial sender, one ultimate receiver, and zero or more intermediaries.

UNIT 4 - CSE/RMKCET

13

IT6801 SERVICE ORIENTED ARCHITECTURE



Design considerations relating to the path a message is required to travel often center around performance, security, context management, and reliable messaging concerns.



Note also that a message path is sometimes not predetermined. The use of header blocks processed by intermediaries can dynamically determine the path of a message. This may be the result of routing logic, workflow logic, or environmental conditions.

Fig: A message path consisting of three Web services.

Coarse grained Operations –Large documents representing entire business events or business objects –e.g. CRUD operations: CreateOrder, ReadOrder, UpdateOrder, DeleteOrder –NOT operations such as SetPrice(), SetProduct(), SetCustomer(), CompleteOrder()

UNIT 4 - CSE/RMKCET

14

IT6801 SERVICE ORIENTED ARCHITECTURE

SERVICE DISCOVERY - UDDI

The Universal Description, Discovery, and Integration (UDDI) protocol is a central element of the group of related standards that comprise the Web services stack. The UDDI specification defines a standard method for publishing and discovering the network-based software components of a service-oriented architecture (SOA).

A UDDI registry’s functional purpose is the representation of data and metadata about Web services. A registry, either for use on a public network or within an organization’s internal infrastructure, offers a standards-based mechanism to classify, catalog, and manage Web services, so that they can be discovered and consumed by other applications.

Description Advertisement and Discovery •

Advertisement refers to publishing service description by a service provider in registry. Discovery refers to finding suitable service description by a service requestor in registry. UDDI formed the first generation of Web service standard for registry or directory.

•

Central directories and registries allow humans and service requestors to: – Locate the latest versions of known service descriptions – Discover new Web services

UNIT 4 - CSE/RMKCET

15

IT6801 SERVICE ORIENTED ARCHITECTURE

Registries •

Public – They accept registrations from any organizations with or without Web services.

•

Private – It can be implemented within an organization to provide a central repository for descriptions of all services the organization develops, leases, or purchases.

UDDI Components •

Business Entities: It contains the descriptive information about the organization (or service provider entity) and about list of services it offers. This would include information such as names and descriptions in multiple languages, contact information and classification information.

•

Business services: The business service structure represents an individual web service provided by the business entity.

•

Binding Templates: It provides the technical information needed by applications to bind and interact with the Web service being described. It must contain either the access point for a given service or an indirection mechanism that will lead one to the access point.

•

tModels (Technical Model): It is used to represent unique concepts or constructs. Each distinct specification, transport, protocol or namespace is represented by a tModel. It contains addresses (URLs) and metadata about the technical documents.