Web Services Giuseppe Attardi Universit di Pisa Overview

Web Services Giuseppe Attardi Università di Pisa

Overview l From COMponents to. NET l Web Services Architecture l Demo l Reflection and Metadata l Rich Interactive Applications l REST Architecture

Software Components

COM Classes and Servers l l l COM class: body of source code that implements COM interfaces provides real functions in any supported programming language for each interface method it supports each COM class has a unique identifier (CLSID) client asks COM to create an object and return interface pointer client applications interact with COM objects through interface pointers

client not dependent on implementation details of COM l COM servers: – in-process server: DLL loaded into client process calls go directly to object created in the client's process – out-of-process server: separate executable, either on same machine as a client or on remote machine; calls go first to an in-process proxy which uses RPC; in the server, stub object receives each incoming call and dispatches to appropriate COM object l l Active. X control is in-process COM server object

Object Creation Server Client 1. Create an object 6. Invoke request directly Object COM 2. Find the server 3. Load DLL or launch EXE 4. Retrieve Class Factory 5. Ask Factory to create Class Factory

Interfaces, Classes and Factories Classes Interfaces Engine Class IUnknown Query. Interface() Add. Ref() Release() Implements IUnknown impl. Inherits from IEngine Impl. Engine Factory IEngine Start() Stop() Add. Fuel() Get. Type() Change. Speed() IEngine IUnknown IEngine_1 IUnknown Objects Engine_2

COM Interfaces l COM interface defines behavior or capabilities of software component as a set of methods and properties l interface is contract that guarantees consistent semantics l each COM object must support at least one interface (IUnknown)

COM pros/cons l PROs – Access to OS functionality – Faster and easier to write apps – Third-party COM components l CONs – Requires infrastructure and tools – Client/server kept separate (e. g. different strings implementations) – DLL hell

History of Distributed Object Models Communication Protocol Models: – Message passing/queueing (DCE) – Request/response (RPC) l 1980 l 1990 model based on network layer (NFS, DCE RPC) object-oriented RPC, to link objects

Remote Procedure Call CLIENT operation() reply SERVER Top layer client stub wire protocol Middle layer Bottom layer Network server stub wire protocol

ORPC codify mappings between objects at language level l Server-side middleware locate and instantiate object in target process l Microsoft DCOM and CORBA IIOP were dominating ORPC protocols l

CORBA l OMG’s specification for interoperability between distributed computing nodes l Goal: heterogeneous environments communicating at the object level, regardless of implementation of endpoints l ORB: middleware that establishes requestor-provider relationship

ORB l Receives invocation message to invoke specified method for registered object l Finds object, unmarshals parameters, invokes method, marshals and returns results l Requester needs not to be aware of location, language or OS of object

CORB Architecture

Interface Definition Language l Language neutral specification interface Polynomial : Math. Object { sequence<Monomial> monomials; int rank; Polynomial add(in Polynomial p); }; l l Mappings to several languages Tools (compilers) generate stubs and skeletons in various languages Note. No way to know at run-time which interfaces an object provides: IDL gets compiled away

DCOM l DCOM distributed extension to COM l builds an ORPC layer on top of DCE RPC l COM server can create object instances of multiple object classes l COM object supports multiple interfaces, representing different view or behavior of the object l interface consists of a set of functionally related methods

DCOM Interfaces l interfaces described using MIDL l MIDL compiler generates proxy and stub code in C or C++ from interface definition l generated proxy code provides client -side API l stub objects decode incoming client requests and deliver to appropriate object in the server

COM client interacts with COM object by acquiring a pointer to an object's interface and invoking methods through that pointer, as if the object resides in the client's address space l interfaces follow standard memory layout, same as C++ vtable l specification at binary level l integration of binary components in different languages (C++, Java, Visual Basic) l

DCOM Architecture

DCOM Overview l l l l proxy and stub code interact with appropriate runtime libraries to exchange requests and responses each interface has UUID Query. Interface method of IUnknown Query. Interface returns an interface pointer points to COM binary data structure client application must know CLSID and IID for an interface standard dictates interface functions calling conventions

