1

XML for Java Developers G22.3033-002

Session 4 – Sub-Topic 3Towards P2P Computing

Dr. Jean-Claude Franchitti

New York UniversityComputer Science Department

Courant Institute of Mathematical Sciences

Soap and Web Services

Part I

2

Evolution of integration methods

Custom static integration

App. Integration Standards

Web Protocol Standards(HTTP, HTML, XML, RosettaNet,

OBI, cXML, …)

Web App. Standards

(Web Services)

-1990

Early 1990s

Late 1990s

2001

Web Services• Machine-to-machine communication

– Description of service semantics & metadata • WSDL: Web Service Definition Language

– Discovery of appropriate services • UDDI: Universal Description, Discovery & Integration service

• Allow services to be defined, deployed, manipulated & evolved in an automated fashion

• Basis for expressing higher-level business logic – Using flow languages

• Potential :– EDI replacement– ERP accelerator– Reduce middleware proliferation– Improve desktop integration

3

“Drivers” for Web Services• Microsoft

– .NET, Hailstorm • Sun

– Sun ONE • HP

– e-speak • IBM

– Dynamic e-business • UN/CEFACT & OASIS

– ebXML• Plus: Oracle, Borland,

…

Submitted to IETF - Nov. 1999

W3C WG- September 2000

RPC Interoperability problems• Naming of communication endpoints

– CORBA: IORs– DCOM: OBJREFs

• Support for multiple interfaces per object– CORBA: implicitly, there is 1 interface in an IOR– DCOM: multiple interfaces + Iunknown

• Format of parameter values– CORBA: CDR– DCOM: Network Data Representation

4

IIOP vs. DCOM (I)

IIOP vs. DCOM (II)

5

URIs, URLs, URNs• Universal Resource Identifier:

– A formatted string that uniquely identifies a resource• Uniform Resource Locator:

– encode the underlying protocol needed to locate the resource, as well as its location

– “http://" <host> [":" <port>] [<path> ["?" <qry>]• Uniform Resource Name:

– location-independent & in no way imply any protocol or mechanism for locating the resource being identified

– "urn:" <NID> ":" <NSS>• <NID>: namespace• <NSS>: namespace-specific string• urn:uuid:00000000-0000-0000-C000-000000000046

Simple Object Access Protocol

• A light-weight XML messaging convention– exchange of structured & typed information

• no application or transport semantics • “XML datagrams” -> extensibility

• Common use: RPC-over-HTTP (using XML)– getStockQuote(), issueQuery(), sendOrder()

• Other uses are possible:– One-way messaging– Multicast

• The KISS* principle– absolute minimum of functionality * Keep It Simple, Stupid!

6

SOAP “reference”

UDDI (I)• Universal Description, Discovery & Integration

– An industry initiative for B2B interoperability• First spec’s outlined by Ariba, Microsoft & IBM • Ariba, Microsoft, IBM, HP, SAP: “operator nodes”

– Business Registry of Web services• Allow companies to register their business & services• Accessible via SOAP

– … and via browser– < businessEntity, businessService, bindingTemplate, tModel >

• Web service:– a self-describing, self-contained, modular unit of application logic

• provides some business functionality to other app’s – Web services can be mixed & matched with other web services to

execute a larger workflow or business Tx.• WSDL: Web Service Definition Language

7

UDDI (II)• XML Schema for UDDI:

– <businessEntity>: Business information– <businessService>: Service information– <bindingTemplate>: Binding information– <tModel>: Information on specifications

• “technical fingerprint”: list of references

• Inquiry API• Publisher API• Coping with Failures ?

– inability to predict, detect, or recover from failures within the systems of the remote partner

– Use cached <bindingTemplate>, “retry-on-failure”• Rely on partner to update registry entry

UDDI (III)Discrete business roles

Applications will increasingly be based on compositions of services discovered & marshaled dynamically at runtime.

Lifecycle:•Build•Deploy•Run•Manage

The business of e-business services (IBM)

PublishWSDL

FindUDDI

BindSOAP

8

UDDI Sample Interaction (I)<?xml version='1.0' encoding='UTF-8'?><Envelope xmlns='http://schemas.xmlsoap.org/soap/envelope/'><Body><find_business generic="1.0" xmlns="urn:uddi-org:api">

<name>Microsoft</name></find_business></Body></Envelope>

UDDI Sample Interaction (II)<businessList generic="1.0" operator="Microsoft Corporation"

