Web Services and Service Oriented Architecture

Snehal Masne
www.TechProceed.com

Todays Web
Web designed for application to human interactions
Served very well its purpose:
Information sharing: a distributed content library Enabled B2C e-commerce Non-automated B2B interactions

How did it happen?

Built on very few standards

Shallow interaction model: very few assumptions made

about computing platforms Result was ubiquity

Problems
Involve a whole learning curve Not based on standardized rules and specifications

Module A

CORBA

Module B

CORBA

CORBA

Module C Module A
RMI

Module B

Whats next?
The Web is everywhere. There is a lot more we can do!
E-marketplaces. Open, automated B2B e-commerce. Business process integration on the Web. Resource sharing, distributed computing.

Current approach is ad-hoc on top of existing standards.

e.g., application-to-application interactions with HTML

forms. Goal: enabling systematic application-to-application interaction on the Web.

Web Services
Provide
Standardized method of communication between software applications

Distributed components are interfaced via non-object-specific protocols

Module A C++ Module B Java

What is a web service?

W3C Definition:
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 artefacts and supports direct interactions with other software applications using XML based messages via internetbased protocols

Other definitions
Web services is an effort to build a distributed computing platform

for the Web. enabling systematic application-to-application interaction on the Web.

Designing Web Services

Goals Enable universal interoperability. Widespread adoption, ubiquity: fast!
Enable (Internet scale) dynamic binding.
Efficiently support both open (Web) and more constrained

environments.

Requirements Based on standards. Pervasive support is critical. Minimal amount of required infrastructure is assumed.

Only a minimal set of standards must be implemented. But may be increased in a flexible way.

Very low level of application integration is expected.

Focuses on messages and documents, not on APIs.

Web Services Framework

Describe ExposeServices register in a repository providing
Business information (White pages) Service information (Yellow pages) Binding information (Green pages) describing how to connect and

use the services InvokeRemote application can invoke service RespondWhen service is invoked, results are returned to the requester Manage/Govern Provided structure and process control

Fundamentals of Web Services

A web service is a programmable component that provides a service and is accessible over the Internet.

Instance

Client

Component

Instance

Network

Client

Instance

Client

Fundamentals of Web Services

Web services stack

Fundamentals of Web Services

Web services stack
Service & Information Layer
Types Message Operation Service Implementation Port Type Binding Port

Web Service Interface (WSDL)

Service

Using WSDL
1. 2. 3.

4. 5.
6.

Describe the message interchange formats the service can support WSDL may define where the service is available and what communications protocol is used to talk to the service. As extended IDL: WSDL allows tools to generate compatible client and server stubs. Allows industries to define standardized service interfaces. Allows advertisement of service descriptions, enables dynamic discovery and binding of compatible services. Provides a normalized description of heterogeneous applications.

WSDL Document
<definition> Abstract (service interface definition) Concrete (service implementation Definition)

interface message ______________ service binding endpoint/port

Logical grouping of operations Data description using XML Schema Actual data structures used to pass data

Service Definition = Abstract + Concrete Service Description = Service Definition + Supplementary Definitions

XML-eXtensible Markup Language

In Web services, a message is an XML document information item as

defined by the XML Information

The Information items generally maps to the various features in an

XML document, such as elements, attributes, namespaces, and comments .

All the technologies in Web Services are XML based

Messaging Description Registry

Are all in XML

Why?

Fundamentals of Web Services

Web services stack
Packaging Layer Simple Object Access Protocol (SOAP) is a lightweight protocol designed for the exchange of information using XML Defines a modular packaging model and the encoding mechanisms for encoding data within modules .

Envelope Encoding rules

SOAP

RPC representation

Fundamentals of Web Services

Web services stack
Protocol Layer Any of the standard Internet protocols may be used to invoke web services over the network .

The initial definition focuses specifically on HTTP/1.1 and the encrypted HTTPS
FTP and SMTP can also be used

Invoking a web service

A client invoking a Web service

Discovery Layer
The Universal Description, Discovery, and Integration protocol, or

UDDI, specifies a protocol for querying and updating a common directory of Web service information. stored in well-known locations.

UDDI directory approach can be used when Web service information is

UDDI provides inquiry and publishing APIs Microsoft, IBM and SAP host the UDDI Business Registry.
Directory entry has three primary parts the service provider, Web

services offered, and bindings to the implementations. and departure from the network.

Dynamically discovered Web services explicitly announce their arrival

UDDI Universal Description Discovery 3. and Integration

1.
SW companies, standards bodies, and programmers populate the registry with descriptions of different types of services Marketplaces, search engines, and business apps query the registry to discover services at other companies

