SOA and Web ServicesSreekanth Narayanan

Code samples in Java

SOA - Definition• SOA (Service Oriented Architecture) is a

collection of services, that communicate with each other.

• Wikipedia Definition• In computing, a service-oriented architecture

(SOA) is a flexible set of design principles used during the phases of systems development and integration. A deployed SOA-based architecture will provide a loosely-integrated suite of services that can be used within multiple business domains.

SOA is not Web Services• General misconception• SOA is more than web services • Starts from a business case then to processes,

management and governance• The Services on a SOA can be of many forms• SOA is characterized by a number of Quality

attributes.

Distributed Computing• Some history – importance of distributed

computing• Different technologies – Java RMI, DCOM,

CORBA and Web Services• A Comparison of the different technologies is

shown below

Quick ComparisonJava RMI DCOM CORBA Web services

Invocation

Mechanism

Java RMI CORBA RMI JAX-RPC, .NET..

Data format

Serialized Java

NDR CDR XML

Wire format

Stream Binary (Unlike WCP which encourages XML-based

SOAP)

GIOP SOAP

Transport protocol

JRMP or IIOP ORPC (Object RPC)

IIOP (Inter-ORB Protocol)

HTTP, SMTP, FTP, JMS…

Interface descriptio

n

Java Interface IDL OMG IDL WSDL

Discovery mechanis

m

RMI registry or JNDI

Windows Registry

COS Naming Service

UDDI

Programming

language &

platform

Java Agnostic (Visual C++, VB,

PowerBuilder, Delhi, etc.)

Agnostic Agnostic

Coupling Tight Tight Tight (Enables - but does not guarantee) loose

coupling

Why Web Services?• Some significant advantages • Get away from Binary based protocols (JMRP,

IIOP)• Text format communication, as SOAP is XML

based. • As SOAP, XML, HTTP and WSDL act as

universal standards, they are not vendor dependent. It works on most operating systems/programming languages.

Other advantages• Aims for Interoperability if designed correctly• Works across the internet• Is not tightly coupled to the connection• Removes vendor specific implementations to a large

extend due to standards used are universally accepted• Enables Loose Coupling between systems• Easy to develop and maintain due to the wide range of

tools and support available from platform vendors

Web Service Definition• The W3C definition says the following

– A Web service is a software application– identified by a URI,– whose interfaces and binding are capable of being

defined, described and discovered by XML artifacts and

– supports direct interactions with other software applications

– using XML based messages– via internet-based protocols

Anatomy of a XML based WSWeb Service System

WS runtime on Client

CLIENT

Marshal the Parameters

Bind data to XML

Create SOAP Message

Send on the Network to the

right Port

Network

SERVERGet the SOAP Response

Un Marshal the parameters

Return Object to the caller

Network

WS runtime on Server

Get XML Payload message

Un marshal the parameters

Invoke the method like a Local method

Get the response Objects

Bind Data to XML

Create SOAP Response

Send to the Caller

Contract based Services• Derived from a Contract between the

Consumer and the Producer• “Design by Contract” as a paradigm

• SOAP – Simple Object Access Protocol

SOAPThe W3C specification for SOAP mentions the following:– An extensible envelope that defines a framework for describing what

is in a message and how to process it (Standardized message format)• What features and services are represented • Who should deal with them• Whether they are optional or mandatory

– A set of encoding rules for expressing instances of application-defined data types and directed graphs

• That is, defines how data types gets serialized over the wire. E.g., how integer value 123 is represented on the wire

– And a convention for representing remote procedure calls and responses

• How to make calls and responses

SOAP Structure• SOAP Envelope is an

XML Document • Contains an

“Optional” header• A Mandatory Body

(Which contains the payload + any attachments)

SOAP Envelope

SOAP Header

SOAP Block

SOAP Block

SOAP Block

SOAP Block

SOAP Body

Sample SOAP XML RequestPOST /StockQuote HTTP/1.1

Host: www.stockquoteserver.com

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

Content-Length: nnnn

SOAPAction: "Some-URI"

<SOAP-ENV:Envelope

xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"

SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

<SOAP-ENV:Header>..</SOAP-ENV:Header>

<SOAP-ENV:Body>

<m:GetLastTradePrice xmlns:m="some-URI">