truncated="false" xmlns="urn:uddi-org:api"><businessInfos>

<businessInfo businessKey="0076B468-EB27-42E5-AC09-9955CFF462A3"><name>Microsoft Corporation</name>

<description xml:lang="en">Empowering people through great software -any time, any place and on any device … </description><serviceInfos>

<serviceInfo businessKey="0076B468-EB27-42E5-AC09-955CFF462A3"serviceKey="8BF2F51F-8ED4-43FE-B665-38D8205D1333">

<name>Electronic Business Integration Services</name></serviceInfo>……………………………………………………………………………………………………….<serviceInfo businessKey="0076B468-EB27-42E5-AC09-955CFF462A3"

serviceKey="D2BC296A-723B-4C45-9ED4-494F9E53F1D1"><name>UDDI Web Services</name>

</serviceInfo>……………………………………………………………………………………………………….

</serviceInfos></businessInfo> </businessInfos> </businessList>

9

UDDI Sample Interaction (III)<find_service generic='1.0' xmlns='urn:uddi-org:api'

businessKey='0076B468-EB27-42E5-AC09-9955CFF462A3'><name>UDDI Web Services</name>

</find_service>

<serviceList generic="1.0" operator="Microsoft Corporation"truncated="false" xmlns="urn:uddi-org:api">

<serviceInfos><serviceInfo businessKey="0076B468-EB27-42E5-AC09-9955CFF462A3"

serviceKey="D2BC296A-723B-4C45-9ED4-494F9E53F1D1"><name>UDDI Web Services</name>

</serviceInfo></serviceInfos>

</serviceList>

UDDI Sample Interaction (IV)<get_serviceDetail generic='1.0' xmlns='urn:uddi-org:api'>

<serviceKey>D2BC296A-723B-4C45-9ED4-494F9E53F1D1</serviceKey></get_serviceDetail>

<serviceList generic="1.0" operator="Microsoft Corporation"truncated="false" xmlns="urn:uddi-org:api">

<serviceInfos><serviceInfo businessKey="0076B468-EB27-42E5-AC09-9955CFF462A3"

serviceKey="D2BC296A-723B-4C45-9ED4-494F9E53F1D1"><name>UDDI Web Services</name>

</serviceInfo></serviceInfos>

</serviceList>

<find_business generic='1.0' xmlns='urn:uddi-org:api'><tModelBag><tModelKey>uuid:4CD7E4BC-648B-426D-9936-

443EAAC8AE23</tModelKey></tModelBag></find_business>

10

UDDI Sample Interaction (V)<serviceDetail generic="1.0" operator="Microsoft Corporation"

truncated="false" xmlns="urn:uddi-org:api"><businessService businessKey="0076B468-EB27-42E5-AC09-9955CFF462A3"

serviceKey="D2BC296A-723B-4C45-9ED4-494F9E53F1D1"><name>UDDI Web Services</name>

<description xml:lang="en">UDDI SOAP/XML message-based programmatic webservice interfaces.</description><bindingTemplates><bindingTemplate bindingKey="A9CAFBE4-11C6-4BFE-90F5-595970D3DE24"

serviceKey="D2BC296A-723B-4C45-9ED4-494F9E53F1D1"><description xml:lang="en">Production UDDI server, Inquiry interface

</description><accessPoint URLType="http">http://uddi.microsoft.com/inquire</accessPoint><tModelInstanceDetails>

<tModelInstanceInfo tModelKey="uuid:4CD7E4BC-648B-426D-9936443EAAC8AE23">

<description xml:lang="en">UDDI SOAP Inquiry Interface</description></tModelInstanceInfo></tModelInstanceDetails>

</bindingTemplate>…………………………………………………………………………………………………………….

SOAP Mandatory Features• Transport Binding

– how to get the message to its destination • isolates message from transport, for portability across transports

• Message Envelope – what features & services are represented in a message

• as blocks

– who should deal with them • actor attribute + implied semantics

– whether they are optional or mandatory • mustUnderstand attribute + implied semantics

11

SOAP Fault Codes100 Version Mismatch

- The call was using an unsupported SOAP version.200 Must Understand

- An XML element was received that contained an element tagged with mustUnderstand="true"that was not understood by the receiver.

300 Invalid Request- The receiving application did not process the request

because it was incorrectly formed or not supported by the application.

400 Application Faulted- The receiving application faulted when processing the

request. The detail element contains the application-specific fault.

SOAP Optional Features• Serialization Mechanism

– to exchange instances of application-defined data types and directed graphs