CORBA / COM interoperability l Naming of communication endpoints: – CORBA: Interoperable Object Reference – DCOM: OBJREFs (include reference counting) l Support for multiple interfaces (only in DCOM) l Format of payload parameter values: – DCOM: Network Data Representation – CORBA: Common Data Representation

COM-CORBA Interoperation Machine 1 Active. X COM client OLE Automation OSA COM CORBA Machine 2 CORBA IIOP CORBA object Translate call COM OSA CORBA OSA The object bridge

CORBA and DCOM limitations l DCOM platform limitation l CORBA, subtle incompatibilities require ORB from same vendor l Reliance on closely administered environments – IIOP must cross firewalls l Programming difficulties in data alignment and data types

Quest for Net Objects 1993 1996 1997 1999 2000 COM Java Mary Kirtland’s articles in MS System Journal present first sketch (COM+) Sun vs Microsoft over Java licensing Java 1. 2 MS announces. NET, CLR, C#

Web Computing l Programming with distributed components on the Web: – Heterogeneous – Distributed – Multi-language

Beyond browsing l Access and act on information l More control, better decision-making and easier collaboration l Optimal support for different devices l Open to partners: each can build its portion of the application

Classes of Use l Web Services l Rich Internet Applications – Full interactive capabilities of desktop applications

Web Services

Web Service: Definitions l Component for Web Programming l Self-contained, self-describing, modular component that can be published, located, and invoked across the Web

Web Services: Properties l can be used either internally or exposed externally over the Internet l accessible through a standard interface l allows heterogeneous systems to work together as a single web of computation

Properties l Loosely coupled l Ubiquitous communication l Universal data format

Service-Oriented Architecture Pu d bli Bin sh Service Provider Service Broker Find Service User

Web Service Scenario l Provider builds and defines the service in WSDL l Provider registers the service in UDDI l User finds the service by searching UDDI registry l User application binds to the Web service and invokes its operations via SOAP

Web Service Architecture Service Provider Interactions: SOAP Service Broker d Bin AP SO Communication: HTTP Pu bli UD sh DI Data: XML UDDI/WSDL Find Service User

Web Services Protocols Find a Service http: //www. uddi. org Link to discovery document UDDI Discovery Web Service Consum er http: //yourservice. com HTML with link to WSDL How do we talk? (WSDL) http: //yourservice. com/? WSDL return service descriptions (XML) Let me talk to you (SOAP) http: //yourservice. com/svc 1 return service response (XML) Web Servi ce

Infrastructure Elements Directories central location to locate Web Services provided by other organizations (e. g. UDDI registry) Discovery locating WSDL for a particular Web Service Description defines what interactions the Web Service supports Wire Formats enable universal communication (e. g. SOAP)

SOAP Wire-protocol based on XML and HTTP that consists of: – an envelope for describing what is in a message and how to process it – a set of encoding rules for expressing instances of application-defined data types – a convention for representing remote procedure calls and responses

Sample SOAP request POST /Currency. Server/Currency. Exchange. asmx HTTP/1. 1 Host: theseus Content-Type: text/xml; charset=utf-8 Content-Length: length SOAPAction: http: //di. unipi. it/webservices/Euro <? xml version="1. 0" encoding="utf-8"? > <soap: Envelope xmlns: xsi=http: //www. w 3. org/2001/XMLSchema-instance xmlns: xsd=http: //www. w 3. org/2001/XMLSchema xmlns: soap=http: //schemas. xmlsoap. org/soap/envelope> <soap: Body> <Euro xmlns=http: //di. unipi. it/webservices> <currency>string</currency> </Euro> </soap: Body> </soap: Envelope>

