SOA 101 Narendra Thota

Agenda
SOA and Web Services Web Services Standards Overview
XML/Schema SOAP WSDL

Java Technologies for Web Services JAX-RPC SOA Service Design Considerations

SOA and Web Services

Service Oriented Architecture (SOA) Definition An architectural style and a design principle for application development and integration
Leverages open standards to represent software assets as services Services can be composed into business processes (which are also services) in a declarative manner Right application of architectural principles
Modularity Encapsulation Loose coupling Separation of concerns Reuse

What is a service?
Services are functions or operations available across a network Well defined interfaces
Independent of any particular technology

Loosely coupled Well defined QoS capabilities and requirements Offered by service providers Public interface, policies and endpoint Consumed by service consumers Mediated by intermediaries Metering, monitoring, logging etc

Service description
Services are described using a standardized interface
Defines the service, its operations, and input and output Defines how the service is reached and its location

Web Services Description Language (WSDL) is a standard used to describe Web Services

Service registry
Publish services so internal and external partners can find them Facilitates service discovery both at design time and run time

What is a Web Service?

Web services are specialized implementations of services! Definition:
Interoperable software system
A Web service is a software system designed to support interoperable machine-to-machine interaction over a network.

Self describing interface

It has an interface described in a machine-processable format (specifically WSDL).

Interaction using messages

Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.

How do Web Services fit into SOA?

Service oriented architecture can be realized through the use of web services and web services technologies but it is not required The goal of SOA is to "componentize" key business processes
so that they can be more easily changed to meet new business conditions while also lowering the cost needed to manage and change the application Web Services provide a seamless approach to realize this goal

Web services defines the implementation level details for the evolution to SOA SOA enables the modeling of business problems in terms of discrete services
These modeled services are implemented as web services Key elements of a SOA include services, interfaces and componentization all of which can be realized by leveraging Web Services

SOA Architecture Layers

Business value of SOA

Maximization of business agility
Adapting rapidly and effectively to changes in the business environment

Business process integration across the enterprise

Cross-regional, cross-line-of-business, cross departmental

Business process integration with partners, suppliers and customers

Easier for partners to do business with you Easier for customers to find you and your services Easier for suppliers to provide

Better visibility and transparency of IT costs, IT value to the business and improved business intelligence Provides an abstraction mechanism for non-technical people to "assemble" software solutions without the need for low-level coding

Technical value of SOA

Service Orientation promotes few, coarse grained interactions between the service providers and consumers
reduces the dependencies between the two participating entities

SOA provides for well described service interfaces

which allows the use of services without the need to understand their implementation details

SOA facilitates technology and platform independence SOA reduces the complexities associated with application integration along with technology platform independence SOA manifests the same architectural model for both internal and external partner application integration

Web Services Standards Overview

Web services standards stack

XML and XML Schema

XML Is this valid? <?xml version="1.0" encoding="UTF-8"?> <employee>Emp 1</employee> <employee>Emp 2</employee> <employee>Emp 3</employee>

XML Schema Refresher course Simple content Complex content Mixed content Simple type
Built-in string, int, base64Binary, dateTime

Complex type Global elements and attributes

SOAP

SOAP
Definition
SOAP provides a simple and lightweight mechanism for exchanging structured and typed information between peers in a decentralized, distributed environment using XML

What the spec covers

SOAP envelope SOAP encoding rules SOAP RPC representation (the above are functionally orthogonal)

Features
Message structure Mechanism for data representation RPC mechanism Processing model Protocol binding framework Extensibility mechanisms Error handling mechanism

SOAP is not an acronym (anymore)

SOAP Message A SOAP Message consists of: A required Envelope element An optional Header element A required Body element An optional Fault element

SOAP Data Model and Encoding Data model for Section 5 SOAP Encoding is a generalization of common features found in most programming languages SOAP encoding specifies rules for serializing and deserializing between this data model and XML SOAP encoding is not mandatory; other data model and encodings can be used (ex. document/literal)

SOAP Message Exchange Model Fundamentally, one-way transmissions from sender to receiver But, SOAP messages are often combined to implement patterns such as request/response SOAP messages are routed along a message path which allows processing at one or more intermediate nodes in addition to the ultimate destination

Communication Style - RPC The Soap message has a reference to the invoked method. It also has the parameters information encoded according to the SOAP encoding standard, which ensures that the Xml elements map correctly to the programming entities. Suitable when
Existing component is made available as a web service

Disadvantages
SOAP encoding uses a non deterministic set of valid serializations for the same object which cannot be validated using Xml Schemas. Tight coupling exists between the message structure and the web service implementation code.