– uniform model for serializing abstract data models that cannot be expressed in XML Schema

– “Section 5 encoding”: representation of programming language types

• RPC Convention – how to make calls & responses for a particular type of

service

Open issue: Security of XML documents ?

12

SOAP ExamplePOST /Accounts/Henrik HTTP/1.1

Host: www.webservicebank.comContent-Length: nnnnContent-Type: text/xml; charset="utf-8"SOAPAction: "Some-URI"

<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/"SOAP:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><SOAP:Header>

<t:Transaction xmlns:t="some-URI"SOAP:mustUnderstand="1"></t:Transaction>

</SOAP:Header><SOAP:Body>

<m:Deposit xmlns:m="Some-URI"><m:amount>200</m:amount>

</m:Deposit></SOAP:Body>

</SOAP:Envelope>

Alternative SOAP Stacks•Based on HTTP•Based on SMTP•Based on SIP (on top of UDP)

•Support for extension modules- encryption- digital signatures- explicit routing (SOAP-RP)- caching

•Modules can address any SOAP processor using the "actor" attribute •Can be optional or mandatory using the "mustUnderstand" attribute

13

SOAP Message Paths & Routing• SOAP is built on underlying transports, which have

their own concepts of: – Message Exchange Pattern

• HTTP: request/response• SMTP: one-way

– Message Routing • HTTP: proxies • DNS: lookup • SMTP: DNS MX record, intermediary configuration

• Some applications using SOAP may need to determine their own concepts of MEP & routing – Message path & routing has an implied relationship with

the processing model• intra-node processing & inter-node processing are linked.

SOAP References• SOAP 1.1 specification

– http://www.w3.org/TR/SOAP• W3C XML Protocol Activity

– http://www.w3.org/2000/xp/ • SOAP/WebServices Resource Center

– http://www.soap-wrc.com/webservices/ • http://www.webservices.org/ • http://www.soaprpc.com/ • Public SOAP Services listing

– http://www.xmethods.com/ • http://msdn.microsoft.com/msdnmag/issues/0300/

soap/print.asp

14

Jini and JXTA

Part II

Distributed programming• Distributed computing is

more difficult than local computing because of:– Network latency– Concurrency issues– Memory (state) management– Inevitable partial failure

“Remote” increasingly looks like “local”

15

Jini• A set of interfaces & protocols• Spontaneous networking

– Federations of software services and/or devices• H/W & S/W entities are represented by Java objects

– Located & accessed via Java interfaces

– Self-healing networks• Vision:

– Make the installation & use of devices & app. software as simple as plugging in a phone

• “Java tone”

Jini & Java• Java VM

– homogeneous network• Portable object code

– architecture independence

• Downloadable code – dynamic environment

• Unified type system

Key component: Lookup Service-repository of service proxies-Clients download services on-demand

16

Using the Lookup service

Discovery & Join protocols- based on UDP multicast

Clients inquire by service type

Discovery & Join• Traditional Technology:

– Device is added to computer

– Device definition isedited in nodeconfiguration table

– Computer is restarted– Updated configuration

table is pushed tonetwork device map

• Jini Technology:– Device is plugged in &

powered up– Lookup service receives

multicast– Lookup service

authenticates source– Lookup service sends

advertisement– Device joins Lookup

service

17

Finding & using a service

Communication is bet. the service & its proxy:-Independent of wire protocol-Protocol can change withoutaffecting client- RMI semantics

Distributed leasing (I)• Protocol for managing resources using a renewable,

duration-based model– Contract between objects (grantor & holder)– Resources can be shared or private– Provides a method of managing resources in an

environment where partial failures occur• Time-based grants of resources or services

– Negotiated for a set period of time– Can be shared or exclusive

• Leases may be:– Cancelled (explicit cleanup)– Renewed (explicit extension)– Allowed to expire (implicit cleanup)– Obtained & manipulated by 3rd parties

18

Distributed leasing (II)• Resources are allocated only as long as

continued interest is shown– The lease holder is responsible to renew lease

before expiry• The network is self-healing

Distributed Events• Extend Java event model to work in a

distributed network– Register interest, receive notification

• Allow for use of event managers• Support various delivery models

– Push, pull, filter• Use the Distributed Leasing protocol

19

Distributed transactions• Designed for distributed object coordination

– Light weight, object-oriented– Supports two-phase commit– Uses Distributed Leasing protocol– Implemented in Transaction Manager service

Jini & JavaSpaces