Sample SOAP reply HTTP/1. 1 200 OK Content-Type: text/xml; charset=utf-8 Content-Length: length <? xml version="1. 0" encoding="utf-8"? > <soap: Envelope xmlns: xsi=http: //www. w 3. org/2001/XMLSchema-instance xmlns: xsd=http: //www. w 3. org/2001/XMLSchema xmlns: soap=http: //schemas. xmlsoap. org/soap/envelope> <soap: Body> <Euro. Response xmlns=http: //di. unipi. it/webservices> <Euro. Result>double</Euro. Result> </Euro. Response> </soap: Body> </soap: Envelope>

Other Wire-Protocols l HTTP GET l HTTP POST l SMTP l … customized

Web Service Description Language

WSDL Structure Types Message Port Type Operation Binding Service Port Data type definitions Signature of request and reply for each method (≈ IDL) <service, protocol> operations method messages Protocol and data-format specification { Port binding } Address (≈ URL)

WSDL example l Currency Exchange Service l Methods double Rate(String From, String To) double Euro(String Currency) l Service URL http: //theseus/Currency. Server/Currency. Exchange. asmx

WSDL example <message name="Rate. Soap. In"> <part name="parameters" element="s 0: Rate" /> </message> <message name="Rate. Soap. Out"> <part name="parameters" element="s 0: Rate. Response" /> </message> <message name="Euro. Soap. In"> <part name="parameters" element="s 0: Euro" /> </message> <message name="Euro. Soap. Out"> <part name="parameters" element="s 0: Euro. Response" /> </message> <message name="Rate. Http. Get. In"> <part name="from" type="s: string" /> <part name="to" type="s: string" /> </message> <message name="Rate. Http. Get. Out"> <part name="Body" element="s 0: double" /> </message> <message name="Euro. Http. Get. In"> <part name="currency" type="s: string" /> </message> <message name="Euro. Http. Get. Out"> <part name="Body" element="s 0: double" /> </message> <message name="Rate. Http. Post. In"> <part name="from" type="s: string" /> <part name="to" type="s: string" /> </message> <message name="Rate. Http. Post. Out"> <part name="Body" element="s 0: double" /> </message> <message name="Euro. Http. Post. In"> <part name="currency" type="s: string" /> </message> <message name="Euro. Http. Post. Out"> <part name="Body" element="s 0: double" /> </message> …

Building A Server l Simplicity – Source file (plain text = notepad accessible) – Compiled at run-time similar to ASP. NET pages – Just hit save – File extension is. asmx l File can be inline or in separate assembly

Building TRUST l CLR exposes its elements l Users can create elements directly l Even when using tools, you can look at their output and change it

Building A Server l <%@ Service. Host Service=“class“ Code. Behind="class. svc. cs" %> – Names the class and file with code l using System. Service. Model. Web; – Required namespace l [Operation. Contract] – Method is ‘web callable’ l Optional: Web. Service base class – Access ASP. NET intrinsics

See: https: //msdn. microsoft. com/enus/library/bb 386386(v=vs. 120). aspx

Creating Web Service Clients Grab WSDL from Web Service 2. Create proxy from WSDL 3. Execute methods against proxy, passing input parameters 1. § § Proxy calls Web Service on your behalf Web Service returns results to proxy Retrieve results from proxy 5. Display results 4.

ASP. NET Client Uses proxy and SOAP protocol to communicate with Web Service l Steps: l 1. Use wsdl utility to create local proxy 2. Compile proxy using vbc or csc l Place compiled proxy assembly in bin folder of Web 3. Create client l Import proxy namespace, code to proxy’s properties and methods

See: https: //msdn. microsoft. com/enus/library/bb 386386(v=vs. 120). aspx #Anchor_2

Using SOAP toolkit // allocate a new Soap. Client pointer m_p. Client = new ISOAPClient; // create the Soap. Client pointer m_p. Client->Create. Dispatch("MSSOAP. Soap. Client") // initialize it m_p. Client->mssoapinit("http: //www. My. Service. com/Calc. wsdl", "Calc. Port. Type", NULL); // perform addition double ISOAPClient: : Add(double dbl. A, double dbl. B, DISPID dispid) { double result; static BYTE parms[] = VTS_R 8; Invoke. Helper(dispid, DISPATCH_METHOD, VT_R 8, (void*)&result, parms, dbl. A, dbl. B); return result; }

