1. Giuseppe Attardi Università di Pisa
Web Services
Giuseppe Attardi
Università di Pisa

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

3. Software Components

4. COM Classes and Servers
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

5. client not dependent on implementation details of COM
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
ActiveX control is in-process COM server object

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

7. Interfaces, Classes and Factories
IUnknown
Engine Class
QueryInterface()
AddRef()
Release()
Implements
IUnknown
impl.
Inherits
from
IEngine
Impl.
IEngine
Engine
Factory
Start()
Stop()
AddFuel()
GetType()
ChangeSpeed()
IEngine
IEngine
IUnknown
Engine_1
IUnknown
Engine_2
Objects

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

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

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

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

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

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

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

15. CORB Architecture

16. Interface Definition Language
Language neutral specification
interface Polynomial : MathObject {
sequence<Monomial> monomials;
int rank;
Polynomial add(in Polynomial p); };
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

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

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

19. 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
interfaces follow standard memory layout, same as C++ vtable
specification at binary level
integration of binary components in different languages (C++, Java, Visual Basic)

20. DCOM Architecture

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

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

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

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

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

26. Web Computing Programming with distributed components on the Web:
Heterogeneous
Distributed
Multi-language

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

28. Classes of Use Web Services Rich Internet Applications
Full interactive capabilities of desktop applications

29. Web Services

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

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

32. Properties Loosely coupled Ubiquitous communication
Universal data format

33. Service-Oriented Architecture
Provider
Publish
Bind
Service
Broker
Service
User
Find

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

35. Web Service Architecture
Provider
Interactions: SOAP
Data: XML
Communication: HTTP
Publish
UDDI
Bind
SOAP
Service
Broker
Service
User
UDDI/WSDL
Find

36. Web Services Protocols
Consumer
Find a Service
UDDI
Link to discovery document
Discovery
Web
Service
HTML with link to WSDL
How do we talk? (WSDL)
return service descriptions (XML)
Let me talk to you (SOAP)
return service response (XML)

37. 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)

38. 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

39. Sample SOAP request
POST /CurrencyServer/CurrencyExchange.asmx HTTP/1.1 Host: theseus Content-Type: text/xml; charset=utf-8 Content-Length: length SOAPAction: <?xml version="1.0" encoding="utf-8"?> <soap:Envelope xmlns:xsi= xmlns:xsd= xmlns:soap= <soap:Body> <Euro xmlns= <currency>string</currency> </Euro> </soap:Body> </soap:Envelope>

40. Sample SOAP reply
HTTP/ OK Content-Type: text/xml; charset=utf-8 Content-Length: length <?xml version="1.0" encoding="utf-8"?> <soap:Envelope xmlns:xsi= xmlns:xsd= xmlns:soap= <soap:Body> <EuroResponse xmlns= <EuroResult>double</EuroResult> </EuroResponse> </soap:Body> </soap:Envelope>

41. Other Wire-Protocols
HTTP GET
HTTP POST
SMTP
… customized

42. Web Service Description Language

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

44. WSDL example Currency Exchange Service Methods Service URL
double Rate(String From, String To)
double Euro(String Currency)
Service URL

45. WSDL example
<message name="RateSoapIn"> <part name="parameters" element="s0:Rate" /> </message> <message name="RateSoapOut"> <part name="parameters" element="s0:RateResponse" /> <message name="EuroSoapIn"> <part name="parameters" element="s0:Euro" /> </message> <message name="EuroSoapOut"> <part name="parameters" element="s0:EuroResponse" /> <message name="RateHttpGetIn"> <part name="from" type="s:string" /> <part name="to" type="s:string" /> <message name="RateHttpGetOut"> <part name="Body" element="s0:double" /> <message name="EuroHttpGetIn"> <part name="currency" type="s:string" /> <message name="EuroHttpGetOut">
<message name="RateHttpPostIn"> <part name="from" type="s:string" /> <part name="to" type="s:string" /> </message> <message name="RateHttpPostOut"> <part name="Body" element="s0:double" /> <message name="EuroHttpPostIn"> <part name="currency" type="s:string" /> <message name="EuroHttpPostOut"> <part name="Body" element="s0:double" /> …

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

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