<symbol>DEF</Symbol>

</m: GetLastTradePrice>

</SOAP-ENV:Body>

</SOAP-Envelope>

SOAP Envelope

Specifies that this message is SOAP Encoded

SOAP Header SectionOptional

Specifies any of the “Control” information which cannot be sent on the payload (Typical

example is authentication data)

SOAP BodySpecifies the operation

being invokedIt also specifies all the

parameters(Called the Payload)

Sample SOAP XML ResponseHTTP/1.1 200 OK

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

Content-Length: nnnn

<SOAP-ENV:Envelope

xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"

SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>

<SOAP-ENV:Body>

<m:GetLastTradePriceResponse xmlns:m="Some-URI">

<Price>34.5</Price>

</m:GetLastTradePriceResponse>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

SOAP Envelope

Specifies that this message is SOAP Encoded

Shows that this is the response

Value returned from the function call

Shows the HTTP Response Status – 200 – OK, You will get the Error

codes here

SOAP Error Response SampleHTTP/1.1 500 Internal Server Error

Host: www.borland.com

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>

<d:message xmlns:d="some URI">

No Symbol found

</d:message>

</detail>

</SOAP-ENV:Fault>

</SOAP-ENV:Body>

SOAP Envelope

SOAP Fault Code

Detailed Error Message from the Server

Shows the HTTP Response Status –

ERROR

Uses of a SOAP Header • SOAP Headers are used for specifying “meta”

information which need not be sent on the Payload

• This is analogous to the HTTP headers and JMS Headers

• This allows meta data like Authentication information and routing information to be sent to the header. One example is routing information sent on the SOAPAction header.

Uses of a SOAP Header

<SOAP-ENV:Header>

<!– security credentials <s:credentials xmlns:s="urn:examples-org:security">

<username>sreekanth</username>

<password>pa$$worD</password>

</s:credentials>

</SOAP-ENV:Header>

• The above example shows a simple SOAP header which has the Authentication information within it.

• One of the key advantages of this is that the Header can be processed by a different server than that processing the payload.

Looking at the Contract - WSDL • WSDL is Web Services Description Language• It carries the following information

- Where is the Service located?- How to invoke the service?- What functions are available on a Service?

• It is analogous to a Java Interface. It is a Contract between the Consumer and the Provider of the Service.

More on the Contract

WSDL - Details • Machine-readable description of a Web service API

– An XML document based on the schema defined in W3C WSDL specifications

• Represents a contract between service requestor and provider– Interface information describing

• all publicly available functions• Data type information for all message requests and message

responses (including input and output parameters)• Binding information about the transport protocol to be used• Address information for locating the specified service

WSDL - Structure

Operation

ports

WSDL Document

Abstract Description

Types

Messages

portTypes

Operation1

Operation 2

Concrete Description

bindings

Services

What Data Types are used

Messages being sent back and forth

Operations/Functions which are supported by the service

How will the service be used on a specific network protocol. This section will contain all the SOAP specific details

Where the service is located. Helps in locating the server on which the service runs

WSDL - Example <?xml version="1.0"?>

<definitions name="StockQuote"

targetNamespace="http://example.com/stockquote.wsdl"

xmlns:tns="http://example.com/stockquote.wsdl"

xmlns:xsd1="http://example.com/stockquote.xsd"

xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"

xmlns="http://schemas.xmlsoap.org/wsdl/">

<types>

<schema targetNamespace="http://example.com/stockquote.xsd"

xmlns="http://www.w3.org/2000/10/XMLSchema">

<element name="TradePriceRequest">

<complexType>

<all>

<element name="tickerSymbol" type="string"/>

</all>

</complexType>

</element>

<element name="TradePrice">

<complexType>

<all>

<element name="price" type="float"/>

</all>

</complexType>

</element></schema></types>

Note this : will be referred from the messages section – defines input

Note this : will be referred from the messages section – defines output

WSDL - Example <message name="GetLastTradePriceInput">

<part name="body" element="xsd1:TradePriceRequest"/>

</message>

<message name="GetLastTradePriceOutput">

<part name="body" element="xsd1:TradePrice"/>

</message>

<portType name="StockQuotePortType">

<operation name="GetLastTradePrice">

