Sriram Krishnan, Ph.D. sriram@sdsc.edu NBCR Summer Institute, August 2010
What are Services Oriented Architectures? What are Web services? WSDL (Web Services Definition Language) Techniques for building Web services SOAP (Simple Object Access Protocol) REST (Representational State Transfer) Conclusions
SOA represents a model in which functionality is decomposed into small, distinct units (services), which can be distributed over a network and can be combined together and reused to create applications - Erl, Thomas (2005). Service-Oriented Architecture: Concepts, Technology, and Design.
*Source: "An Overview of Service-Oriented Architecture in Retail", MSDN Library
Reduce complexity by encapsulating the back-end implementation Service interfaces can be published and used by a number of clients Enable interoperability across systems through the use of open standards Web services (WSDL, SOAP, XML Schemas) are de facto standards Lend themselves well to the creation of workflows Support a loosely-coupled model where clients can bind to services at run-time Enables greater flexibility and fault tolerance
Many different definitions are available IBM (Gottschalk, et al): A Web service is an interface that describes a collection of operations that are network accessible through standardized XML messaging. Microsoft (on MSDN): A programmable application logic accessible using standard Internet protocols. To summarize: A Web service is a network service that provides a programmatic interface to remote clients
Accessible through standard Web protocols Independent of programming language and operating systems Interoperability is key Standard description language Publishable to a registry of services Discoverable via standard mechanisms
Service Registry 2. Lookup 1. Publish Service Requestor 3. Interact Service Provider
All information required to access a service is captured by the Web Service Description Web Services Description typically encapsulates: Interface definition Data types being used Protocol information
What does the service do? How is the service accessed? Where is the service located?
Web Services Definition Language (WSDL) Authors: IBM, Microsoft and others Standard to describe the invocation syntax of a Web Service WSDL is an XML document that describes Interface types for each port Content of messages it receives and sends Bindings of interfaces to protocols on the wire
public class TestStruct { } String varstring; int varint; public interface TestPortType { } public TestStruct echostruct(teststruct inputstruct);
Collection of all data types used in the Web service Any schema language can be used, typically XML Schemas <types> <schema xmlns="http://www.w3.org/2001/ XMLSchema"> <complextype name= TestStruct"> <all> <element name="varstring" type="string"/> <element name="varint" type="int"/> </all> </complextype> </schema> </types> public class TestStruct { String varstring; int varint; }
An abstract set of operations supported by one or more endpoints <porttype name="testporttype"> <operation name="echostruct"> <input message="tns:echostructrequest /> <output message="tns:echostructresponse /> </operation> </porttype> public interface TestPortType { public TestStruct echostruct(teststruct inputstruct); }
Details of how elements in PortType are converted into concrete representations on the wire <binding name="testsoapbinding" type= "tns:testporttype > <soap:binding style="rpc transport="http://schemas.xmlsoap.org/soap/http /> <operation name="echostruct"> <soap:operation soapaction="http://test.org/"/> <input> <soap:body use="encoded" namespace="http://test.org/" encodingstyle="http://schemas.xmlsoap.org/soap/encoding/"/> </input> <output> <soap:body use="encoded" namespace="http://test.org/" encodingstyle="http://schemas.xmlsoap.org/soap/encoding/"/> </output> </operation> </binding>
Service: A named collection of ports Port: How a binding is deployed to a particular endpoint <service name="testservice"> <port binding="tns:testsoapbinding name= test"> <soap:address location="http://test.org:8080/axis/services/test /> </port> </service>
Types Collection of all data types used by the Web service Message Definition of data being sent and received by every operation PortTypes Abstract set of operations and interface implemented by the service Binding Conversion of messages into concrete representations on the wire Port A physical end point to access a service interface Service Collection or set of ports
PortType: What does the service do? Binding: How is the service accessed? Service: Where is the service located?
What are Services Oriented Architectures? What are Web services? WSDL (Web Services Definition Language) Techniques for building Web services SOAP (Simple Object Access Protocol*) REST (Representational State Transfer) Conclusions
Mechanism for exchanging structured information in a decentralized environment HTTP (usually) + XML XML: De facto standard for representing data in a platform independent way HTTP: Simple universally supported protocol Interoperability: Common Data Format: XML Easily understood Network Protocol: HTTP
XML based Internet-based Independent of Programming language Transport mechanism Can be used with protocols other than HTTP SMTP: Simple Mail Transfer Protocol JMS: Java Message Service
POST /serv/echo HTTP/1.1 Host: www.test.org Content-Type: text/xml Content-Length: 357 SoapAction: http://test.org/ <SOAP-ENV:Envelope xmlns:soap-env = http://schemas envelope SOAP-ENV:encodingStyle= http:// /encoding > <SOAP-ENV:Body> <m:echostructrequest xmlns:m= http://test.org/ > <inputstruct> <varstring>nbcr Summer Institute</varString> <varint>2010</varint> </inputstruct> </m:echostructrequest> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
HTTP/1.1 200 OK Content-Type: text/xml Content-Length: 343 <SOAP-ENV:Envelope xmlns:soap-env= http:// /envelope/ SOAP-ENV:encoding= http:// /encoding/ > <SOAP-ENV:Body> <m:echostructresponse xmlns= http://../ > <return> <varstring>nbcr Summer Institute</varString> <varint>2010</varint> </return> </m:echostructresponse> </SOAP-ENV:Body> </SOAP-Env:Envelope>
Use WSDL to describe the Web service Use a stub compiler to generate source code Implement the business logic provided by the service interface Deploy the service into a service container On the client-side, use the stubs to access Web service
Apache Axis: http://ws.apache.org/axis/ One of the most popular toolkits Used by several projects here like NBCR, GEON, CAMERA, GLEON Axis2: http://ws.apache.org/axis2/ Microsoft.NET: http://msdn.microsoft.com/webservices/ SUN: http://java.sun.com/webservices/ Several other lightweight implementations: Python - ZSI: http://pywebsvcs.sourceforge.net/ Perl - SOAP::Lite: http://www.soaplite.com/
Pros De facto standard for building Web services Services can implement an arbitrary (and unlimited) set of operations, described by the WSDL Transport agnostic can work with protocols other than HTTP Availability of development tools Good error handling Designed to work in a distributed environment, in the presence of intermediaries Cons Very verbose, because of the presence of copious headers Requires tools for development harder to do it by hand
SOAP-based services viewed as very complex by a growing number of people Use of Representational State Transfer (REST) for simplification
Introduced in 2000 in the doctoral dissertation of Roy Fielding at UCI Principles Application state and functionality abstracted into resources Every resource uniquely addressable via unique URIs All resources share a uniform interface for the transfer of state between client and resources GET, POST, PUT, DELETE if using HTTP
For every resource (object), following operations are defined: Create (C) = PUT Retrieve (R) = GET Update (U) = POST Delete (D) = DELETE
A RESTful Web service is a simple service implemented using HTTP and the principles of REST State of server side is modeled as a collection of resources Comprises of the following aspects: The base URI for the Web service such as http://www.parts-depot.com/parts The MIME type of the data supported by the web service - typically XML, but could be others such as JSON A set of operations supported using standard HTTP methods (e.g. POST, GET, PUT or DELETE) Much simpler* than SOAP, especially for clients
GET: List or retrieve the contents of a resource http://www.parts-depot.com/parts would get a list of all parts http://www.parts-depot.com/parts/00345 would retrieve the contents of a specific part POST: Create a new resource with a unique URI By POSTing a valid XML document containing parts information to http://www.parts-depot.com/parts PUT: Update the contents of a specified resource DELETE: Delete the contents of a specified resource
GET http://www.parts-depot.com/parts/00345 returns the following XML: <p:part xmlns:p="http://www.parts-depot.com" xmlns:xlink="http://www.w3.org/1999/xlink"> <Part-ID>00345</Part-ID> <Name>Widget-A</Name> <Description>This part is used within the frap assembly</description> <Specification xlink:href="http://www.parts-depot.com/parts/00345/specification"/> <UnitCost currency="usd">0.10</unitcost> <Quantity>10</Quantity> </p:part> POST to http://www.parts-depot.com/parts with a similar XML creates a new part Do not have to specify Part-ID explicitly it is automatically generated New resource created at http://www.parts-depot.com/parts/xxxx
RESTEasy: http://jboss.org/resteasy/ JBoss project for building RESTful services Jersey: https://jersey.dev.java.net/ Open source Java-based implementation part of Sun s Glassfish project DIY in Python, Perl
REST works well if you have a set of resources/entities that need to be exposed as services Similar to the CRUD (Create, Read, Update, Delete) functions in relational databases Intuitive for exposing data(base) functionality as Web services Resources can be thought of as Nouns SOAP works well if you have a set of specific operations that need to be exposed Similar to remote procedure calls in distributed systems Intuitive for exposing actions or computational functionality as Web services Operations can be thought of as Verbs
Hopefully, we have a better idea of what Web services are What? How? Where? Next, we will see how Web services are applicable to the scientific community Finally, we will do a hands-on session deploying a scientific application as a Web service on a Cloud infrastructure
Service Discovery Layer Service Description Layer Service Messaging Layer Service Transport Layer
Abstract, typed definition of the data being sent <message name="echostructrequest"> <part name="inputstruct type="s:teststruct"/> </message> <message name="echostructresponse"> <part name="return" type="s:teststruct"/> </message>
Service Discovery Layer: WSIL, UDDI Service Description Layer: WSDL, RDF Service Messaging Layer: SOAP, REST Service Transport Layer: HTTP, SMTP
Define a Web service interface Use WSDL to define port types, messages, and data types Use a stub compiler to generate Java sources WSDL2Java generates client and server side bindings from the WSDL Also generates Web Services Deployment Descriptors (WSDD)
<definitions>.. <porttype name="testporttype"> <operation name="echostruct"> <input message="tns:echostructrequest"/> <output message="tns:echostructresponse"/> </operation> </porttype>.. <service name="testservice"> <port binding="tns:testsoapbinding name="echo"> <soap:address location="http://test.org:5049/serv/echo"/> </port> </service> </definitions> public class SoapStruct { } String varstring; int varint; public interface TestPortType { } public SoapStruct echostruct(soapstruct inputstruct);
Implement the service implementation (server-side) Deploy the service into a Container Jakarta Tomcat: http://tomcat.apache.org/ Hosting environment - provides desirable features such as reliability, scalability, security, etc Write custom clients based on the generated stubs Can also write clients in other languages, viz., Python, JavaScript, Perl, etc