Publishing and transporting Web Services over XMPP

Johannes Wagener

Web Services – State of the Art

(from Wikipedia)

WSDL:Web Services Description Language

SOAP:Simple Object Access Protocol

UDDI:Universal Description,Discovery and Integration

http is a pull protocol!

Client ServerdoBLAST()

Client(waiting)

Server(working)

doBLAST()

Client(waiting)

Server(working)

doBLAST()

Firewall http timeout

Workaround

Client ServerdoBLAST()

Client(loop)

Server(working)

checkResult(ID)

ClientServer

(finished)

checkResult(ID)

RESULT

“please wait”

(…)

ID

Next generation of Web Services

should ...• be a properly and strictly defined standard• allow stateful job management• allow asynchronous client notification• be discoverable• have big user community with a lot of software

About XMPP

• The Extended Messaging and Presence Protocol

• Formerly known as Jabber

• Invented by Jeremie Miller in 1998

• Formalized by the Internet Engineering Task Force since 2004

• RFC 3920 – 3923, 4622

• XMPP Standards Foundation continues to define various XMPP Extensions

• “…a protocol for streaming XML elements in order to exchange structured information in close to real time between any two network endpoints.

While XMPP provides a generalized, extensible framework for exchanging XML data, it is used mainly for the purpose of building instant messaging and presence applications.” (from RFC 3920)

(from Wikipedia)

XMPP Architecturesimilar to Email …

user@server1.com

server2.org

server1.com

server3.net

user@server2.org

user@server3.net

XMPP Architectureone user can connect with different resources

server2.org

server1.com

server3.net

user@server2.org/workuser@server2.org/home

User ID Server Resource

XMPP ArchitectureServer Components

server3.net

user@server3.netservice.server3.net

XMPP ArchitectureUse cases of Server Components

server3.net

user@server3.netuserdirectory.server3.net

msn.server3.netconference.server3.net

XMPP Architecturepresent

jabber.org

XMPP Architecturepresent

jabber.org

googlemail.com

XMPP Architecturepresent

jabber.org

googlemail.comgmx.net

… but many unofficial servers, too.

Clients

Servers

ServersClusterable

Libraries

• 3 x .NET• 3 x C• 2 x C#• 7 x C++• 3 x COM• 2 x Delphi• 1 x Flash• 9 x Java• 1 x Java Script

• 1 x Lisp• 1 x Mono• 5 x Perl• 2 x PHP• 4 x Python• 2 x Ruby• 1 x TCL• 1 x XPCom

The Protocol

• An inbound and outbound “XML Stream”

• Client connections are usually done with TCP. However there are no restrictions; i.e. many server allow polling over HTTP

• Streams may be encrypted in various formats

• Packets are sent as “stanzas”

• There are three top level stanzas:

<message/> … to submit messages

<presence/> … to submit presence information

<iq/> … for everything else – and that’s a lot

Simplified Stream Example...with two <message/> stanzas

(from RFC 3920)

C: <iq from='juliet@example.com/balcony' to='server.org' type='get' id='request_1'> <query xmlns='jabber:iq:version'/> </iq>

S: <iq type='result' from='server.org' to='juliet@example.com/balcony' id='request_1'> <query xmlns='jabber:iq:version'> <name>ejabberd</name> <version>1.1.2</version> <os>win32/nt5.1.2600</os> </query> </iq>

Information Query: <iq/>

XMPP Extensions Protocol (XEPs)

(…)

http://www.xmpp.org/extensions

(Web) Service Discovery

There are three kinds of information that needto be discovered about an entity

• its basic identity (type and/or category)• the features it offers and protocols it supports • any additional items associated with the entity,

whether or not they are addressable as JIDs

Web Service related XEPs

} Asynchronous +Stateful -Discoverable -

Asynchronous +Stateful +Discoverable +

Ad-Hoc CommandsC: <iq type='set' from='user@server.org' to='service.server.org' id='iq_127'> <command xmlns='http://jabber.org/protocol/commands' node='function_name' action='complete'/>

<THE RPC INPUT/OUTPUT DATA/> </command> </iq>

S: <iq type='result' from='service.server.org' to='user@server.org' id='iq_127'> <command xmlns='http://jabber.org/protocol/commands' sessionid='RPC-SESSION-1' node='function_name' status='completed'>

<THE RPC OUTPUT/OUTPUT DATA/> </command> </iq>

Use Case: Disco and Ad-Hoc CommandsRendering a GUI around a service with the XEP-0004 X-Data envelope

XEP-0004 X-Data Formsoptimized for GUI

Ad-Hoc CommandsC: <iq type='set' from='user@server.org' to='service.server.org' id='iq_127'> <command xmlns='http://jabber.org/protocol/commands' node='function_name' action='complete'/>

<THE RPC INPUT DATA/> </command> </iq>

S: <iq type='result' from='service.server.org' to='user@server.org' id='iq_127'> <command xmlns='http://jabber.org/protocol/commands' sessionid='RPC-SESSION-1' node='function_name' status='completed'>

<THE RPC OUTPUT DATA/> </command> </iq>

X-Data Forms (XEP-0004)GUI

X-Data Forms (XEP-0004)GUI

Web Service related XEPs

} Asynchronous +Stateful -Discoverable -

Asynchronous +Stateful +Discoverable +

Yet another XEP?

SOAP ? something else?WSDL ?

Test Case: Web ServiceServer Component

gandhi

SOAPWSDbfetch

wsdbfetch.gandhi

gandhi

chat-client@gandhi

SOAPWSDbfetch

bioclipse@gandhi

wsdbfetch.gandhi

Test Case: ClientGUI (chat-client), Scripting Environment (Bioclipse)

XEP-0050 Ad-Hoc CommandsTransporting EMBL-EBI’s WSDbfetch Web Service over XMPP

Summary:XMPP is• a well established and widely used XML routing

technology• a server-client oriented architecture• working with unique entity identifiers• offering a discoverable network• an asynchronous protocol (the server can push data to

the client)

Client Serverfunction(data)

“function started”

“result is available”

Andreas Heusler

Egon Willighagen

Ola Spjuth

XEP-0096: File Transfer

Requirements• Enable seamless file transfer, including fall-back

mechanisms as appropriate. • Ensure that the profile will work even when one or both

parties are behind a firewall. • Define a full-featured set of metadata for file transfers,

including the following:– description – size – name – date – hash

• Optionally support ranged transfers.