1 / 74

Integrating Peer to Peer Networks and Web Services with the Grid

Part of GGF4 Tutorial Toronto February 17 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

lev-fletcher
Télécharger la présentation

Integrating Peer to Peer Networks and Web Services with the Grid

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Part of GGF4 Tutorial Toronto February 17 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/tutorial2/fox" email="gcf@indiana.edu"

  2. Relational Database “Flat” FileSystem Classic Multi-Tier Architecture Back-end Tier Raw Resources Middle Tier Servers Client Tier Object Broker IIOP HTTP Web Server RMI Specialized Java Server Web Service SOAP + WSDL Old and New Useful Backend Systems uri="gxos://gridform/ggf4/tutorial2/fox" email="gcf@indiana.edu"

  3. Object Web View of the World I • “Everything electronic” is a resource • Computers • Programs • Data (from sensors to this presentation to email to databases) • People • “Everything electronic” is a distributed object • “All External Interfaces” are defined in XML whether this is a property (data-structure) or a method (service, function, subroutine) • We can assume that a data-structure property has getproperty() and setproperty(value) methods to act as interface • All resources have interfaces • All resources are linked by messages with format and transport protocol to be discussed but as interfaces defined in XML, message structure must be specifiable in XML uri="gxos://gridform/ggf4/tutorial2/fox" email="gcf@indiana.edu"

  4. Object Web View of the World II • All resources have a URI which can be a URL (location) to URN (property tag) • I could be ssn://abc/de/fghk or my homepage http://www.w3.org/Addressing/ uri="gxos://gridform/ggf4/tutorial2/fox" email="gcf@indiana.edu"

  5. The 3 Critical XML Interfaces RawResources Raw Data (Virtual) XML Data Interface • Data (sort of dumb) • Information • User Rendering Processing Server Information/Knowledge (Virtual) XML Information Interface Render to XML Display Format (Virtual) XML Rendering Interface Clients uri="gxos://gridform/ggf4/tutorial2/fox" email="gcf@indiana.edu"

  6. 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/tutorial2/fox" email="gcf@indiana.edu"

  7. 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 “Messaging as a Web service” which could perhaps integrate e-mail, text chat, instant messenger, voicemail uri="gxos://gridform/ggf4/tutorial2/fox" email="gcf@indiana.edu"

  8. Quick and Dirty mail as XML • If your boss orders you to produce a quick messaging web service then you might instead define: • <kwikmailasxml whitespace=“preserve” >Reply-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</kwikmailasxml> • This is allowedbut of course relies on an SMTP parser not an XML parser to decode message • Our messaging web service would allow either form but put them on different ports. Internally we would convert to the common XML representation uri="gxos://gridform/ggf4/tutorial2/fox" email="gcf@indiana.edu"

  9. XML in a Nutshell • So we have seen .xml files – XML Instances or the equivalent of Objects in Java • There are corresponding .xsd or Schema files which are the equivalent of Classes in Java • Schema happen to be defined in XML syntax • Schema totally replace DTD’s • Originally Schema defined “things”/”properties”/”data” • At times in this tutorial, we will use .wsdl files which define Web Service Interfaces • The wsdl specification separates into components that specify structure of service which is equivalent to “Abstract Method or Interface” and those that specify actual service (equivalent of program and its methods) uri="gxos://gridform/ggf4/tutorial2/fox" email="gcf@indiana.edu"

  10. XML Rendering Interfaces • The simplest example is XHTML which is HTML in an XML Syntax • See http://www.w3schools.com/xhtml/default.asp • <BR> in HTML MUST become <br/> • <p> must become <p>Material in Paragraph</p> etc. • Another good example is SVG (Scalable Vector Graphics) which is 2D Vector Graphics and can represent • Macromedia Flash • PowerPoint and StarOffice • Adobe Illustrator/Photoshop etc. • See http://grids.ucs.indiana.edu/courses/xinformatics/svg • Here is a snippet of SVG from above link illustrating text, matrix transformations, positioning and styles <texttransform="matrix(1 0 0 1 220.687 216.7256)"style="fill:#66FF00;stroke:none;"><tspanx="5"y="0">Spring Semester 2001 MWF 2:30 pm - 3:20 pm </tspan></text> uri="gxos://gridform/ggf4/tutorial2/fox" email="gcf@indiana.edu"

  11. XML in a Nutshell Concluded • We can browse some examples at:http://grids.ucs.indiana.edu/courses/xinformatics/educexample and on the following page • Note Schema are labeled by URI’s – their namespaces which allow one to build class libraries • WSDL files are also referenced by their URI’s (namespaces) in the XML (SOAP) message communicating between 2 Web services • Note version number in URI • http://grids.ucs.indiana.edu/courses/xinformatics/xmlschemaspring02.ppt • http://www.w3.org/TR/xmlschema-0/are reasonable links • Always remember that XML defines (potentially complicated) objects and it can specify both data and methods this could have profound implications for architecture and implementation of Enterprise infrastructure • Use Castor (http://castor.exolab.org/) to link XML & Java “automatically” uri="gxos://gridform/ggf4/tutorial2/fox" email="gcf@indiana.edu"

  12. A Sample of XML • <?xml version="1.0"?> • <okcversion="3"xmlns="http://grids.ucs.indiana.edu/okc/schema/admin/ver/3"> • <event> • <comment> This is a Test </comment> • <senderemail="gcf@grids.ucs.indiana.edu">Geoffrey Fox</sender> • <distribution> Community Grids Project Reports </distribution> • <organization></organization> • <updatecreateuri="gxos://okc/newsgroups/cgreports/$next“ /> • <keywords></keywords> • <subject></subject> • <message/> • <filingdate> 2/6/2002 </filingdate> • <cg:messageTypexmlns:cg=“http://grids.ucs.indiana.edu/okc/schema/cg/ver/1”> • Test </cg:messageType> • </event> • </okc> Schema are here http://grids.ucs.indiana.edu/schemas/commgrids-v1.xsdhttp://grids.ucs.indiana.edu/schemas/okc-v3.xsd uri="gxos://gridform/ggf4/tutorial2/fox" email="gcf@indiana.edu"

  13. HTTP Delivery with address SOAP over HTTP Structure • SOAP defines a message with envelope, header and body • The SOAP standard also defines a binding to HTTP which is equivalent to methodology for delivering message • The SOAP body can specify data as well as fault processing information • SOAP can be transported over standard mail by just putting XML in body of mail – see http://xml.apache.org/soap/faq/faq_chawke_smtp.html http://www.w3c.org/2000/xp/Group/1/11/16/soap12-primer.html#SMTP uri="gxos://gridform/ggf4/tutorial2/fox" email="gcf@indiana.edu"

  14. SOAP Example from W3C I • We take November 16 tutorial:http://www.w3c.org/2000/xp/Group/1/11/16/soap12-primer.html • This is a SOAP Message – defining a reservation request • Header has key meta-data of application (namelist m: and instructions to SOAP (intermediate actor) processors Start Envelope Start Header End HeaderStart Body uri="gxos://gridform/ggf4/tutorial2/fox" email="gcf@indiana.edu"

  15. SOAP Example (Concluded) Start Body • This has the SOAP Body with actual request End BodyEnd Envelope uri="gxos://gridform/ggf4/tutorial2/fox" email="gcf@indiana.edu"

  16. SOAP Binding to SMTPfrom W3C • Same example as before • This is very straightforward! uri="gxos://gridform/ggf4/tutorial2/fox" email="gcf@indiana.edu"

  17. Remarks on SOAP Structure • If you look at networking protocols, at each layer one specifies a header and a body • HTTP has a header telling system where to send information and some high level specification of what to get • In example, we see that body of HTTP message is full SOAP envelope and this envelope has SOAP Header and Body interpreted by “application” • At a lower level in protocol stack, TCP/IP and ATM etc. have their own headers and bodies • It is the standard Russian Dollsituation – each doll has a body (contained inside it) which is the full doll of higher level protocol HTTP SOAP SOAP Body uri="gxos://gridform/ggf4/tutorial2/fox" email="gcf@indiana.edu"

  18. SOAP Attachments • This uses same approach as email or HTTP and is a general way of including binary data in XML – but not understood by most parsers! • Very important? XML links to MIMEAttachment using absolute or relative URI’s uri="gxos://gridform/ggf4/tutorial2/fox" email="gcf@indiana.edu"

  19. What is a Web Service I • A web service is a computer program running on either the local or remote machine with a set of well defined interfaces (ports) specified in WSDL • In principle, computer program can be in any language (Fortran .. Java .. Perl .. Python) and the interfaces can be implemented in any way what so ever • Interfaces can be method calls, Java RMI Messages, CGI Web invocations, totally compiled away (inlining) but • The simplest implementations involve XML messages (SOAP) and programs written in net friendly languages like Java and Python • Web Services separate the meaning of a port (message) interface from its implementation uri="gxos://gridform/ggf4/tutorial2/fox" email="gcf@indiana.edu"

  20. What is a Web or Grid Service II? • The Webis distributed system allowing communities to access seamlessly heterogeneous resources from heterogeneous clients • Resources are web-pages, instruments, Object repositories, Simulation codes running on supercomputers …. • A Serviceis a generic application or capability respecting standards (general web and application specific) allowing multiple providers to compete on a given service • For a simulation to be a web service, we want it to have standard interfaces so be run from standard “portals” and access “standard format” data Middle TierBroker Portal is customizable User interface Back endCapability Resource uri="gxos://gridform/ggf4/tutorial2/fox" email="gcf@indiana.edu"

  21. PaymentCredit Card Security Catalog Warehouse shipping Role of Web Services • Define interfaces of web applications so that computer-computer interactions are enabled • Defines virtual XML for all system and application services • WSDL is XML versions of Class and Method definitions • SOAP is XML version of message • UDDI or WSIL catalogs WSDL based services enabling precise linkage of them • WSFL and WSCL are candidate linkage languages WSDL interfaces WSDL interfaces uri="gxos://gridform/ggf4/tutorial2/fox" email="gcf@indiana.edu"

  22. Web Service (WS) WS WS WS WS WS WS RawResources Raw Data Raw Data (Virtual) XML Data Interface WS WS etc. XML WS to WS Interfaces (Virtual) XML Knowledge (User) Interface Render to XML Display Format (Virtual) XML Rendering Interface Clients uri="gxos://gridform/ggf4/tutorial2/fox" email="gcf@indiana.edu"

  23. UDDI or WSIL WSFL WSDL SOAP or RMI HTTP or SMTP or IIOP or RMTP TCP/IP Physical Network Some Sort of XML Protocol Stack • Protocols are built in a layered fashion – one on top of another • At higher (highest) level a protocol becomes an API (Application Interface) • Some reserve protocol to denote the representation of a process involving some negotiation but to my naïve view there is no consensus as to difference between an API and a protocol • We are expanding application (top) layer of OSI protocol stack uri="gxos://gridform/ggf4/tutorial2/fox" email="gcf@indiana.edu"

  24. UDDI or WSIL WSFL WSDL SOAP or RMI HTTP or SMTP or IIOP or RMTP TCP/IP Physical Network Details of Application Layer • UDDI finds where programs are • remote( (distributed) programs are just Web Services • WSFL links programs together • WSDL defines interface (methods, parameters, data formats) • SOAP defines structure of message including serialization of information • HTTP is negotiation/transport protocol • TCP/IP is layers 3-4 of OSI • Physical Network is layer 1 of OSI uri="gxos://gridform/ggf4/tutorial2/fox" email="gcf@indiana.edu"

  25. Role of UDDI with WSDL • UDDI plays a role like find or grep under UNIX or Google on the web or yellow pages in the real world • A critical difference is that UDDI aims at finding resources matching precise information • Suppose we were a shopping cart service and told by a customer that we need to contact the SuchandSuch online credit card system • We would not only need to find www.suchandsuch.com but also identify the exact URL’s for “approval” and “payment” channels – we would need to get the syntax correct for exchanging data • For instance, we would need to know if system used US Canadian or HK dollars • So UDDI knows about WSDL Interfaces and this knowledge enables programs with such interfaces to link together • UDDI and WSDL together enable dynamic applications • Note “service” just means web-based application built according to agreed interaction rules – such “plug and play” software usually called “components” uri="gxos://gridform/ggf4/tutorial2/fox" email="gcf@indiana.edu"

  26. Software Engineering and WSDL/SOAP? • Software Engineering is a field whose goal is agreed by most to be important • Namely to codify the building of software so that it is more re-usable, modular, easier to maintain and easier to build with teams • However there is not so much agreement as to how to do this and if the field has established itself • WSDL is part of component-based software engineering methodology of the web • As the Web could be a set of processes and threads on a single PC or Palmtop, WSDL can in fact provide software engineering for conventional sequential or parallel computing. • WSDL/SOAP addresses same issues as calling sequences and library methodology in conventional programming uri="gxos://gridform/ggf4/tutorial2/fox" email="gcf@indiana.edu"

  27. WSDL and SOAP • 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/tutorial2/fox" email="gcf@indiana.edu"

  28. 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/tutorial2/fox" email="gcf@indiana.edu"

  29. SOAP Server Client Web Browser (HTML) SOAP over HTTP HTTP(s) Service Components User Interface Web Server The deployment descriptor maps the SOAP request to the correct service component (Apache SOAP specific). UI Server Components (including SOAP Client) Basic Portal SOAP Interaction uri="gxos://gridform/ggf4/tutorial2/fox" email="gcf@indiana.edu"

  30. Server-Server Communication for Basic SOAP Requests • We have two servers: • User interface (UI) server. Includes components for basic functionality (like managing user sessions) plus SOAP client modules. • SOAP server. Converts SOAP requests into calls to the underlying service. • User interacts with UI to make requests for services. • UI server constructs SOAP request and acts as the SOAP client. For example, if UI server is Tomcat, developer uses Apache SOAP’s Java API implementation to create JavaBean components to act as SOAP clients. • SOAP server executes the request (generate batch script) and returns response. • Note that the UI’s SOAP component must match the interface on the SOAP server. This is where WSDL will come in. • UI server formats display for user. uri="gxos://gridform/ggf4/tutorial2/fox" email="gcf@indiana.edu"

  31. SOAP and Gateway Portal I • Having specified service in WSDL, the run-time is implemented in SOAP which is “just” an XML header (info needed by transport – empty here) and body • Here is SOAP transported by HTTP message • This is execLocalCommand WSDL operation to run one particular command (ls) on current WebFlow directory HTTP Header Argument of operation Specify ls as SOAP Envelope and body uri="gxos://gridform/ggf4/tutorial2/fox" email="gcf@indiana.edu"

  32. SOAP and Gateway Portal II HTTP Header SOAPEnvelopeand body • And this is the result of ls sent back to client in SOAP over HTTP uri="gxos://gridform/ggf4/tutorial2/fox" email="gcf@indiana.edu"

  33. WSDL Abstractions • WSDL abstracts a program as an entity that does something given one or more inputs with its results defined by streams on one or more outputs. • Functions are defined by method name and parametersmethodname(parm1,parm2, … parmN) • Where parameters are “Input” “Output” or both • In WSDL, we will have a Web Service which like a (Java or CORBA Program) can be thought of as a (distributed) object with many methods • Instead of a function call, the “calling routine” sends an XML message to the Web Service specifying methodname and values of the parameters • Note name of function is just another parameter uri="gxos://gridform/ggf4/tutorial2/fox" email="gcf@indiana.edu"

  34. 7 Primitives in WSDL • types: which provides data type definitions used to describe the messages exchanged. • message: which represents an abstract definition of the data being transmitted. A message consists of logical parts, each of which is associated with a definition within some type system. • operation– an abstract description of an action supported by the service. • portType: which is a set of abstract operations. Each operation refers to an input message and output messages. • binding: which specifies concrete protocol and data format specifications for the operations and messages defined by a particular portType. • port: which specifies an address for a binding, thus defining a single communication endpoint. • service: which is used to aggregate a set of related ports uri="gxos://gridform/ggf4/tutorial2/fox" email="gcf@indiana.edu"

  35. Discussion of 7 WSDL Primitives • types specify data-structures which are equivalent to arguments of methods • message specifies collections of types and is equivalent to set of arguments in a method call. Note that it is an “abstract method” in Java terminology • operation is a a collection of input output and fault messages; there are 4 types of operation one-way(service just receives a message), request-response(RPC), solicit-response, notification (services pushes out a message) • portType represents a single channel that can support multiple operations. It is “abstract” as specified as a set of operations. It is equivalent to a “interface or abstract class” in Java • binding tells you transport and message format for a porttype (which can have multiple bindings to reflect say performance-portability trades) • port combines a binding and an endpoint network address (URL) and is like a “class instance” • service consists of multiple ports and is equivalent to a “program” in Java uri="gxos://gridform/ggf4/tutorial2/fox" email="gcf@indiana.edu"

  36. Client Web Browser (HTML) SOAP Server SOAP over HTTP HTTP(s) Service Components User Interface Web Server WSTK compiles WSDL into client stubs that can be used by UI components UI Server Components (including WSDL clients) Basic Portal WSDL Interaction uri="gxos://gridform/ggf4/tutorial2/fox" email="gcf@indiana.edu"

  37. WSDL-Based Portal Services • Basically the same as SOAP server-server interaction described previously. • We can use Web Services Toolkit (WSTK) from IBM to generate java client stubs from the WSDL interface. These stubs can be used to create “local” java objects in the UI server that use SOAP RPC to talk to server. So the WSTK creates CORBA-like remote objects. • We still use SOAP+HTTP under the hood to make the method calls. uri="gxos://gridform/ggf4/tutorial2/fox" email="gcf@indiana.edu"

  38. <?xml version="1.0" encoding="UTF-8" ?> <definitionsname="BatchScriptService" targetNamespace="http://yourserver/BatchScriptService" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:tns="http://yourserver/BatchScriptService" xmlns:xsd="http://www.w3.org/1999/XMLSchema“> WSDL Definitions and Namespaces Default Schema (null namespace) is WSDLsoap namespace is SOAP binding of WSDLtns namespace is this WSDL file xsd namespace defines (ancient) XML Schema uri="gxos://gridform/ggf4/tutorial2/fox" email="gcf@indiana.edu"

  39. 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/tutorial2/fox" email="gcf@indiana.edu"

  40. 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/tutorial2/fox" email="gcf@indiana.edu"

  41. 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/tutorial2/fox" email="gcf@indiana.edu"

  42. 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/tutorial2/fox" email="gcf@indiana.edu"

  43. Client Web Browser (HTML) UDDI Server SOAP over HTTP (1) HTTP(s) (2) User Interface Web Server SOAP Server SOAP over HTTP (3) UI Modules include both WSDL and UDDI clients Portal UDDI Interaction uri="gxos://gridform/ggf4/tutorial2/fox" email="gcf@indiana.edu"

  44. SOAP+UDDI+WSDL • UI server now includes both WSDL and UDDI client components. • UI’s UDDI components are, for example JavaBeans using UDDI4J API to interact with the UDDI. • The UDDI client components can be used to build administrator HTML/JSP interfaces to add, modify UDDI entries on the server. • UDDI client components can also be used to build search interfaces for regular users. • Note the UDDI client implementation uses SOAP for RPC to talk to the server. uri="gxos://gridform/ggf4/tutorial2/fox" email="gcf@indiana.edu"

  45. Steps 1-3 on Figure • User requests that the UI server performs a search for a particular service. • UI server now acts as a client to the UDDI server, gets back the search results, plus URLs for the SOAP servers and the WSDL for the desired service. • User selects the desired service provider from UI’s display. UI then becomes client to the SOAP server and executes the service. uri="gxos://gridform/ggf4/tutorial2/fox" email="gcf@indiana.edu"

  46. 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/tutorial2/fox" email="gcf@indiana.edu"

  47. 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/tutorial2/fox" email="gcf@indiana.edu"

  48. SimulationComponent DataComponent PersistentStorage HPCEngine Data base ParallelI/O … MPI .. XML basedInterfacesWSDL JavaC++ ..Proxy JavaC++ ..Proxy SOAP IIOPRMI ….. HPCC andWSDL BackendResources MPP Middle Tier Client uri="gxos://gridform/ggf4/tutorial2/fox" email="gcf@indiana.edu"

  49. 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/tutorial2/fox" email="gcf@indiana.edu"

  50. WebApplication1 Single Address space stack WebServer Method2 Method1 Compiling for WSDL WebApplication2 WebServer WSDL Messages Shared Memory Distributed System uri="gxos://gridform/ggf4/tutorial2/fox" email="gcf@indiana.edu"

More Related