20

Architecture layers

Communication Events

21

Processes (I)

• A JavaSpace can be replicated on all machines. The dotted lines show the partitioning of the JavaSpace into subspaces.

a) Tuples are broadcast on WRITEb) READs are local, but the removing of an instance when calling

TAKE must be broadcast

Processes (II)

• Unreplicated JavaSpace.a) A WRITE is done locally.b) A READ or TAKE requires the template tuple to be

broadcast in order to find a tuple instance

22

Processes (III)

• Partial broadcasting of tuples & template tuples.

The Jini Lookup Service (I)

A set of tuples describing the service.AttributeSets

A (possibly remote) reference to the object implementing the service.Service

The identifier of the service associated with this item.ServiceID

DescriptionField

23

The Jini Lookup Service (II)

• Examples of predefined tuples for service items.

Street, organization, organizational unit, locality, state or province, postal code, countryAddress

Floor, room, buildingLocation

Name, manufacturer, vendor, version, model, serial numberServiceInfo

AttributesTuple Type

Synchronization of Transactions

24

PAM

Evolution of network computing

C/S model is increasingly seen as a limiting factor !

25

Motivation for peer-to-peer (p2p)• Vast underutilization of Internet assets:

– Information• World “data” production: 2x1018 bytes/year

– Published: 3x1012 bytes– Transient data cannot be captured by Web crawlers– Google: 1.3x108 pages

– Bandwidth• x 106 increase since 1975

– ~x2 every 16 months• Yet hot spots remain !

– Computing resources• Concentrated in data centers

– Crippling rate of increase of workloads– Hard to keep up with demand !

JXTA software architecture

Platform- & transport-independent protocols

26

JXTA concepts (I)• UUID: 128-bit internal identifier per entity

– Must be explicitly bound to external name to form a security principal

• The authenticity of the binding can be ensured by including digital signatures

• Advertisement:– XML document that names & describes the existence of a

“resource”• Peer, peer group, pipe, services (“codats”)

• Messages:– Datagram-like, assuming unreliable, asynchronous, uni-

directional transport• Envelope: header, msg digest, source end-point (optional),

destination end-point • Stack of protocol headers & bodies

– Variable number of bytes + security credentials

JXTA concepts (II)• Peers:

– any entity that can interact with (a subset of) the JXTA protocols

• End-point: – a URI identifying a logical “destination” on a transport that

supports datagram-like messaging• Peer group:

– a collection of co-operating peers • Eg: in the context of a service

– World Peer Group• Pipes:

– Asynchronous, uni-directional comm. Channels– A pipe’s end-point can be bound to one or more peer end-

points• Usually dynamically, at run-time

27

JXTA protocols• Peer discovery

– Find advertisements• Peer resolver

– Search for peers, peer groups, pipes, …• Peer information

– Inquire a peer’s capabilities & status• Peer membership

– Obtain group membership requirements• Spec’s of credentials, authenticator, …

– Apply for/update/cancel membership• Pipe binding

– Bind an advertisement to a pipe end-point• End-point routing

– Ask a peer router for available routes for a destination– Peers may not be directly connected

• Different transports, Firewalls, NATs

JXTA Shell (I)• Command-line access to the JXTA platform

– Publish, search & execute “codats”– Discover peers & groups– Create pipes to connect peers– Send/receive messages

• Stdin := default input pipe• Stdout := default output pipe• Pipes can be dynamically disconnected &

reconnected:– cat myfile | grep jxta

• cat myfile >p1 ; grep <p1 jxta

– grep <p1 unix

28

JXTA Shell (II)• cat:

– Display advertisement, message, structured document (as read using importfile)

• mkpipe –i|o <pipe-adv>• mkmsg• send <outPipe> <msg>• recv [-t <timeout>] <inPipe>• Codats can be imported into codat containers:

– share <URI>• Currently, only local file:// URIs are supported• Symbolic name + size + MIME type + encoding

• ls: – listing of codats currently cached by the local peer

• For the current peer group

JXTA Shell (III)• whoami [-g]

– Display the local peer’s or current peer group’s advertisement

• mkadv• mkgrp• chgrp• join• leave• peers –r

– Propagate peer inquiry– Results are cached locally

• peers– Display currently known peers

• peerinfo <id>• groups

29

References• Jini Network Technology Web site

– http://www.sun.com/jini/• Jiniology articles

– http://www.artima.com/jini/jiniology/• JXTA project Web site

– http://www.jxta.org/