2.
Businesses populate the registry with descriptions of the services they support

Business Descriptions

Service Types

4.

Business uses this data to facilitate easier integration with each other over the Web

Web Services Pros and Cons

Pros Global method for describing and finding Internetbased business services Packaging and publishing of applications in a readily understood format New revenue streams through syndication of existing application as Web Service Cons Emerging technology Managing and Tracking changes is a challenge Transactions not fully addressed Multiple, evolving security standards Processing overhead

Future Vision and Challenges

Technology vendors plan to develop, market, and lend online Web

services to fulfill virtually any business function.

Companies will be able to simply search a public directory of

applications and download those that fit their needs.

Right now we have only tools and standards which are still not matured,

but its needless to say that its time to learn and practice some web services development

Challenges

Example
Google
A great search engine but what if I want my own GUI?

Google web service

Google offers a web service that performs searches for

you Why?
clients can build custom GUIs google.com can make money!
// ask google to search for us... google = new GoogleSearchService(); result = google.doGoogleSearch("4a8/TvZQFHID0WIWnL1CMmMx0sNqhG8H", txtSearch.Text, 0, 10, false, "", false, "", "", ""); // display resulting URLs... foreach (ResultElement re in result.resultElements) lstURLs.Items.Add(re.URL);

(1) Building a web service

Start by creating a project of type ASP.NET Web

Service

A web service is
One or more objects that respond to web-based

method calls
there is no GUI design to a web service only raw classes with methods public class Service1 : System.Web.Services.WebService { . . . }

Example
Looks like C#, but keep in mind these are web-based methods
client could be calling from any platform parameters passed using XML
public class Service1 : System.Web.Services.WebService { [WebMethod] public int Add(int x, int y) { return x + y; } [WebMethod] public string[] Attendees() { <<open DB, read attendees into array, return it>> } }

(2) Building a client

Start by creating a client WinForm, WebForm, console-based, anything you want! for fun, let's use VB

Reference the component

As usual, we need to reference component
this will activate IntelliSense this will make sure we call it correctly this will enable underlying XML +

SOAP communication

How?
project references, right-click, Add web reference
type URL for web service, e.g.

http://localhost/WebService/Service1.asmx
web server service name class name

Program against component

Treat web service like any other class!
use new to create instances make method calls pass parameters

Private Sub Button1_Click(...) Handles Button1.Click Dim i, j, k As Integer

i = CInt(TextBox1.Text) j = CInt(TextBox2.Text)
Dim obj As localhost.Service1 obj = New localhost.Service1() k = obj.Add(i, j) MessageBox.Show("Sum = " + k.ToString()) End Sub

Underlying execution
web service client app obj obj.Add(10, 20); obj.Add(i, j); proxy <Add> <n1>10</n1> <n2>20</n2> </Add> HTTP request: Service1.asmx

.asmx
Web server

Service Oriented Architecture

Allows a collection of services to communicate with each other and

unifies processes by collecting smaller service modules in an ad hoc manner. Operational Implementation Architectural Business Principles

SOA Concept
SOA enables a standards-based marketplace of service

consumers and service providers across an enterprise community or across the Web SOA is a specification-based architecture to transition the technical landscape to a standards-based, vendor independent, and loosely-coupled information sharing environment
Decoupling the service contract from the service

implementation Promoting design and invocation by contract

Basic Components of SOA

Basic Component of SOA

De-mystifying SOA
SOA is

A design philosophy
and Architecture

SOA is NOT

A technology or a
methodology

A means A solution Achieved through Web

Services and related technologies

Not an end Not a product Only Web Services

SOA Requirements

Agility Use of standards Separation of concerns Reuse Interoperability between different systems and programming languages. Clear and unambiguous description language Retrieval of the service Security

The Architecture
SOA - an evolution in objectives
From
Function oriented Build to last Prolonged development cycles

To
Process oriented Build to change Incrementally built and deployed

Application silos
Tightly coupled Structuring applications using components or objects

Orchestrated solutions
Loosely coupled Structure applications using services

Known implementation

Implementation abstraction

The Architecture
Building an SOA - a Closer look at services
Services in a Service-Oriented Architecture are always: Stateless: SOA services neither remember the last thing they were asked to do, nor care what the next is. Discoverable: A service must be discoverable by potential consumers of the service Self-describing: The SOA service interface describes, exposes, and provides an entry point to the service. Composable: SOA services are, by nature, composite.

The Architecture
Building an SOA - a Closer look at services

Single-instance Only one implementation of a given service should exist in an SOA. Loosely coupled Loose coupling allows the concerns of application features to be separated into independent pieces. Governed by policy Services are built by contract. Independent of location, language, and protocol Services are designed to be location-transparent and protocol/platform-independent

