Essential SOA - Part 1

8/7/2019 Essential SOA - Part 1

1/21

Essential SOA Part 1

Real Time SOA Series

Feb 14 2008

April 4, 2011 2003 Satyam Computer Services LimitedAll Rights Reserved

Slide 1


2/21


Slide 2

Agenda

Quick context to SOA series

SOA Adoption

Tenants of SOA

XML Stack, INFOSET and WS-* Standards Howthey impact SOA and Design

SOAP Internals


3/21


Slide 3

Quick context to SOA series

Not about focusing on any specific SOA product or platformrather to enable the technical community to approach SOAand design as any other architecture style

Our sessions will focus on why and how it is gettingapplied than what a certain aspect is all about

More on understanding under the hood less onmethodology, approach etc

We will attempt to be on the ground with the reality (moredesign and less architecture) !!!

We will attempt to understand and apply SOA and designthru real life business problems


4/21


Slide 4

SOA Adoption Cutting thru the hype

SOA has been stuckin the second phase of what as a four-phase progression. Implementers have beenable to create Web services from legacy applications but not implement a process model. SOA for the most

part, is not enabling this yet, Maybe someday, but not today; I don't see it today. There is a great deal of

promise in SOA, noting that SOA has had many definitions. But thus far this promise has notbeen

realized. -Don Rippert, CTO Accenture (source -http://www.computerworlduk.com/technology/development/soa/news/index.cfm?newsid=6463, Nov 30th 2007)

SOA, hype-wise is widespread. SOA, implementation-wise is not. Thus, we are still attempting to close

the gap on what we think will work, and what actually does work, thus it's going to be a learning process for

the next few years. Accepting that, SOA vendors need to be constantly reinventing their approaches and

technologies, understanding that the game will change as we all become better at SOA. Admitting that does

not take away from your creditability, it adds to it. - David Linthicum (source -http://weblog.infoworld.com/realworldsoa/)

More SOA projects will highlight a lack of qualified SOA talent- David Linthicum on SOA predictions for2008 (source - http://weblog.infoworld.com/realworldsoa/archives/2007/12/linthicumas_soa.html, Dec 15th 2007)

Large consulting organizations will continue nottoget SOA- David Linthicum on SOA predictions for 2008(source - http://weblog.infoworld.com/realworldsoa/archives/2007/12/linthicumas_soa.html, Dec 15th 2007)
http://www.computerworlduk.com/technology/development/soa/news/index.cfm?newsid=6463http://weblog.infoworld.com/realworldsoa/http://weblog.infoworld.com/realworldsoa/archives/2007/12/linthicumas_soa.htmlhttp://weblog.infoworld.com/realworldsoa/archives/2007/12/linthicumas_soa.htmlhttp://weblog.infoworld.com/realworldsoa/archives/2007/12/linthicumas_soa.htmlhttp://weblog.infoworld.com/realworldsoa/archives/2007/12/linthicumas_soa.htmlhttp://weblog.infoworld.com/realworldsoa/http://www.computerworlduk.com/technology/development/soa/news/index.cfm?newsid=6463


5/21


Slide 5

Tenants of SOA

SOA is different things to different people

For the business community

A set of services that a business wants to expose to customers and clients

For the developer (technical) community

an architectural style which requires a service provider, requestor and a service

description.

a set of architectural principles and patterns which address characteristics such

as modularity, encapsulation, loose coupling, separation of concerns, reuse,

composable and single implementation

also a programming model complete with standards, tools , methods and

technologies such as the web services stack


6/21


Slide 6

Tenants of SOA

An SOA in production will evolve over a period of time enabling organizations to seamlessly

add, remove and modify services (business and technical) . Composability is key to service

orientation

Boundaries Are Explicit

Services are Autonomous

Services will share schema and contract

Service compatibility is based on policies


7/21


Slide 7

XML Stack, INFOSET and WS-* Standards

How they impact SOA

XML Stack , INFOSET and WS-* specifications

provide the required fidelity to enable composing

arbitrary services in a SOA

INFOSET provides abstract data model completely

free of the syntactic detail as expressed in XML 1.0 +

namespaces

Think of XML stack as a technology for

software integration and that is machine

readable and serializable over arbitrary

transports

SOAP and WS-* standards are modeled as

INFOSETS enabling different on the wire-representations (SOAP over HTTP, SMTP etc)

Almost all WS-* standards provide the

requisite binding information allowing them to

be defined and encoded as part of one or more

SOAP headers

This means an SOA can compose, deploy and

consume services regardless of the underlying

transport.

SOA has to guarantee security (integrity,

confidentiality and non repudiation) as services

composed may reside across federated boundariesTransportTransport

MessagingMessaging

DescriptioDescriptionn

DiscoveryDiscovery

QualityQuality

of Serviceof Service

Integration

HTTP, BEEP,IIOP, JMS, SMTPHTTP, BEEP,IIOP, JMS, SMTP

XML,EncodingXML,Encoding

SOAPSOAP

WSDLWSDL

UDDIUDDI

ReliableReliable

MessagingMessaging

Business Process Languages:Business Process Languages:

BPEL, XPDL, BPMLBPEL, XPDL, BPML

SecuritySecurity

TransactionsTransactions

CoordinationCoordination

Business Collaboration Language:Business Collaboration Language:

Choreography Description LanguageChoreography Description Language

ContextContext

Spec Source - http://www.oasis-open.org/specs/index.php
http://www.oasis-open.org/specs/index.phphttp://www.oasis-open.org/specs/index.php


8/21


Slide 8

Standard Bodies

Recommendation

Proposed Recommendation

Candidate Recommendation

Working Draft in Last Call

Working Draft in Development

Requirements

Note

Final version

Proposed Recommendation last chance to complain

Feature Complete time to implement

Are we done yet?

Snapshot of working group activity

Seed for working group activity

Heres what I think

OASIS Standards are approved within an OASIS Committee, submitted for public review,

implemented by at least three organizations, and finally ratified by the Consortium's

membership at-large

XML is a set of specifications from the World Wide Web Consortium(W3C)

Publicly, freely available specs at http://www.w3.org/TR

Universal industry support Anyone can contribute, comment and implement


9/21

SOAP Internals

SOAP is a simple, lightweight XML protocol forexchanging structured and typed information onthe Web

Overall design goal: KISS Can be implemented in a weekend

Stick to absolutely minimum of functionality

Make it Modular and Extensible No application semantics and no transport semantics

Think XML datagram

Spec Source - http://www.w3.org/TR/2007/REC-soap12-part1-20070427/


Slide 9


10/21

SOAP Internals Anatomy of SOAP

An extensible envelope expressing (mandatory)

what features and services are represented in a message;

who should deal with them,

whether they are optional or mandatory.

A set of encoding rules for data (optional)

Exchange instances of application-defined data types anddirected graphs

Uniform model for serializing abstract data models thatcan not directly be expressed in XML schema

A Convention for representation RPC (optional)

How to make calls and responses A protocol binding to HTTP and HTTP-EF(optional)


Slide 10
http://www.normos.org/ietf/rfc/rfc2616.txthttp://www.normos.org/ietf/rfc/rfc2774.txthttp://www.normos.org/ietf/rfc/rfc2774.txthttp://www.normos.org/ietf/rfc/rfc2616.txt


11/21

SOAP Internals SOAP and Composability

We are looking at two types of composability offeatures and services within a message: Vertical: multiple features and services can exist

simultaneously within the same message Horizontal: features and services within a message can

be intended for different recipients.


Slide 11


12/21

SOAP Internals - Vertical Composability

Allows for independent features to co-exist


13/21

SOAP Internals - Horizontal Composability

Allows for intermediaries


14/21

SOAP Internals

Modularity through XML Namespaces

The SOAP envelope namespace http://schemas.xmlsoap.org/soap/envelope/

Resolves to the SOAP Envelope Schema

The SOAP encoding namespace http://schemas.xmlsoap.org/soap/encoding/

Resolves to the SOAP Encoding Schema

Separate namespaces help enforce modularity

SOAP Envelope Schema provides formal definitionof Envelope


Slide 14
http://schemas.xmlsoap.org/soap/envelope/http://schemas.xmlsoap.org/soap/envelope/http://schemas.xmlsoap.org/soap/encoding/http://schemas.xmlsoap.org/soap/encoding/http://schemas.xmlsoap.org/soap/encoding/http://schemas.xmlsoap.org/soap/encoding/http://schemas.xmlsoap.org/soap/envelope/http://schemas.xmlsoap.org/soap/envelope/


15/21

SOAP Internals - The SOAP Envelope

A SOAP envelope defines a SOAP message

Basic unit of exchange between SOAP processors

SOAP messages are one-way transmissions

From sender through intermediaries to receiver

Often combined to implement patterns such asrequest/response

Messages are routed along a "message path"

Allows for processing at one or more intermediate nodesin addition to the ultimate destination node.

A node is a SOAP processor and is identified by a URI

Envelopes can be nested Only outer envelope is "active" to the receiving SOAP

processor


Slide 15


16/21

SOAP Internals - SOAP Headers

Allows for modular addition of features and

services Open-ended set of headers

Authentication, privacy, security etc. etc. Can address any SOAP processor using the "actor"

attribute

Can be optional/mandatory using the "mustUnderstand"attribute

Start web://bar web://toto web://foo


Slide 16


17/21

SOAP Internals - Semantics of SOAP Headers

Contract between sender and recipient Recipient is described by "actor" attribute

Allows for different types of negotiation:

Take it or leave it directly supported Let's talk about it can be built on top

And for different settings: Server dictated

Peer-to-peer Dictated by third party


Slide 17


18/21

SOAP Internals - SOAP Body

Special case of header Default contract between sender and ultimate recipient

Different from HTTP's header/body separation

Defined as a header with attributes set to:

Implicit mustUnderstand attribute is always"yes"

Implicit actor attribute is always "the end"

Start web://bar web://toto web://foo


Slide 18


19/21


Slide 19

SOAP Internals SOAP Binding

Model SOA for protocol independence

Minimal interdependencies between services propagating all the way to the protocol layerof a SOA

Communication Infrastructure used in an SOA is independent of the underlyingcommunication protocol

Can promote extreme reusability even at the code level !!

Achieved thru SOAP binding

SOAP provides a binding framework explaining the responsibilities of transporting a SOAPmessage from one node to another mode

Enables the SOAP processors to be protocol agnostic and protocol independent

SOAP Binding Framework

Declares the features provided by a binding.

Describes how the services of the underlying protocol are used to transmit SOAP messageinfosets.

Describes how the services of the underlying protocol are used to honor the contract formedby the features supported by that binding.

Describes the handling of all potential failures that can be anticipated within the binding.

Defines the requirements for building a conformant implementation of the binding beingspecified.


20/21

SOAP Internals - SOAP Stack Examples

SOAP

HTTP

TCP

Protocol Binding

SOAP

SIP

TCP

Protocol Binding

SOAP

SIP

UDP

Protocol Binding

SOAP

MIME Multipart

Protocol Binding

SOAP

SMTP

TCP

Protocol Binding

SOAP

TCP

Protocol Binding

SOAP

UDP

Protocol Binding

ServicesServices Services Services

Services Services Services


Slide 20


21/21

SOAP Envelope

HTTP Request

SOAP-HTTP Binding

SOAP Header

SOAP Body

POST /Accounts/Henrik HTTP/1.1

Host: www.webservicebank.comContent-Length: nnnn

Content-Type: text/xml; charset="utf-8"

SOAPAction: "Some-URI"

5

200

SOAP Internals - SOAP HTTP Binding


Slide 21

Documents

Essential SOA - Part 1