<input message="tns:GetLastTradePriceInput"/>

<output message="tns:GetLastTradePriceOutput"/>

</operation>

</portType>

<binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType">

<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>

<operation name="GetLastTradePrice">

<soap:operation soapAction="http://example.com/GetLastTradePrice"/>

<input><soap:body use="literal"/></input>

<output><soap:body use="literal"/></output>

</operation>

</binding>

<service name="StockQuoteService">

<documentation>My first service</documentation>

<port name="StockQuotePort" binding="tns:StockQuoteBinding">

<soap:address location="http://example.com/stockquote"/>

</port>

</service>

</definitions>

This is the Operation supported by this Web Service

The input message and the output message for this operation

The input message and the output message for this operation

WSDL – Parts of the XML • Types – It is an optional part of the WSDL.• Defines the Content of the messages (Input

and Output)• Like data type definitions, • like “int a;” in Java• Custom Types need to be defined by XSDs• By default it is assumed that the types are

defined by the W3C XML Schema definition which can be found here http://www.w3.org/2000/10/XMLSchema

WSDL – Parts of the XML • If your Service uses only the default data types

defines in the W3C XML Schema specification, then you do not need a “Types” definition on the WSDL.

• If you have custom types of your own, for e.g, a “Employee” object consisting of some attributes like name, salary etc; then you need to define the employee as a custom type on the WSDL.

WSDL – Parts of the XML • The Message Element

• Contains the following• Name• 0 or more Part elements which in turn have

- a unique name- type which associates this part to the XSD type

<message name="GetLastTradePriceInput">

<part name="body“ element="xsd1:TradePriceRequest"/>

</message>

<message name="GetLastTradePriceOutput">

<part name="body" element="xsd1:TradePrice"/>

</message>

WSDL – Parts of the XML• The PortType Element

• PortType is like a “Class” in Java• It contains one or many operations• Operations are like methods• They define the input and output types

<portType name="StockQuotePortType">

<operation name="GetLastTradePrice">

<input message="tns:GetLastTradePriceInput"/>

<output message="tns:GetLastTradePriceOutput"/>

</operation>

<!-- More operations -->

</portType>

WSDL – Parts of the XML• The Binding Element <binding name="StockQuoteSoapBinding" type=

"tns:StockQuotePortType">

<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>

<operation name="GetLastTradePrice">

<soap:operation soapAction=

"http://example.com/GetLastTradePrice"/>

<input>

<soap:body use="literal"/>

</input>

<output>

<soap:body use="literal"/>

</output>

</operation>

</binding>

Specifies that this uses SOAP Protocol Binding – Could be HTTP or SMTP also

Declares the data format of the message

Specifies that this service uses SOAP

over HTTP

WSDL – Parts of the XML• The Binding Element specifies the exact method of

invoking the operation on the service. • For every Port Type there can be a different binding.• A SOAP binding has two parameters that influence

the form of the message– Style: determines how the soap:Body is structured –

RPC | Document– Use: Specifies the encoding rules of the SOAP message :

Encoded | Literal• Latest Services recommend the use of “Document

Literal” or “Document Literal Wrapped” Styles due to the higher interoperability.

WSDL 1.1 – Summary

How to implement SOAP Services ?• Java Based Services • JAX-WS vs JAX-RPC• JAX-WS is the recommended technology and

replaces JAX-RPC.

Advantages of SOAP Services• Simple to develop due to the large amount of tooling

support available from all the Vendors.• Very Rigid structure, follows the contract strictly• Large number of associated standards like WS-Security

etc make most of the associated corporate needs like Security and transactions very easy to implement.

• Standards based/Defined in all the WS standards. SOAP becomes heavy because of the amount of metadata it carries. SOAP is transport Agnostic and can be used over HTTP, SMTP etc.

• Can support Stateful services

Disadvantages of SOAP Services• SOAP has a considerable amount of metadata it carries on the

message• Though some of the sections on the SOAP message are

optional, the metadata tends to make the SOAP message structure rigid and heavier.

• SOAP is based on XML and the arrival of some of the lighter transports like JSON (Java Script Object Notation) has created the need for creating “lighter” services as well, which will perform better.

