280 likes | 433 Vues
Part of GGF4 Update Track Toronto February 18 2002 Grid Programming with Web Services, Software Components and Portal Development Tools. Integrating Peer to Peer Networks and Web Services with the Grid. PTLIU Laboratory for Community Grids
E N D
Part of GGF4 Update Track Toronto February 18 2002 Grid Programming with Web Services, Software Components and Portal Development Tools Integrating Peer to Peer Networks and Web Services with the Grid PTLIU Laboratory for Community Grids Geoffrey Fox, Marlon Pierce, Shrideep Pallickara, Choonhan Youn Computer Science, Informatics, Physics Indiana University, Bloomington IN 47404http://grids.ucs.indiana.edu/ptliupages/presentations/ggf4feb02 gcf@indiana.edu uri="gxos://gridform/ggf4/talk/fox" email="gcf@indiana.edu"
Gateway and Web Services • We will use the Gateway Computing Portal as an example (http://www.gatewayportal.org) • It is largely built using CORBA with a Java Server Pages front end • http://community.ucs.indiana.edu:8004/GCWS/BatchScriptGen/Main.jsp • Several capabilities have been interfaced using WSDL • Job Submission (11 Methods including execute local and remote command, copy files etc. as well as Submit Job) • Manage WebFlow Session (67 Methods) • Generate Batch Script (just 1 method but two implementations developed – one at SDSC and one at Indiana – with UDDI to manage) • Each is one service – could have used finer grain services • Sample files are athttp://grids.ucs.indiana.edu/ptliupages/presentations/ggf4feb02 uri="gxos://gridform/ggf4/talk/fox" email="gcf@indiana.edu"
Gateway Architecture • As needed DoD approved Kerberos/SecureID security, does not usually link to standard Grid technology (Globus) Pre WSDL Post WSDL backend backend Add CastorJava to XML Globusor submit to localqueue system Will replacehistorical CORBA By EJB CORBA Corba middle tierSECIOP withJava modules WSDL SOAP wrapperJSP Servlet JSP SSL uri="gxos://gridform/ggf4/talk/fox" email="gcf@indiana.edu"
WSDL Message Example <message name="submitRequest"> <part name="xmljob" type="xsd:string"/> </message> <messagename="submitResponse"> <part name="response" type="xsd:string"/> </message> • For the batch script service, we pass the XML description of the job as a string and get back the script as a string. • In general, any XML primitive or complex types can be used in messages. • We could improve our service by defining a BatchScript complex type. uri="gxos://gridform/ggf4/talk/fox" email="gcf@indiana.edu"
WSDL portTypes Example <portType name="BatchScriptServicePortType"> <operationname="batchGen"> <output message="tns:submitResponse" name="submitResponse"/> <input message="tns:submitRequest" name="submitRequest"/> </operation> </portType> A portType corresponds to a Java class, so if we compile this WSDL to make client stubs, we will generate a BatchScriptServiceBinding.java class. uri="gxos://gridform/ggf4/talk/fox" email="gcf@indiana.edu"
WSDL SOAP Binding Example <binding name="BatchBinding" type="tns:BatchScriptServicePortType"> <soap:bindingstyle="rpc" transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="batchGen"> <soap:operation soapAction=""/> <input> <soap:body use="encoded“ namespace="urn:BatchScriptService" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/> </input> <output> <soap:body use="encoded" namespace="urn:BatchScriptService“ encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/> </output> </operation> </binding> note binding’s “type” attribute points back to the portType tag by name uri="gxos://gridform/ggf4/talk/fox" email="gcf@indiana.edu"
WSDL Ports and Services <service name="BatchScriptService"> <documentation>BS stands for Batch Script </documentation> <port binding="BatchBinding” name="BatchPort"> <soap:address location= "http://yourserver/soap/servlet/rpcrouter/"/> </port> </service> </definitions> ports are concrete implementations of portTypes and point back to a particular binding (by name). They also point to the specific location of a server that implements the service. A service is a collection of one or more ports. uri="gxos://gridform/ggf4/talk/fox" email="gcf@indiana.edu"
What is a Virtual XML Interface • We can specify interfaces in XML but we are not required to implement in XML. • Example 1:We aren’t likely to change syntax of mailReply-to:Geoffrey Fox <gcf@indiana.edu>To: Geoffrey Fox <gcf@grids.ucs.indiana.edu>Subject: A Test for TutorialA simple mail messageGeoffrey Fox gcf@indiana.edu FAX 8128567972Phones Cell 315-254-6387 Home 812323919 • But we could specify and indeed store in XML with transport done using conventional SMTP. • So conventional mail is easy to give a virtual XML specification for withname:value becoming<name>value</name> but this is not only way uri="gxos://gridform/ggf4/talk/fox" email="gcf@indiana.edu"
Mail in XML • <mailasxmluri=“gxos://mail/users/gcf/sent/2002/february/290” ><smtpheaders><reply-toemail=“gcf@indiana.edu”>Geoffrey Fox</reply-to><toemail=“gcf@grids.ucs.indiana.edu” >Geoffrey Fox</to><subject>A Test for Tutorial</subject></smtpheaders><smtpbody><messagewhitespace="collapse"> A simple mail message</message><signature personuri=“ssn://123/45/6789”whitespace=“preserve” > Geoffrey Fox gcf@indiana.edu FAX 8128567972 Phones Cell 315-254-6387 Home 812323919 </signature></smtpbody></mailasxml> • Such an interface could be used by “User Messaging as a Web service” which could perhaps integrate News Groups, e-mail, text chat, instant messenger, voicemail uri="gxos://gridform/ggf4/talk/fox" email="gcf@indiana.edu"
Virtual XML for MPI I • In days gone by, we used to study:MPI_SEND(buf, count, datatype, dest, tag, comm)[ IN buf] initial address of send buffer (choice) [ IN count] number of elements in send buffer (nonnegative integer)[ IN datatype] datatype of each send buffer element (handle) [ IN dest] rank of destination (integer) [ IN tag] message tag (integer) [ IN comm] communicator (handle) • Now our SPMD code is a Web service running in some large scale parallel machine – perhaps integrated with an Apache server running on node • Need to support distributed and shared memory • We want to define all interfaces in WSDL – at least all of them which could be “external” ports uri="gxos://gridform/ggf4/talk/fox" email="gcf@indiana.edu"
Virtual XML for MPI II • datatype becomes an XML Schema specifying structure of transmitted data – could either be a URI for Schema or its realization • There would be a built-in schema suitable for handling standard Fortran/C datatypes • buf is a handle to an XML instance of Schema datatype • count is still an integer (xs:integer where xs is Schema namespace xmlns:xs=http://www.w3.org/2001/XMLSchema) • For some bindings count is implied by buf • dest becomes a URI with special notation such as legacympi://procnum/local/nnn for processor numbers • tag becomes an instance of (new) mpitag Schema • comm becomes an instance of (new) mpicommunicator Schema uri="gxos://gridform/ggf4/talk/fox" email="gcf@indiana.edu"
Virtual XML for MPI III • So one defines mpi.wsdl with all 100 or so methods defined as (abstract) operations • We will define several bindings including the classic HPCC method calls for Fortran C C++ and Java with either distributed memory or shared memory mode • For C++ and Java we would implements bindings for either “object” or “packed consecutive byte” interpretation of buf • Note one can use both static and run-time compilation to map XML specified services into particular implementations • MPI_INIT() might be implemented with JXTA (peer-to-peer advertisments) to find nodes; the communicator might be transmitted by SOAP while buf transmission uses MPICH • This brings Web Services to MPI but also MPI to web services uri="gxos://gridform/ggf4/talk/fox" email="gcf@indiana.edu"
CollabWS: Collaboration as a Web Service • This includes Audio-Video conferencing, Instant Messengers, shared applications and tools • There are basic standards H323 and SIP • There are peer to peer collaboration approaches like JXTA from Sun • There are various commercial products – Groove Networks effectively defines some shared application interfaces • CollabWS defines a superset of collaboration properties and subservices in XML/WSDL • Then you provide several bindings of collabws.wsdl to new transports and old ones (binary H323) uri="gxos://gridform/ggf4/talk/fox" email="gcf@indiana.edu"
H323 SIP JXTA uri="gxos://gridform/ggf4/talk/fox" email="gcf@indiana.edu"
SIPH323 JXTA SIP H323 JXTA uri="gxos://gridform/ggf4/talk/fox" email="gcf@indiana.edu"
A Typical SIP Message • REGISTER sip:registrar.biloxi.comVia: SIP/2.0/UDP 10.4.1.4:5060To: Bob (sip:bob@biloxi.com)From: Bob (sip:bob@biloxi.com);tag=456248Call-ID:843817637684230@phone21.boxesbybob.comCSeq: 1826 REGISTERContact: (sip:bob@10.4.1.4)Expires: 7200Contact-Length: 0 • Initially build a wrapper that accepts such messages and converts to ….. uri="gxos://gridform/ggf4/talk/fox" email="gcf@indiana.edu"
Collaboration as a Web service - now uri="gxos://gridform/ggf4/talk/fox" email="gcf@indiana.edu"
SIP as XML • <sipasxml><register> sip:registrar.biloxi.com</register><via> SIP/2.0/UDP 10.4.1.4:5060</via><to> Bob (sip:bob@biloxi.com) </to><from tag="456248" > Bob (sip:bob@biloxi.com) </from><call-id> 843817637684230@phone21.boxesbybob.com</call-id><cseq> 1826 REGISTER </cseq><contact> (sip:bob@10.4.1.4) </contact><expires> 7200 </expires><contact-length> 0 </contact-length></sipasxml> • So this is either an internal format to which we map SIP messages or it is an external format used for Collaboration Web Service uri="gxos://gridform/ggf4/talk/fox" email="gcf@indiana.edu"
Quick SIP as XML (SOAP based WS) • <kwiksipasxmal>REGISTER sip:registrar.biloxi.comVia: SIP/2.0/UDP 10.4.1.4:5060To: Bob (sip:bob@biloxi.com)From: Bob (sip:bob@biloxi.com);tag=456248Call-ID:843817637684230@phone21.boxesbybob.comCSeq: 1826 REGISTERContact: (sip:bob@10.4.1.4)Expires: 7200Contact-Length: 0</kwiksipasxml> • This requires a SIP parser uri="gxos://gridform/ggf4/talk/fox" email="gcf@indiana.edu"
Future Collaboration Web Service uri="gxos://gridform/ggf4/talk/fox" email="gcf@indiana.edu"
Messaging/Events as a Web Service • We can implement messaging subsystem (between WSDL resources) with either direct messages or by a queued system where you publish messages to queues and subscribe as receiver to particular queues • There are many different publish/subscribe models • JMS is a cluster of central servers • JXTA is a very dynamic Peer to Peer model where pipes are queues and topics (metadata) are service advertisements • Implement JMS API with JXTA protocol – different WSDL bindings here have different fault tolerance/reliability semantics • Could use JMS as long distance “carrier” between JXTA peers • JXTA provides higher performance than JMS for nearby recipients uri="gxos://gridform/ggf4/talk/fox" email="gcf@indiana.edu"
Destination Source Matching Routing Filter workflow Web Service 1 Web Service 2 (Virtual)Queue WSDLPorts WSDLPorts Event Web Service uri="gxos://gridform/ggf4/talk/fox" email="gcf@indiana.edu"
Resource Data base Broker Network Software multicast P2P: Brokers are clients Broker Broker Broker Broker Broker Broker uri="gxos://gridform/ggf4/talk/fox" email="gcf@indiana.edu"
Narada JXTA/JMS Integration • http://grids.ucs.indiana.edu/ptliupages/projects/narada/ • Is a network of event brokers which can reliably deliver XML specified events • Using openJMS selection module, becomes a distributed or conventional Java Message Service • Linking special JXTAproxies, it can link JXTA communities • Think of JXTA JMS andNarada as differentbindings toevent/messagingweb service uri="gxos://gridform/ggf4/talk/fox" email="gcf@indiana.edu"