Merging the Grid Services

architecture with the web

services architecture
Service Oriented Architecture
Service Oriented Architecture is concerned with interoperable message interchange to or from
a message producer to a message consumer, while hiding the details of the message
processing.

Consumer Producer

MESSAGE
Service oriented architecture is intended to define loosely coupled and interoperable
services/applications and to define a process for integrating these interoperable components.
In SOA, the system is decomposed into a collection of network-connected components.
Applications and resources within a service oriented architecture should not be built as a
tightly coupled monolithic model. rather these applications are composed dynamically from
the deployed and available services in the network.
These services are dynamically discovered and bound together in a loosely coupled manner.
This dynamic construction allows the system to quickly respond to new business
requirements.
Service Oriented Architecture

Most commonly understood SOA architectures are WEB and WEB SERVICES.
Web:
web is a medium for message exchange between consumer and producer using a
common, well understandable and interoperable data model, HTML/XHTML.

Consumer(BR Producer(WE
OWSER) BSERVER)
MESSAGE
Html/xhtml
The above model was adequate for the common user agent based interaction. But when the
interaction pattern becomes complex such as business to business the above architecture needs
to be modified to adapt to any user agent or applications.
Solution is web services
Web service architecture extends the above interaction pattern further by adding the power
and expressiveness of XML.
Service Oriented Architecture

Any
Any producer
consumer
MESSAGE
XML

This architecture is further polished as follows

Service
Registry
description

discover publish

service
service service
consumer producer
MESSAGE Service
XML description
Service Oriented Architecture

Interaction pattern will be as follows

A service provider creates a service for interaction and exposes the services description for
the consumers with the necessary message format and transport bindings.
Service provider may decide to register this service and its description with a registry of
choice.
Service consumer can discover a service from a registry or directly from the service provider
and can start sending messages in a well defined XML format that both the consumer and
service can consume.
Web Service Architecture

A web service is a software system identified by a URI whose public interfaces are defined and
described using XML.
Other systems can interact with these systems using XML messages.
Web Service Architecture
XML RELATED TECHNOLOGIES AND THEIR RELEVANCE TO WEB SERVICES:
Web service agents(requesters and providers) exchange information in the form of messages.
These messages are defined in terms of XML Infoset, XML schema and XML namespace
XML MESSAGES AND ENVELOPING:
Here we look at how XML Web service messages are packaged and enveloped. The most
notable mechanism available is SOAP.
SOAP:
SOAP is a simple and lightweight XML Based mechanism for creating structured data packages
that can be exchanged between network applications.
Soap specification will be consisting of following components:
an envelope that defines a framework for describing message structure.
A set of encoding rules for expressing instances of application-defined data types
A convention for representing remote procedure calls and responses
A set of rules for using SOAP with HTTP
MESSAGE EXCHANGE PATTERNS such as request response, one way and peer to peer
conversations.
Web Service Architecture

SOAP MESSAGE STRUCTURE AND ITS SPECIFICATION:

<?xml version=1.0?>
<env:Envelope xmlns:env=http://www.w3.org/2003/05/soap-envelope>
<env:Header>
</env:Header>
<env:Body>
</env:Body>
</env:Envelope> SOAP ENVELOPE

SOAP Header

SOAP BODY
Web Service Architecture

A SOAP message is packaged in a SOAP:Envelope, which consists of zero or more SOAP:Header

and exactly one SOAP:Body.
The SOAP body and header can be further divided into blocks. While the SOAP body blocks are
intended for the final receiver the header blocks can be interpreted by the SOAP intermediaries.
Fig shows message exchange pattern.

Soap Soap
SOAP message SOAP Service
Request intermedia
message
Soap interme end
er ry
message diary point

Soap header Soap header

blocks will be blocks will be
processed processed
Web Service Architecture

SOAP header blocks carry information such as security, transactional information, correlation
and so on.
These intermediaries may act on these header blocks, add more blocks, change them or leave
them untouched.
These header blocks can be targeted to some intermediary or final receiver by the use of ROLES
attributes. The value of the roles attribute can be an address or a standard role name as defined
by the soap specification which are
next each SOAP intermediary and the ultimate receiver must act on this role
none SOAP nodes must not act in this role
ultimate receiver the ultimate receiver must act in this role
Web Service Architecture

