WebServices & SOA

Web Services and Service Oriented Architecture

Snehal Masne www.TechProceed.com

Today’s 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

What’s 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.

 Very low level of application integration is expected. 

But may be increased in a flexible way.

 Focuses on messages and documents, not on APIs.

Web Services Framework  Describe  Expose—Services 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  Invoke—Remote application can invoke service  Respond—When 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

Component

Instance

Instance

Client

Network

Client

Client

Fundamentals of Web Services Web services stack

Fundamentals of Web Services Web services stack Service & Information Layer Types Message Operation Port Type

Service Implementation

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 Abstract (service interface definition) Concrete (service implementation Definition)

interface message ______________ service binding

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

endpoint/port

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

 Why?

Are all in XML

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.

 UDDI directory approach can be used when Web service information is

stored in well-known locations.

 UDDI provides inquiry and publishing API’s  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.

 Dynamically discovered Web services explicitly announce their arrival

and departure from the network.

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 Internet–based 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 it’s 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() { } }

(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.Add(i, j); proxy 10 20 HTTP request: Service1.asmx

obj obj.Add(10, 20);

.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

Not an end

A solution

Not a product

Achieved through Web

Only Web Services

Services and related technologies

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

To

Function oriented

Process oriented

Build to last

Build to change

Prolonged development cycles

Incrementally built and deployed

Application silos

Orchestrated solutions

Tightly coupled

Loosely coupled

Structuring applications using components or objects

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 • WS-RM • WS-RM policy • WS-Policy • WS-Addressing • WS-Notification

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

• UDDI • ebXML • WS-Discovery Security

Messaging

Service Discovery

Mediation

Governance

Management

• WSDM • WS-Management

• XSL • BPEL • WS-Policy • XQuery • XPath

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: 





Service Consumer needs tools to: 



Publish, categorize, define meta-data, virtualize Choose policy, participate in capacity planning & access workflow Facilitate service discovery, selection & access workflow

Operations Staff need to: 

 

Monitor service performance Troubleshoot problems, monitor dependencies Version services, virtualization & proxy management

Source: SOA Software, Inc., 2008.

Govern the SOA Cont’d 

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

Transformation (XSLT)

.NET

JCA

Web Services

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???