publishing and transporting web services over xmpp johannes wagener
Post on 26-Dec-2015
220 Views
Preview:
TRANSCRIPT
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.
top related