SOAP Processing model:

The processing of a SOAP message is dependent on the role assumed by the processor.
SOAP headers are targeted using a role attribute. If the SOAP intermediary plays the role as
defined by the SOAP message it can then process the message.
There are two options related to processing:
If the SOAP header is targeted to this node and specified a mustUnderstand flag is set to
true then the processing node must process that header.
If there is not such requirement mustUnderstand flag is not set its up to the processing node
to decide on the processing of the message.
Once the processing is completed the message will be directed to the next node. The decision
on the next node selection is not specified by the SOAP specification. Therefore its now the
choice of the processing node to make such a decision.
Another interesting aspect of this message forwarding paradigm is the concept of relaying
SOAP headers a header can have a relay attribute value(true or false) to indicate that non
processed headers get forwarded to the next node. The default value is false this indicates a
SOAP node which is targeted by this header, will not forward this header to the next node.
Web Service Architecture

SOAP Features:
Features are reliability, security, correlation, routing and message exchange patterns such as
request/response, one way and peer to peer conversations.
SOAP feature has the following characteristics:
A unique name used to identify the feature and its properties.
A set of properties associated with a feature that can be used to control, constrain or identify
a feature.
Implementation of these features:
SOAP header blocks: SOAP HEADER BLOCKS are used to specify a feature.
SOAP binding protocol: in this case the features are directly implemented in the protocol
binding level.
Web Service Architecture

MESSAGE EXHANGE PATTERN:

Request/response
One-way
Peer to peer conversation etc.

SOAP MODULES:
Combined syntax and semantics of a set of SOAP headers are known as a SOAP module. a SOAP
module realizes one or more SOAP features.
Web Service Architecture

A service description is a set of documents that collectively describe the interface to a service(
service expectations and functionalities).
In addition to the interface definition, it must describe the semantics of a service such as the
relationship between the operations on a service, the meaning of an interface, or the basic
behavior of an operation.
A service must provide service descriptions with the details on its utilization syntax and
semantics.
Web Service Architecture

SERVICE MESSAGE DESCRIPTION MECHANISM:

My search service Google Service

description Description provides

Google Search
uses uses
provides interact
MY SEARCH uses News Service
Requester
interact service Description

provides
interact
News Service
Web Service Architecture

In the example a search engine service is exposing some of its capabilities to the external world
so that its clients can understand the syntax and semantics of that service and interact with the
service.
This service may then interact with other services using the description provided by those
services such as other search engines or news services.
Web service description language:
Quick overview of WSDL 1.1
WSDL is an XML infoset based document, which provides a model and XML format for
describing web services. This enables services to be described and enables the client to
consume these services in a standard way without knowing much on the lower level protocol
exchange binding including SOAP and HTTP.
Web Service Architecture
ABSTRACT
Types

Messages

PortType
PortType

definition

Binding

Binding

Port1<address>

Port1<address>

service
Web Service Architecture
As shown in the figure,
WSDL document can be divided into abstract definitions and agreed upon definitions.
Abstract section defines the SOAP messages in a platform independent language and a neutral
manner.
A message component describes the abstract format of a particular message that a Web service
sends or receives. The format of a message is typically described in terms of XML element
information items and attribute information items.
A message binding describes how the abstract content is mapped into a concrete format.
Abstract service definition components are Types, Messages, Operations, PortType and Binding.
Agreed upon definition components are service, port and binding. Agreed upon definitions
specify the wire message serialization, transport selection and other protocol implementation
aspects.
There can be two types of message encoding
Literal encoding
SOAP encoding
literal encoding specifies that the messages will be constructed according to the XML schema
SOAP encoding specifies that the messages are encoded using SOAP encoding rules.
Web Service Architecture

At the abstract level, the Types Component is a container for data type definition(describes the
elements in XML document)
A port type is an abstract set of operations(actions supported by the service) supported by one
or more endpoints.
A binding component described a concrete binding of a port type component and associated
operations to a particular concrete message format and transmission protocol.
A binding operation component describes a concrete binding for a particular operation of a port
type to a particular concrete message format.
A service component describes collection of related endpoints.
A port component defines the particulars of a specific end-point at which a given service is
available.
Web Service Architecture