Communication Style Document Unencoded XML as message payload in the envelope Document style messages are essentially one-way For correlating request-response MEPs
Use custom headers containing correlation data (vertical extensibility) Depend on underlying transport

SOAP Faults Fault element: faultcode Machine readable

VersionMismatch, MustUnderstand, Client, Server (from the Envelope namespace)

faultstring Human readable faultactor Who caused the fault detail Application specific error information

Which style to use? rpc/encoded style for pure RPC requirements Document/literal style for all other requirements SOA requires Document style WS-I prohibits RPC style

SOAP Transport Bindings SOAP HTTP binding is included in the specification; other bindings are possible, but may not be standard Some bindings may have advantages JMS for guaranteed delivery, Multicast IP for broadcasting For HTTP binding, SOAP request is carried in HTTP request and SOAP response is carried in HTTP response SOAPAction HTTP header indicates intent of SOAP HTTP request

HTTP
Request GET / HTTP/1.1 Accept: Host: localhost Response HTTP/1.1 200 OK Content-Type: text/html;charset=ISO-8859-1 Transfer-Encoding: chunked Date: Fri, 05 May 2006 09:50:45 GMT Server: Apache-Coyote/1.1 <html> Methods GET, POST, PUT, DELETE, HEAD, TRACE, CONNECT Content-Types application/x-www-form-urlencoded, multipart/form-data

HTTP (x-www-form-urlencoded) Request: POST /some/resource HTTP/1.1 Content-type: application/x-www-form-urlencoded 0=example.getStateName&1=10023 Response: HTTP/1.1 200 OK Content-type: text/plain New York

HTTP (multipart/form-data)
Request: POST /some/resource HTTP/1.1 Content-type: multipart/form-data, boundary=AaB03x --AaB03x content-disposition: form-data; name="field1 Joe Blow --AaB03x content-disposition: form-data; name="pics"; filename="file1.gif Content-type: image/gif Content-Transfer-Encoding: binary ...contents of file1.gif... --AaB03x Response: HTTP/1.0 200 OK Content-type: text/plain OK

SOAP HTTP Example

POST /StockQuote HTTP/1.1 Content-Type: text/xml; charset="utf-8" Content-Length: nnnn SOAPAction: "http://electrocommerce.org/abc#MyMessage" <SOAP-ENV:Envelope... HTTP/1.1 200 OK Content-Type: text/xml; charset="utf-8" Content-Length: nnnn <SOAP-ENV:Envelope...

SOAP Fault Example

HTTP/1.1 500 Internal Server Error Content-Type: text/xml; charset="utf-8" Content-Length: nnnn <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body> <SOAP-ENV:Fault> <faultcode>SOAP-ENV:Server</faultcode> <faultstring>Server Error</faultstring> <detail> <e:myfaultdetails xmlns:e="Some-URI"> <message> My application didn't work </message> <errorcode> 1001 </errorcode> </e:myfaultdetails> </detail> </SOAP-ENV:Fault> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

Which transport to use?

Based on non-functional requirement Synchronous/Asynchronous communication Reliable message delivery Security Standards friendly Firewall friendly HTTP Standard, Synchronous, Unreliable JMS Non-standard, Asynchronous, Reliable (with persistent queues) HTTPS - Security Non functional requirements can also be met by extending the SOAP envelope

Extending SOAP messages Vertical extensibility

Headers carrying supplementary information relating to body of message

Horizontal extensibility
Headers targeted at intermediaries
Processing nodes that exist between the receiver and the sender These nodes can inspect, insert, delete or forward the message Useful to direct different parts of the message to different nodes

Also supports scalability

Set mustUnderstand=true to enforce processing

Binary data in SOAP messages Using base64Binary encoding is inefficient SOAP with Attachments (SwA)
SOAP message and related attachments are carried using multipart/related mime type HREF is used to reference attachment from SOAP message

Direct Internet Message Encapsulation (DIME)

Similar to SwA, smaller and efficient encoding

Upcoming standards
Message Transmission Optimization Mechanism (MTOM) XML-binary Optimized Packaging (XOP)

Types of web services

Type of web services SOAP Web Services Activity oriented REST Web Services Resource oriented (REST - REpresentational State Transfer Thesis by Roy Fielding)

WSDL

WSDL A WSDL Document describes

what a web service does where it can be found how the service can be invoked

WSDL Information Model

Abstract parts types, message, portType - Service interface definition Concrete parts binding, service - Service implementation definition

WSDL Sample

WSDL Authoring Style <definitions .... > <import namespace="uri" location="uri"/> * </definitions> Use of import: helps writing clearer service definitions, by separating the definitions according to their level of abstraction maximizes the ability to reuse service definitions easier to use and maintain