Client Side? l Use HTTP GET – handle XML yourself l Use wsdl. exe, generate client-side program, invoke it through Jscript l Use Active. X or Java

Microsoft. NET l A software platform for XML Web Services

Commercial Offerings. NET http: //microsoft. com/net Web. Sphere http: //www. ibm. com/websphere J 2 EE http: //java. sun. com/j 2 ee

Role of CLR l Robustness – more and more programs run on server – avoid memory leaks l Simplifies programming – Avoid burden of reference counting l Reduce incompatibilities – Objects are remotely accessible – More easily reproduced if built on same basic elements

Reflection l Avoids IDL – Slight incompatibilities in CORBA l Avoids type libraries l Provides for dynamic invocation l Allows customization – e. g. serialization

Processing inside SOAP Client WSDL WSML WSDLReader load() WSDLOperation object Get. Operation. Parts() Add(3, 4) Num. 3 Num. 4 Serializer Num. 7 Sum Reader SOAP Connector SOAP request SOAP reply

Server-side SOAP WSDL SOAP request Soap. Reader load() WSML WSDLReader Parse. Request | load() WSDLOperation object Execute. Operation | Get. Operation. Parts() Num. 3 Num. 4 Add(3, 4) Num. 7 SOAP reply Serializer Sum

Reflection in Web Services l SOAP proxy performs: – Invoke(m, new object[] {arg 1, arg 2}); l SOAP message dispatcher: – parses request – creates parameter objects – determines object requested – instantiates object – gets requested method – invokes method with built parameters

Reflection: Apache SOAP l SOAP requests addressed to: server: 8080//soap/servlet/rpcrouter/method l Servlet performs: – Call c = extract. Call. From. Envelope(Service. Manager sm, Envelope e, SOAPContext ctx); – Response invoke(Deployment. Descriptor dd, Call c, Object o, SOAPContext req. Ctx, SOAPContext res. Ctx) { … m = Method. Utils. get. Method(o, call. get. Method. Name(), arg. Types); return new Bean(m. get. Return. Type(), m. invoke(o, args)); }

Meta Data l Reflection extracts metadata (no need for separate type library) l Attributes: turned into metadata stored within IL l Metadata accessible at runtime l New attributes can be defined, for program use