• The contract associated with SOAP services is sometimes an overhead. There are many simpler applications of the web services which do not warrant the need for a Contract.

• SOAP needs a full runtime stack to run.

Alternatives to SOAP Services• Representational State Transfer (REST)• A recent paradigm in Web services • WWW – biggest REST implementation • Stateless and lightweight• Tied to HTTP

REST• Representational State Transfer (REST) is a

style of software architecture for distributed hypermedia systems such as the World Wide Web

• The term Representational State Transfer was introduced and defined in 2000 by Roy Fielding in his doctoral dissertation

REST• REST-style architectures consist of clients and

servers. Clients initiate requests to servers; servers process requests and return appropriate responses.

• Requests and responses are built around the transfer of "representations" of "resources". A resource can be essentially any coherent and meaningful concept that may be addressed. A representation of a resource is typically a document that captures the current or intended state of a resource.

REST• REST supports the HTTP Methods

GET POST PUT DELETE

Retrieve a Collection Matching a Criterion. The Criteria might be

passed as an input parameter in the

HTTP Request.

Creates a New Record as part of the

collection, but retrieves and assigns a NEW ID to the item

which is created. This stands for a

CREATE operation in the simpler sense

Replaces the Collection with a

different collection. Stands for an

UPDATE

Deletes the entire Collection

REST• REST service can be implemented as a simple servlet. • REST Services can send information as TEXT, XML or

JSON.• As the request and the response does not contain any

meta data, this allows for light weight communication.

• It is very easy to invoke REST Services over AJAX from the script layer.

• REST does not need a full SOAP runtime stack to run. It only needs a HTTP Server.

REST• A Simple REST Service with the GET method

REST Vs SOAPSOAP REST

Size of the message SOAP message has a header and a body. In most cases, the need for sending the data as soap is not needed. Sending a SOAP message has considerable overhead due to the stringent structure

Rest enables sending smaller messages as response. As the technology is not tied to the use of SOAP for messaging, the designer can use XML, JSON or TEXT. This enables lightweight messaging.

Environment/Standards/Transport

Standards based/Defined in all the WS standards. SOAP becomes heavy because of the amount of metadata it carries. SOAP is transport Agnostic. If you have a heterogeneous messaging infrastructure to integrate, SOAP is a better solution.

REST is not defined in any of the standards. It is just an architectural style. It is tightly coupled to the HTTP transport. Rest is suited for mostly Web Driven Architectures where the base mode of transport is HTTP

Infrastructure Support/Security/Error Handling

SOAP based WS have extensive support within all the application containers. As SOAP provides for extensive storage of metadata within the message, a lot of infrastructure support can be built making use of the data which is sent. SOAP provides inherent support for Security and Error Handling

REST not being a standard, all the advantages mentioned in SOAP do not come by default. Most cases the implementation has to take care of the Security needs as well as the Error handling. This becomes difficult as Out of the Box Solutions for the same are not available and all is left to the Coder to implement.

Ease of Development/Change Management

Strict adherence to contract. The Contract needs to be established first. Tightly couples the Client due to the Contract.

Better chance of loose coupling due to the non existence of the contract. The Resource processing might be dependent on Parameters, even of they change, it is easier to default them on Server side without the Client changing anything.

When to Use SOAP Services• A formal contract must be established to describe the interface that the

web service offers. The Web Services Description Language (WSDL) describes the details such as messages, operations, bindings, and location of the web service.

• When the architecture must address complex nonfunctional requirements. Many web services specifications address such requirements and establish a common vocabulary for them. Examples include Transactions, Security, Addressing, Trust, Coordination, and so on.

• Most real-world applications go beyond simple CRUD operations and require contextual information and conversational state to be maintained. With the RESTful approach, developers must build this plumbing into the application layer themselves. (Stateful services)

• When you need to be transport agnostic, REST is tied to HTTP. (There are new frameworks which are enabling it on other transports)

When to Use REST Services• The web services are completely stateless. A good test is to consider whether

the interaction can survive a restart of the server.

• The service producer and service consumer have a mutual understanding of the context and content being passed along. Because there is no formal way to describe the web services interface, both parties must agree out of band on the schemas that describe the data being exchanged and on ways to process it meaningfully.

