XML for Java Developers G

(1)

XML for Java Developers

G22.3033-002

Session 4 – Sub-Topic 3

Towards P2P Computing

Dr. Jean-Claude Franchitti

New York University

Computer Science Department

Courant Institute of Mathematical Sciences

Soap and Web Services

(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

(4)

IIOP vs. DCOM (I)

(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

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

(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)

Publish

WSDL

Find

UDDI

Bind

SOAP

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

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

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

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

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

(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 web service interfaces.</description>

<description xml:lang="en">Production UDDI server, Inquiry interface </description>

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

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

100 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

(12)

SOAP Example

POST /Accounts/Henrik HTTP/1.1

Host: www.webservicebank.com Content-Length: nnnn

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

(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

(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 is

edited in node

configuration table

– Computer is restarted

– Updated configuration

table is pushed to

network device map

• Jini Technology:

– Device is plugged in &

powered up

– Lookup service receives

multicast

– Lookup service

authenticates source

– Lookup service sends

– Device joins Lookup

(17)

Finding & using a service

Communication is bet. the service

& its proxy:

-Independent of wire protocol

-Protocol can change without

affecting 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

(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

(20)

Architecture layers

(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 WRITE

b)

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

Description Field

(23)

The Jini Lookup Service (II)

• Examples of predefined tuples for service items.

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

Address

Floor, room, building Location

Name, manufacturer, vendor, version, model, serial number ServiceInfo

Attributes Tuple Type

(24)

PAM

Evolution of network computing

(25)

Motivation for peer-to-peer (p2p)

• Vast underutilization of Internet assets:

– Information

• World “data” production: 2x10

18

_bytes/year

– Published: 3x1012 _bytes

– Transient data cannot be captured by Web crawlers – Google: 1.3x108_pages

– Bandwidth

• x 10

6

_{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

(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 point can be bound to one or more peer

end-points

(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

• mkadv

• mkgrp

• chgrp

• join

• leave

• peers –r

– Propagate peer inquiry

– Results are cached locally

• peers

– Display currently known peers

• peerinfo <id>

(29)

References

• Jini Network Technology Web site

– http://www.sun.com/jini/

• Jiniology articles

– http://www.artima.com/jini/jiniology/

• JXTA project Web site