Essential SOA – Part 1

Real Time SOA Series

Feb 14 2008

April 4, 2011 ©2003 Satyam Computer Services Limited Slide 1

All Rights Reserved
 Agenda

 Quick context to SOA series

 SOA Adoption
 Tenants of SOA
 XML Stack, INFOSET and WS-* Standards – How
they impact SOA and Design
 SOAP Internals

April 4, 2011 ©2003 Satyam Computer Services Limited Slide 2

All Rights Reserved
 Quick context to SOA series

 Not about focusing on any specific SOA product or platform

rather to enable the technical community to approach SOA
and design as any other architecture style

 Our sessions will focus on “why” and “how” it is getting

applied than “what” a certain aspect is all about …

 More on understanding “under the hood” less on

methodology, approach etc

 We will attempt to be on the ground with the reality (more

design and less architecture) !!!

 We will attempt to understand and apply SOA and design

thru real life business problems

April 4, 2011 ©2003 Satyam Computer Services Limited Slide 3

All Rights Reserved
 SOA Adoption – Cutting thru the hype

“SOA has been stuck in the second phase of what as a four-phase progression. Implementers have been
able 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 not been
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 for
2008 (source - http://weblog.infoworld.com/realworldsoa/archives/2007/12/linthicumas_soa.html, Dec 15th 2007)

“Large consulting organizations will continue not to get SOA” - David Linthicum on SOA predictions for 2008
(source - http://weblog.infoworld.com/realworldsoa/archives/2007/12/linthicumas_soa.html, Dec 15th 2007)

April 4, 2011 ©2003 Satyam Computer Services Limited Slide 4

All Rights Reserved
 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

April 4, 2011 ©2003 Satyam Computer Services Limited Slide 5

All Rights Reserved
 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

April 4, 2011 ©2003 Satyam Computer Services Limited Slide 6
All Rights Reserved
 XML Stack, INFOSET and WS-* Standards –
How they impact SOA
 XML Stack , INFOSET and WS-* specifications
provide the required fidelity to enable composing Business Collaboration Language: Integration
arbitrary services in a SOA Choreography Description Language

 INFOSET provides abstract data model completely

free of the syntactic detail as expressed in XML 1.0 + Business Process Languages:
namespaces BPEL, XPDL, BPML
 Think of XML stack as a technology for
software integration and that is machine
Reliable Transactions
readable and serializable over arbitrary
transports
Messaging
Coordination Quality
 SOAP and WS-* standards are modeled as Security of Service
INFOSETS enabling different on the wire-
representations (SOAP over HTTP, SMTP etc) Context
 Almost all WS-* standards provide the
requisite binding information allowing them to UDDI Discovery
be defined and encoded as part of one or more
SOAP headers
WSDL Description
 This means an SOA can compose, deploy and
consume services regardless of the underlying SOAP
transport. Messaging
XML,Encoding
 SOA has to guarantee security (integrity,
confidentiality and non repudiation) as services HTTP, BEEP,IIOP, JMS, SMTP Transport
composed may reside across federated boundaries

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

April 4, 2011 ©2003 Satyam Computer Services Limited Slide 7

All Rights Reserved
 Standard Bodies

 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
Recommendation Final version

Proposed Recommendation Proposed Recommendation – last chance to complain

Candidate Recommendation Feature Complete – time to implement

Working Draft in Last Call Are we done yet?

Working Draft in Development Snapshot of working group activity

Requirements Seed for working group activity

Note Here’s what I think…

April 4, 2011 ©2003 Satyam Computer Services Limited Slide 8

All Rights Reserved
 SOAP Internals

 SOAP is a simple, lightweight XML protocol for

exchanging structured and typed information on
the 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/

April 4, 2011 ©2003 Satyam Computer Services Limited Slide 9

All Rights Reserved
 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 and
directed graphs
 Uniform model for serializing abstract data models that
can 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)

April 4, 2011 ©2003 Satyam Computer Services Limited Slide 10

All Rights Reserved
 SOAP Internals – SOAP and Composability

 We are looking at two types of composability of

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

April 4, 2011 ©2003 Satyam Computer Services Limited Slide 11

All Rights Reserved
 SOAP Internals - Vertical Composability

 Allows for independent features to co-exist

<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope”
SOAP:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP:Header>
<a:authentication …>…</a:authentication>
<s:security …> … </s:security>
<t:transactions …> … </t:transactions>
<p:payment …> … </p:payment>
</SOAP:Header>
<SOAP:Body>
<m:mybody> …
<m:mybody> … </m:mybody>
</m:mybody>
</SOAP:Body>
</SOAP:Envelope>

April 4, 2011 ©2003 Satyam Computer Services Limited Slide 12

All Rights Reserved
 SOAP Internals - Horizontal Composability

 Allows for intermediaries

<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope”
SOAP:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP:Header>
<a:authentication actor="intermediary a"…>…</a:authentication>
<s:security actor="intermediary b"…> … </s:security>
<t:transactions actor="intermediary c"…> … </t:transactions>
<p:payment
<p:payment actor="destination"…>
actor="destination"…> …
… </p:payment>
</p:payment>
</SOAP:Header>
<SOAP:Body>
<m:mybody> …
<m:mybody> … </m:mybody>
</m:mybody>
</SOAP:Body>
</SOAP:Envelope>

April 4, 2011 ©2003 Satyam Computer Services Limited Slide 13

All Rights Reserved
 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 definition
of Envelope

April 4, 2011 ©2003 Satyam Computer Services Limited Slide 14

All Rights Reserved
 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 as
request/response
 Messages are routed along a "message path"
 Allows for processing at one or more intermediate nodes
in 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

April 4, 2011 ©2003 Satyam Computer Services Limited Slide 15

All Rights Reserved
 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

April 4, 2011 ©2003 Satyam Computer Services Limited Slide 16

All Rights Reserved
 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

April 4, 2011 ©2003 Satyam Computer Services Limited Slide 17

All Rights Reserved
 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

April 4, 2011 ©2003 Satyam Computer Services Limited Slide 18

All Rights Reserved
 SOAP Internals – SOAP Binding
 Model SOA for protocol independence
 Minimal interdependencies between services propagating all the way to the protocol layer
of a SOA

 Communication Infrastructure used in an SOA is independent of the underlying

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

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

 Describes how the services of the underlying protocol are used to honor the contract formed
by 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 being
specified.

April 4, 2011 ©2003 Satyam Computer Services Limited Slide 19

All Rights Reserved
 SOAP Internals - SOAP Stack Examples

Services Services Services

SOAP SOAP SOAP

Protocol Binding Protocol Binding Protocol Binding
HTTP SIP SIP

TCP TCP UDP

Services Services Services Services

SOAP SOAP SOAP SOAP

Protocol Binding Protocol Binding Protocol Binding Protocol Binding
MIME Multipart SMTP TCP UDP

TCP
…

April 4, 2011 ©2003 Satyam Computer Services Limited Slide 20

All Rights Reserved
 SOAP Internals - SOAP HTTP Binding

POST /Accounts/Henrik HTTP/1.1 SOAP-HTTP Binding

Host: www.webservicebank.com HTTP Request
Content-Length: nnnn SOAP Body
Content-Type: text/xml; charset="utf-8" SOAP Header
SOAPAction: "Some-URI"
SOAP Envelope
<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/"
SOAP:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP:Header>
<t:Transaction xmlns:t="some-URI" SOAP:mustUnderstand="1">
5
</t:Transaction>
</SOAP:Header>
<SOAP:Body>
<m:Deposit xmlns:m="Some-URI">
<m:amount>200</m:amount>
</m:Deposit>
</SOAP:Body>
April 4,</SOAP:Envelope>
2011 ©2003 Satyam Computer Services Limited Slide 21
All Rights Reserved