48. Building A Server using System.ServiceModel.Web; [OperationContract]
ServiceHost Service=“class“ CodeBehind="class.svc.cs" %>
Names the class and file with code
using System.ServiceModel.Web;
Required namespace
[OperationContract]
Method is ‘web callable’
Optional: WebService base class
Access ASP.NET intrinsics

49. See: https://msdn.microsoft.com/en-us/library/bb386386(v=vs.120).aspx

50. Creating Web Service Clients
Grab WSDL from Web Service
Create proxy from WSDL
Execute methods against proxy, passing input parameters
Proxy calls Web Service on your behalf
Web Service returns results to proxy
Retrieve results from proxy
Display results

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

52. See:

53. Using SOAP toolkit
// allocate a new SoapClient pointer m_pClient = new ISOAPClient; // create the SoapClient pointer m_pClient->CreateDispatch("MSSOAP.SoapClient") // initialize it m_pClient->mssoapinit(" "Calc", "CalcPortType", NULL); // perform addition double ISOAPClient::Add(double dblA, double dblB, DISPID dispid) { double result; static BYTE parms[] = VTS_R8 VTS_R8; InvokeHelper(dispid, DISPATCH_METHOD, VT_R8, (void*)&result, parms, dblA, dblB); return result; }

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

55. Microsoft .NET
A software platform for XML Web Services

56. Commercial Offerings
.NET WebSphere J2EE

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

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

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

60. ExecuteOperation | GetOperationParts()
Server-side SOAP
WSDL
WSML
SoapReader
load()
SOAP request
WSDLReader
ParseRequest | load()
WSDLOperation object
ExecuteOperation | GetOperationParts()
Num. 3
Num. 4
Add(3, 4)
Num. 7
SOAP reply
Serializer
Sum

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

62. Reflection: Apache SOAP
SOAP requests addressed to:
server:8080//soap/servlet/rpcrouter/method
Servlet performs:
Call c = extractCallFromEnvelope(ServiceManager sm, Envelope e, SOAPContext ctx);
Response invoke(DeploymentDescriptor dd, Call c, Object o, SOAPContext reqCtx, SOAPContext resCtx) { …
m = MethodUtils.getMethod(o, call.getMethodName(), argTypes);
return new Bean(m.getReturnType(), m.invoke(o, args)); }

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

64. int (*fun)(int, char); fun f = someFunction; f(3,’a’); someFunction(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]); … }

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

66. Deployment Scenario Service Broker Customer performs title search
DJInterpool
Customer
performs title search
DeadVinyl
Music Portal
Service Broker
FunkFactory
Services respond with search results
Portal invokes
search
Web Service
Service Broker invokes search services

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

68. Rich Interactive Applications

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

70. Current SOAPs SOAP 1.2 specifications Implementations:
MS SOAP Toolkit 2.0
Apache Axis
SOAP::Lite for Perl
pocketSOAP
GSoap for C++

71. References Standards SOAP http://www.w3.org/TR/SOAP
WSDL
UDDI
Papers
Close up on .NET, DNJ,
M. Kirtland, Object-Oriented Software Development Made Simple with COM+ Runtime Services, MSDJ,

72. REST Architecture

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

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

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

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

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

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

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

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

81. No official standard for RESTful services
But Web standard protocols are often used

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

83. Using HTTP Methods Explicitly
One-to-one mapping
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>

84. Another example Before After
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>

85. Be Stateless
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 load-balance without any state being held locally in between requests

87. Expose directory structure-like URIs
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.

88. Transfer XML, JSON, or both
Example
<?xml version="1.0"?>
<discussion date="{date}" topic="{topic}">
<comment>{comment}</comment>
<replies>
<reply href="/discussion/topics/{topic}/joe"/>
<reply
href="/discussion/topics/{topic}/bob"/>
</replies>
</discussion>
Common MIME types
JSON: application/json
XML: application/xml
XHTML: application/xhtml+xml

89. References http://en.wikipedia.org/wiki/Web_service
RESTful Web services: the basics, by Alex Rodriguez, IBM developerWorks, available at:

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