int (*fun)(int, char); fun f = some. Function; f(3, ’a’); some. Function(3, ’a’); apply(fun f, void* args) { f(args); switch (args. lentgh) { case 1: return f(args[0]); case 2: return f(args[0], args[1]); … }

Use of Reflection l Building a high performance search engine l Need way to store and retrieve objects from relational table l Need reflection to serialize objects l Solution before. NET: template metaprogramming

Deployment Scenario Customer performs title search DJInterpool Dead. Vinyl Service Broker Music Portal invokes search Web Service Funk. Factory Service Broker invokes search services Services respond with search results

Dynamic Objects (. NET) l Dynamic class creation l Dynamic class loading l Needed for interactive SQL interpreter

Rich Interactive Applications

Original Web Limitations l Thin but weak: – Not real-time – Not productive – Not interactive l Client cannot initiate actions l Browser pull: waste bandwidth l Java, Active. X: maintainability and security restrictions l AJAX

Current SOAPs l SOAP 1. 2 specifications l Implementations: – MS SOAP Toolkit 2. 0 – Apache Axis – SOAP: : Lite for Perl – pocket. SOAP – GSoap for C++

References Standards SOAP WSDL UDDI http: //www. w 3. org/TR/SOAP http: //www. w 3. org/TR/WSDL http: //www. uddi. org Papers 1. 2. Close up on. NET, DNJ, http: //www. dnjonline. com/articles/essentials/iss 24_essentials. html M. Kirtland, Object-Oriented Software Development Made Simple with COM+ Runtime Services, MSDJ, http: //www. microsoft. com/msj/defaultframe. asp? page=/msj/1197/complus. htm&na v=/msj/1197/newnav. htm

REST Architecture

REST l REpresentational State Transfer l An architectural style, not a toolkit l A distillation of the way the Web already works

Representation l Resources are first-class objects – Indeed, “object” is a subtype of “resource” l Resources are retrieved not as character strings or BLOBs but as complete representations

A web page is a resource? l A web page is a representation of a resource l Resources are just concepts l URIs tell a client that there's a concept somewhere l Clients can then request a specific representation of the concept from the representations the server makes available

State l “State” means application/session state l Maintained as part of the content transferred from client to server back to client l Thus any server can potentially continue transaction from the point where it was left off l State is never left in limbo

Principles Client-server l Stateless l – No client context is stored on the server between requests – The server can be stateful l Cacheable – Clients can cache responses l Layered system – Clients cannot tell whether it’s connected directly to the end server, or an intermediary l Code on demand (optional) – Servers are able to temporarily extend the functionality of a client l Uniform interface

Guiding Principles of the Interface l Identification of resources – E. g. URIs l Manipulation of resources through these representations l Self-descriptive messages l Hypermedia as the engine of application state – E. g. hyperlinks, hypertext

Key Goals l Scalability of component interactions l Generality of interfaces l Independent deployment of components l Intermediary components to reduce latency, enforce security, and encapsulate legacy systems

RESTful Web API l Four aspects 1. Base URI for the Web service 2. Internet media type of the data supported by the Web service • e. g. JSON, XML, or YAML 3. The set of operations supported by the Web service using HTTP methods • e. g. GET, PUT, POST, or DELETE 4. The API must be hypertext driven

l No official standard for RESTful services – But Web standard protocols are often used

RESTful Web services: Basics l Use HTTP methods explicitly l Be stateless l Expose directory structure-like URIs l Transfer XML, JSON, or both

Using HTTP Methods Explicitly l One-to-one mapping – – l GET: to retrieve a resource on the server POST: to create a resource PUT: to change the state of a resource or to update it DELETE: to remove a resource For example: – Before • GET /adduser? name=Robert HTTP/1. 1 – After • POST /users HTTP/1. 1 Host: myserver Content-Type: application/xml <? xml version="1. 0"? > <user> <name>Robert</name> </user>

l Another example – Before • GET /updateuser? name=Robert&newname=Bob HTTP/1. 1 – After • PUT /users/Robert HTTP/1. 1 Host: myserver Content-Type: application/xml <? xml version="1. 0"? > <user> <name>Bob</name> </user>

Be Stateless l For scalability, clients are required to send complete, independent requests – include all data needed to be fulfilled so that the components in the intermediary servers may forward, route, and loadbalance without any state being held locally in between requests

Expose directory structure-like URIs l Ex. – http: //www. myservice. org/discussion/topics/{topic} – http: //www. myservice. org/discussion/2008/12/10/{t opic} l Guidelines – Hide the server-side scripting technology file extensions (. jsp, . php, . asp), if any, so you can port to something else without changing the URIs – Keep everything lowercase – Substitute spaces with hyphens or underscores (one or the other) – Avoid query strings as much as you can – Instead of using the 404 Not Found code if the request URI is for a partial path, always provide a default page or resource as a response.

Transfer XML, JSON, or both l Example l Common MIME types – <? xml version="1. 0"? > <discussion date="{date}" topic="{topic}"> <comment>{comment}</comment> <replies> <reply from="joe@mail. com" href="/discussion/topics/{topic}/joe"/> <reply from="bob@mail. com" href="/discussion/topics/{topic}/bob"/> </replies> </discussion> – JSON: application/json – XML: application/xml – XHTML: application/xhtml+xml

References l http: //en. wikipedia. org/wiki/Web_serv ice l RESTful Web services: the basics, by Alex Rodriguez, IBM developer. Works, available at: http: //www. ibm. com/developerworks/ webservices/library/ws-restful/.

Conclusions l Web Services allow exploiting the Web as a platform l Two styles: – SOAP based: XML Web Services – REST based: RESTful l Issues: – no more DLL Hell – but maybe, Namespace Hell