• Bandwidth is particularly important and needs to be limited. REST is particularly useful for limited-profile devices such as PDAs and mobile phones, for which the overhead of headers and additional layers of SOAP elements on the XML payload must be restricted.

• Web service delivery or aggregation into existing web sites can be enabled easily with a RESTful style. Developers can use technologies such as Asynchronous JavaScript with XML (AJAX) and toolkits such as JQuery to consume the services in their web applications. Rather than starting from scratch, services can be exposed with XML and consumed by HTML pages without significantly re-factoring the existing web site architecture.

Service Granularity• The concept of granularity is a relative measure of

how broad the interaction between a Service consumer and provider must be in order to address the need at hand.

Service Granularity an ExampleExample of Employee Details

• Dependents (An Array of Persons)• Skills (An Array of Skills)• Peers (An Array of Employees)• Direct Reports (An Array of Employees)

Service GranularityService Granularity

Fine Grained Services

Coarse Grained Services

Service GranularityService Granularity

Service Granularity in designAn architect has two general approaches to identifying Services: • Starting from the business-process or a business model and

decomposing that into sub-processes or sub-models recursively until some condition is met by which it can’t be decomposed any further. (Top Down)

• Start from the IT systems already implemented, expose Service interfaces from the APIs and access points that already exist, create Service Contracts on top of those interfaces, and then compose them together until the business process requirements are met (Bottom Up)

• Best approach, it depends: On a case to case basis, a mixture of the Top-Down and Bottom-up approach is found to be most successful.

Key Considerations for Secure Web ServicesWeb Service SecurityWeb Service Security

Authentication Authentication is defined as the process of verifying the identity of the sender or the requestor of the Service. Credentials are embedded in either the headers or body of the SOAP message. Standard Web technologies using passwords,X.509 certificates or LDAP credentials.

Authorization Authorization is the process of verifying what data/functionality the user has access to. The actions a user is able to perform should be based on the user’s credentials.

Data Privacy Standard SSL encryption using HTTPS can be used to provide data privacy between service requestors and service providers. In many cases, the service provider may not be the ultimate destination for the message. A service provider may act as a Integrator of Data, sending pieces of information to multiple services. The XML Encryption standard permits encryption of portions of the message allowing header and other information to be clear text while leaving the sensitive payload encrypted. Sensitive information can then be left encrypted to the ultimate destination, allowing true end-to-end data privacy.

Data Integrity and Verification

Digital Signatures can be used to verify whether a message has been tampered with. The Requested can sign the request and send to the provider and the provider can verify whether the message has been modified before it reached the provider. The XML Signature standard provides a means for signing parts of XML documents, providing end-to-end data integrity across multiple systems.

Types of attacksDenial of Service • Overwhelming the resources by continuously sending more

requests than what a server can handle • Web Services are very prone to Denial of Service attacks and

such attacks cannot be determined by the firewall• Usage of suitable Web Service throttling mechanisms.

Replay Attack • Replay attacks involve copying valid messages and repeatedly

sending them to a service. • Prevention similar to Denial of Service – Careful consideration

to be made to determine the Replay is genuine. • Pattern Identification takes time and needs to be mature

enough to prevent Replays

Types of attacksDictionary Attack • Dictionary attacks are used against systems which have

password based authentication • Brute Force Method• Password Strength• DoS caused by load, throttling/Pattern Identification.

SQL Injection • SQL Injection is a technique of passing additional values in to

String Arguments which are used as values in a where clause• If your message has a Customer ID field, this is a highly

probable field which will be directly used in a where clause. An attacker can insert an additional X’ OR 1=1 to the parameter and force the SQL to produce the entire data in the table as 1=1 is always true.

Security Best Practices• Implementing Role Based Access Control • Web Service Throttling• Identifying Clients through header data • Using the header data to throttle requests

Advanced Topics• SOAP Handlers – Basic Concept and uses.• Interoperability of Web Services• WS-I Basic Profile• Asynchronous Client APIs for invoking WS.

Conclusion• Web services provides a new paradigm for

program to program communication• JAX-WS provides a comprehensive set of Java

APIs • Tools hide a lot of complexity from you• REST is a paradigm to consider for simpler and

lightweight services. • SOA is not Web Services !

Thank You !!

Q & ASreekanth Narayanan