Types types element encloses data type definitions that are relevant for the exchanged messages WSDL prefers the use of XSD as the canonical type system <definitions .... > <types> <xsd:schema .... />* </types> </definitions>

Messages
Messages consist of one or more logical parts Each part is associated with a type using a message-typing attribute
element. Refers to an XSD element using a QName. type. Refers to an XSD simpleType or complexType using a QName.

<definitions .... > <message name="nmtoken"> * <part name="nmtoken" element="qname"? type="qname"?/> * </message> </definitions>

Port Types
A port type is a named set of abstract operations and the abstract messages involved. <wsdl:definitions .... > <wsdl:portType name="nmtoken"> <wsdl:operation name="nmtoken" .... /> * </wsdl:portType> </wsdl:definitions>

Transmission Primitives
WSDL has four transmission primitives that an endpoint can support:
One-way. The endpoint receives a message. Request-response. The endpoint receives a message, and sends a correlated message. Solicit-response. The endpoint sends a message, and receives a correlated message. Notification. The endpoint sends a message.

One-way: <wsdl:input name="nmtoken"? message="qname"/> Request-response: <wsdl:input name="nmtoken"? message="qname"/> <wsdl:output name="nmtoken"? message="qname"/> <wsdl:fault name="nmtoken" message="qname"/>*

Bindings
A binding defines message format and protocol details for operations and messages defined by a particular portType. There may be any number of bindings for a given portType

<wsdl:definitions .... > <wsdl:binding name="nmtoken" type="qname"> * <-- extensibility element (1) --> * <wsdl:operation name="nmtoken"> * <-- extensibility element (2) --> * <wsdl:input name="nmtoken"? > ? <-- extensibility element (3) --> </wsdl:input> <wsdl:output name="nmtoken"? > ? <-- extensibility element (4) --> * </wsdl:output> <wsdl:fault name="nmtoken"> * <-- extensibility element (5) --> * </wsdl:fault> </wsdl:operation> </wsdl:binding> </wsdl:definitions>

Ports
A port defines an individual endpoint by specifying a single address for a binding <wsdl:definitions .... > <wsdl:service .... > * <wsdl:port name="nmtoken" binding="qname"> * <-- extensibility element (1) --> </wsdl:port> </wsdl:service> </wsdl:definitions>

Services
A service groups a set of related ports together <wsdl:definitions .... > <wsdl:service name="nmtoken"> * <wsdl:port .... />* </wsdl:service> </wsdl:definitions>

Supported Bindings
SOAP 1.1 HTTP GET/POST MIME

SOAP Binding
<definitions .... > <binding .... > <soap:binding style="rpc|document" transport="uri"> <operation .... > <soap:operation soapAction="uri"? style="rpc|document"?>? <input> <soap:body parts="nmtokens"? use="literal|encoded" encodingStyle="uri-list"? namespace="uri"?> <soap:header message="qname" part="nmtoken" use="literal|encoded" encodingStyle="uri-list"? namespace="uri"?>* <soap:headerfault message="qname" part="nmtoken" use="literal|encoded" encodingStyle="uri-list"? namespace="uri"?/>* <soap:header> </input> <output> SAME AS INPUT </output> <fault>* <soap:fault name="nmtoken" use="literal|encoded" encodingStyle="uri-list"? namespace="uri"?> </fault> </operation> </binding> <port .... > <soap:address location="uri"/> </port> </definitions>

SOA Service Design Considerations

Service types
Business process services
A business process represents a sequence of activities that accomplish a business goal
For example, the process for applying for a loan at a bank can be represented as a business process service

Business process services are likely to be composed of/from other services e.g. createStockOrder, reconcileAccount, renewPolicy Business transaction services represent business functions that change the state of the business in some way e.g. checkOrderAvailability, createBillingRecord Business function services represent business functions that do not by themselves change the state of the business process e.g. calculateDollarValueFromYen, getStockPrice These are services that provide the technical or infrastructure functions required to support service interactions e.g. auditEvent, checkUserPassword, checkUserAuthorisation

Business transaction services

Business function services

Technical function services

Service design principles

Re-use
A service should be designed with re-use in mind Services should not expose any implementation or deployment details at their interface Services should be invocation protocol independent Services should not depend on deployment location for correct functioning Service interfaces should be concise, related and form complete behavioral sets of operations Service implementations should not store conversational state across multiple requests Service operation parameters should be coarse-grained and allied to operation semantics Service operation names should accurately reflect the operation's function to the consumer Locking resources for long periods of time is discouraged

Encapsulation

High cohesion

Statelessness Operational granularity Meaningful names for operations (semantic operations) Efficient resource utilization

Review !!

Loose coupling aspects