Another important concept in WSDL are the message transfer format, messages can be
transferred as document or rpc parameters.
Document means that the message part is the body of the message, while RPC means that the
parts are just parameters of the call with specific signatures that are wrapped in an element.
Quick overview of WSDL 1.2
One of the major semantic clarifications we can discuss is regarding the concept of the service.
We will start with the concept of a resource
A resource is anything that can be addressable by a URI. These resources can be software
applications, hardware abstractions, web resources. every resource can be logically represented
by a set of interfaces such as manageability interfaces, operational interfaces and other such
interfaces.
A service is then treated as a realization of a single interface of a resource.
Web Service Architecture

abstract
types

messages

Interface A

Interface B
resource

Binding A Binding SOAP

Binding B Binding HTTP

endpoint endpoint

endpoint endpoint

Service(Interface B) Service(Interface a)
Web Service Architecture

Global XML Architecture Vision:

Global XML Architecture provides a modular, XML-based, open standards-based and federated
XML web services suite.
The primary goal of GXA is to define the syntax and semantics of a new family of Web-service-
specific protocols that take the basic capabilities of SOAP and XML to the next level of
interoperability
GXA attempts to define SOAP-based protocols to deal with security, routing, and more, using a
common and well-understood syntax and semantics.
Vision includes:
1. Providing standards-based and interoperable protocol definitions.
2. Reducing development efforts by separating infrastructure protocols from application and
transport protocols.
3. Providing open standards based designs for interoperable messaging across multiple
vendors.
Web Service Architecture

APPLICATIONS AND PROCESS

SOAP

GXA WS-* WSDL

XML INFORMATION SET

TRANSPORT PROTOCOLS
Web Service Architecture

The main principle of GXA includes:

XML Information set
Open standards
Service policy
security
Web Service Architecture

XML Data Model:

The core of web services is the XML data model or the XML information set.
Modularity: GXA is built using modular components rather than large, monolithic specifications
that offer end-to-end functionality.
Decentralization and federation:
There is an agreement between the parties involved in web service. This agreement is on the
syntax and semantics of the messages being exchanged. They may disagree on the software
accepting the message, programming languages used to build the system, operating system
utilized and the database system utilized.
GXA accepted the concept of decentralization, allowing the parties involved to make their own
decision on all parts of message processing including, security, policies requirements and
processing.
Therefore this concept of federation still allows these parties to exchange information in
meaningful formats.
Web Service Architecture

Application and Transport Neutral:

Application neutrality comes from the fact that its not defining any specific message exchange
protocol but instead defining standards based XML messages that needed to be exchanged.
Transport neutrality comes from the fact that the transport mechanism for message exchange is
a binding level decision done by the agreement between the service and the requester.
Web Service Architecture

SERVICE POLICY:
The web service policy framework provides a general purpose model and the corresponding
syntax to describe and communicate the respective policies of a web service.
Policy model and framework defines the following components:
Policy expression: an XML infoset representation of one or more policy assertions
Policy subject: an entity to which a policy can be bounded.
Policy assertion: an individual preference, requirement, capability or other property
Policy attachment: the mechanism for associating policy with one or more subjects is referred
to as a policy attachment.
Web Service Architecture
Web Service Architecture

Fig shows a sample policy expression with two policy statements containing the names QA and
QB respectively.
Policy Expressions and Assertions:
A policy Expression is a mechanism to convey a set of policy assertions. A policy expression is an
XML infoset with a combination of a top level <wsp:policy> container element, the policy
operators(<wsp:all>,<wsp:ExactlyOne>, <wsp:OneorMore>) and some attributes
(<wsu:id,Name, wsp:preference and soon) the attributes Name and ID are used to uniquely
identify the policy expression.
In the above fig there are two policy expressions with a default operation of <wsp:all> this
indicates that with all the policy assertions expressed, there is a present need to be satisfied.
This means that for the first policy expression QA both the assertions must be satisfied.
Web Service Architecture

A mechanism for policy expression attachement:

There are two mechanism by which we can attach a policy expression with one or more subjects
or resources. First is the XML based resources to attach policy expressions as part of the
definition.
Web Service Architecture

A mechanism for policy expression attachement:

Another way is by using wsp:policyattachment element