The Architecture
Building an SOA - a Closer look at services

As Coarse-grained as possible Services are typically coarse-grained business functions. Granularity is a statement of functional richness for a service the more coarse-grained a service is, the richer the function offered by the service. Potentially Asynchronous Asynchronous communication is not required of an SOA service, but it increases system scalability through asynchronous behavior and queuing techniques.

SOA Infrastructure Standards

WSS SAML XACML XML-Signature XML-Encryption WS-Trust WS-Policy WS-SecurityPolicy XKMS
Security Messaging

WS-RM WS-RM policy WS-Policy WS-Addressing WS-Notification

UDDI ebXML WS-Discovery
Service Discovery

Mediation

Governance

Management

XSL BPEL WS-Policy XQuery XPath

WSDM WS-Management

Steps to Implement SOA

Create/Expose Services 2. Register Services 3. Secure Services 4. Manage (monitor) Services 5. Mediate and Virtualize Services 6. Govern the SOA
1.

Source: SOA Software, Inc., 2008.

1. Create & Expose Services

Three primary choices

Rebuild existing applications using SOA paradigm Expose existing application logic as a set of services A combination of rebuild and expose

Enterprises typically use a combination of rebuild & expose Granularity is a key criterion for Web Service

2. Register Services

Application architects & developers need to know that a service exists Use a registry

Source: SOA Software, Inc., 2008.

3. Secure Services

May have inadvertently created gaping security holes May have exposed sensitive information principles of security

4. Manage Services

Look for potential disaster Need to be able to monitor for

Basic Availability Performance Throughput SLA agreement

Source: SOA Software, Inc., 2008.

5. Mediate & Virtualize Services

As SOA matures may need to: Introduce new versions Increase capacity by running multiple instances Provision applications to use specific instances of services Solution is Virtualization XML transformation can be used to allow consumers to use an old version of service that no longer exists. Consumers can provide different policy requirements for different classes of users Transport bridging can be provided E.g. HTTP and JMS Meditation between different standards implementation or versions of standards Mediation between different messaging styles RSS, SOAP, REST, Plain old XML (POX) Content-or-context-based routing to deliver advanced load-balancing and highavailability capabilities

Source: SOA Software, Inc., 2008.

6. Govern the SOA

Use a governance framework Design Time Issues Run Time Issues Tools needed for active participants Service Developer needs tools to:

Publish, categorize, define meta-data, virtualize Choose policy, participate in capacity planning & access workflow Facilitate service discovery, selection & access workflow Monitor service performance Troubleshoot problems, monitor dependencies Version services, virtualization & proxy management

Service Consumer needs tools to:

Operations Staff need to:

Source: SOA Software, Inc., 2008.

Govern the SOA Contd

Security Staff needs tools to:

Manage policy, report policy, check compliance, audit security Enterprise Architect needs tools to: Monitor application, manage relationships Define & validate design policy Assign services to proxy Virtualize services Enterprise IT Management

Manage reuse metrics Gather service reuse statistics Gather SOA statistics

Source: SOA Software, Inc., 2008.

Enterprise Service Bus (ESB)

ESB is the backbone of SOA that acts as a message

broker providing a message queuing system using industry standard specifications for messaging such as SOAP, or JMS (Java Message Service). Expert Sally Hudson, an IDC analyst, describes the Enterprise Service Bus as an open standards-based messaging means designed to provide interoperability between larger-grained applications and other components via simple standard adapters and interfaces.

ESB Architecture
ERP .NET Web Services Transformation (XSLT) JCA SOAP/ HTTP SOAP/ HTTP Connection Layer

Communication Layer Reliable Asynchronous Secure Messaging

SOAP/ HTTP C/C++ Legacy Application

Connection Layer

JMS

J2EE

According to the SOA

A Web service is:
An interface that describes a collection of

network accessible

operations Described using a service description language Published by making this service description available to users Found by sending queries to a registry matching service descriptions Bound-Invoked by using the information contained in the service description Composed with other services to create new services (service orchestration)

How it all works together

SOA vs CORBA & DCOM

Benefits
Provides location independence: Services need not be

associated with a particular system on a particular network Protocol-independent communication framework renders code reusability Offers better adaptability and faster response rate to changing business requirements Allows easier application development, run-time deployment and better service management

Benefits (cont.)
Loosely coupled system architecture allows easy

integration by composition of applications, processes, or more complex services from other less complex services Provides authentication and authorization of Service consumers, and all security functionality via Services interfaces rather than tightly-coupled mechanisms Allows service consumers (ex. Web Services) to find and connect to available Services dynamically

Thank You Questions???