1 / 50

Web Services and Peer-to-Peer Technologies for the Grid

ICCS Amsterdam April 24 2002. Web Services and Peer-to-Peer Technologies for the Grid. PTLIU Laboratory for Community Grids Geoffrey Fox Computer Science, Informatics, Physics Indiana University, Bloomington IN 47404 http://grids.ucs.indiana.edu/ptliupages/presentations/iccsapril02.

tcolmenero
Télécharger la présentation

Web Services and Peer-to-Peer Technologies for 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. ICCS Amsterdam April 24 2002 Web Services and Peer-to-Peer Technologies for the Grid PTLIU Laboratory for Community Grids Geoffrey Fox Computer Science, Informatics, Physics Indiana University, Bloomington IN 47404http://grids.ucs.indiana.edu/ptliupages/presentations/iccsapril02 gcf@indiana.edu uri="http://grids.ucs.indiana.edu/ptliupages/presentations/iccsapril02" email="gcf@indiana.edu"

  2. The Application Service Model • There are generic Grid system services: security, collaboration, persistent storage, universal access • OGSA (Open Grid Service Architecture) is implementing these as extended Web Services • An Application Web Service is a capability used either by another service or by a user • It has input and output ports – fed by devices or other services • A service “is a component” and is a replacement for a library in case where performance allows • Services (components) are a sustainable model of software development – each service has documented capability with standards compliant interfaces • XML defines interfaces at several levels • WSDL at Service interface level and XSIL or equivalent for scientific data format • A service can be written as Perl, Python, Java Servlet, Enterprise Javabean, CORBA (C++ or Fortran) Object … • Communication protocol can be RMI (Java), IIOP (CORBA) or SOAP (HTTP, XML) …… uri="http://grids.ucs.indiana.edu/ptliupages/presentations/iccsapril02" email="gcf@indiana.edu"

  3. 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 XML (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 • Enhances/Enables Re-usable component model of ANY electronic resource uri="http://grids.ucs.indiana.edu/ptliupages/presentations/iccsapril02" email="gcf@indiana.edu"

  4. 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="http://grids.ucs.indiana.edu/ptliupages/presentations/iccsapril02" email="gcf@indiana.edu"

  5. Database Database Classic Grid Architecture Resources Content Access Composition Middle TierBrokers Service Providers Netsolve Security Collaboration Computing Middle Tier becomes Web Services Clients Users and Devices uri="http://grids.ucs.indiana.edu/ptliupages/presentations/iccsapril02" email="gcf@indiana.edu"

  6. PaymentCredit Card WSDL interfaces Security Catalog Warehouse shipping WSDL interfaces What is a Web Service II • Web Services have important implication that ALL interfaces are XML messages based. In contrast • Most Windows programs have interfaces defined as interrupts due to user inputs (see WSIA and W3C DOM) • Most software have interfaces defined as methods which might be implemented as a message but this is often NOT explicit uri="http://grids.ucs.indiana.edu/ptliupages/presentations/iccsapril02" email="gcf@indiana.edu"

  7. What is a Web Service III • This is a server NOT a client model • “Everything electronic” is a resource (= distributed object or = service) • Computers; Programs; People • Data (from sensors to this presentation to email to databases) • All resources have interfaces which are defined in XML for both properties (data-structure) and methods (service, function, subroutine) • We can assume that a data-structure property has getproperty() and setproperty(value) methods to act as interface • All resources are linked by messages with structure, which must be specifiable in XML • All resources have a URI such as unique://a/b/c ……. uri="http://grids.ucs.indiana.edu/ptliupages/presentations/iccsapril02" email="gcf@indiana.edu"

  8. 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="http://grids.ucs.indiana.edu/ptliupages/presentations/iccsapril02" email="gcf@indiana.edu"

  9. UDDI or WSIL WSFL WSDL SOAP or RMI HTTP or SMTP or IIOP or RMTP TCP/IP Physical Network Details of WSDL Protocol Stack • UDDI finds where programs are • remote( (distributed) programs are just Web Services • WSFL links programs together(under revision?) • 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="http://grids.ucs.indiana.edu/ptliupages/presentations/iccsapril02" email="gcf@indiana.edu"

  10. Examples of Web Services I • OGSA (Open Grid Service Architecture) • Integrate Web Service and Grid Concepts and allows Globus to be implemented as Web Services • Audio-Video Conferencing as a Web Service • Integrates H323, SIP, JXTA (etc.) protocols by mapping to single XML Interface • Provides VRVS reflector model from Messaging Web Service • Messaging or Event Web Service provides intelligent routing and buffering of messages • Computing as a Web service • Job submittal, status, composition, data services, visualization • Performance WS allows access to distributed monitoring data, analysis, models, and final benchmarks with interoperable XML interfaces uri="http://grids.ucs.indiana.edu/ptliupages/presentations/iccsapril02" email="gcf@indiana.edu"

  11. Examples of Web Services II • Education as a Web Service • One of easiest to do as object standards well defined (IMS) and little performance issues • Grading, Homework submission, registration, assessment etc. • Universal Access and Web Services • As Web Services allow multiple implementation of a particular interface, one can adjust to needs of particular clients (PDA v. versus, impaired sight etc.). See WSRP • Can build custom implementations of certain web services for particular communities but re-use others • Collaborative Web Services • As interfaces all message based, much easier to share Web Services than other applications (PowerPoint interface is NOT message based and harder to share than server app) uri="http://grids.ucs.indiana.edu/ptliupages/presentations/iccsapril02" email="gcf@indiana.edu"

  12. Education as a Web Service • Can link to Science as a Web Service and substitute educational modules • “Learning Object” XML standards already exist from IMS/ADL http://www.adlnet.org – need to update architecture • Web Services for virtual university include: • Registration • Performance (grading) • Authoring of Curriculum • Online laboratories for real and virtual instruments • Homework submission • Quizzesof various types (multiple choice, random parameters) • Assessment data access and analysis • Synchronous Delivery of Curricula • Scheduling of courses and mentoring sessions • Asynchronous access, data-mining and knowledge discovery • Learning Plan agents to guide students and teachers uri="http://grids.ucs.indiana.edu/ptliupages/presentations/iccsapril02" email="gcf@indiana.edu"

  13. XMLSkin XMLSkin Data base e-Science is XML Specified Resourcesconnected by XML specified messages Message Or Event Based InterConnection Software Resource Software Resource Implementation of resource and connection may or may not be XML uri="http://grids.ucs.indiana.edu/ptliupages/presentations/iccsapril02" email="gcf@indiana.edu"

  14. Biased History of Computing • In almost the beginning, there was Fortran and formats (6I5, 5F10.4) for data • ………………………….. • 1993-1997: HTML came along for Web Pages • 1998-…: XML was developed to define information in documents while HTML defining rendering • But soon it became used for specifying all data and their format • 2001: Web Services allowed XML to specify methods (subroutines) as well as data • Java, C++, Python, Perl, .. Fortran are now “just” the insides of XML specified programs uri="http://grids.ucs.indiana.edu/ptliupages/presentations/iccsapril02" email="gcf@indiana.edu"

  15. How do we organize all this • As everything is a resource implemented as a Web Service, we need a common description framework for • back end supercomputers and a petabyte data • Microsoft PowerPoint and this file • Grids tend to organize large back end resources but peer to peer (P2P) technology more natural for the digital equivalent of the scraps of information in each of the multiple sub-communities in a “virtual organization” • Grids and P2P approaches can be integrated by building both in terms of Web Services with different implementations of core services such as discovery, and event or message transport/filter ….. • Use JXTA as “typical” P2P technology as architecture clear • Gives a Peer-to-Peer Grid uri="http://grids.ucs.indiana.edu/ptliupages/presentations/iccsapril02" email="gcf@indiana.edu"

  16. Database Database Event/MessageBrokers Event/MessageBrokers Integrate P2P and Grid/WS Peer to Peer Grid JXTA Web Service Interfaces Web Service Interfaces JXTA A democratic organization Peer to Peer Grid uri="http://grids.ucs.indiana.edu/ptliupages/presentations/iccsapril02" email="gcf@indiana.edu"

  17. Data base Broker Network (P2P) Community For message/events service Broker Broker (P2P) Community Resource Broker Broker Broker (P2P) Community Software multicast Broker (P2P) Community uri="http://grids.ucs.indiana.edu/ptliupages/presentations/iccsapril02" email="gcf@indiana.edu"

  18. Destination Source Matching Routing Filter workflow Web Service 1 Web Service 2 (Virtual)Queue WSDLPorts WSDLPorts Broker Event Web Service • Filter is mapping to PDA or slow communication channel (universal access) – see our PDA adaptor • Workflow natural as all messages “intercepted” by Event Web Service • Routing illustrated by JXTA • Destination-Source matching illustrated by JMS • Publish-subscribe uri="http://grids.ucs.indiana.edu/ptliupages/presentations/iccsapril02" email="gcf@indiana.edu"

  19. 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 • events are time stamped messages • There are many different publish/subscribe models • JMS is a classic Grid-like cluster of central servers • JXTA is a very dynamic Peer to Peer model where pipes are queues and topics (metadata) are service advertisements • JXTA naturally supports local dynamic structure but • JMS is long distance “carrier” between JXTA peers and supports global relatively static resources uri="http://grids.ucs.indiana.edu/ptliupages/presentations/iccsapril02" email="gcf@indiana.edu"

  20. Narada P2P Grid Event Service • http://grids.ucs.indiana.edu/ptliupages/projects/narada/ • Is a network of event brokers which can reliably deliver XML specified events with UDP or TCP/IP • Using openJMS selection module, becomes a distributed or conventional Java Message Service • Linking selected JXTArendezvous’s, it also supports multiple JXTA communities • Think of JXTA JMS andNarada as differentbindings for aevent/messagingweb service uri="http://grids.ucs.indiana.edu/ptliupages/presentations/iccsapril02" email="gcf@indiana.edu"

  21. Database e-Science is just a pile of XML • Each leaf is a piece of XML either defining a nugget of information or a Service and/or containing links to other XML or “raw resources” uri="http://grids.ucs.indiana.edu/ptliupages/presentations/iccsapril02" email="gcf@indiana.edu"

  22. XML (RSS) Specification of Information Nuggets • <itemrdf:about="http://xml.com/pub/2000/08/09/xslt/xslt.html"> • <title> Processing Inclusions with XSLT </title> • <link>http://xml.com/pub/2000/08/09/xslt/xslt.html</link> • <description> • Processing document inclusions with general XML tools can be problematic. </description> • </item> • <item rdf:about="http://xml.com/pub/2000/08/09/rdfdb/index.html"> • <title> Putting RDF to Work </title> • <link>http://xml.com/pub/2000/08/09/rdfdb/index.html</link> • <description> • Tool and API support for the Resource Description Framework is slowly coming of age. </description> • </item> • </rdf:RDF> Example of XML meta-data in the “pile”pointing to other (outside) resources Links are essential as much meta-data willNOT be co-located with resource uri="http://grids.ucs.indiana.edu/ptliupages/presentations/iccsapril02" email="gcf@indiana.edu"

  23. Distributed Information Actually the XML is distributed all around in a dynamic Grid uri="http://grids.ucs.indiana.edu/ptliupages/presentations/iccsapril02" email="gcf@indiana.edu"

  24. Note XML specifiesboth internal andexternal nodes of tree root escience://root/one/two/bottom one two bottom Tree Structured Information • Roughly current organization of Web (Grid) uri="http://grids.ucs.indiana.edu/ptliupages/presentations/iccsapril02" email="gcf@indiana.edu"

  25. root escience://root/one/two/mess one two mess “mess” can be multiple levels of tree Unstructured and Structured XML • Peer to Peer natural for unstructured “mess” (local broadcast) • Get a Grid of P2P organized communities uri="http://grids.ucs.indiana.edu/ptliupages/presentations/iccsapril02" email="gcf@indiana.edu"

  26. Database Database Grid Middleware Grid Middleware Grid Middleware Grid Middleware MP Group MP Group MP Group MP Group MP=Middleware Peer uri="http://grids.ucs.indiana.edu/ptliupages/presentations/iccsapril02" email="gcf@indiana.edu"

  27. Audio Video Conferencing as a Web Service • We can use openh323 as core of a web service for audio video conferencing • We have designed XGSP as a common XML session protocol including SIP and H323 capabilities • We add additional commands to extend web service to support heterogeneous clients and new fault tolerance and audio mixing options • Will support traditional (H323, SIP) or new generationclients with native XML (JXTA) • Event Service must support UDP and Real-time constraints • WSDL must “bind” to RTP transport used in A/V field • Include Internet Audio (NetMeeting, HearMe SIP ….), Polycom (H323), Voice over IP Phones, and Access Grid (MBONE) uri="http://grids.ucs.indiana.edu/ptliupages/presentations/iccsapril02" email="gcf@indiana.edu"

  28. New TechXGSP A/V Conferencing Web Services Event/MessageService JXTAGateway SetupSession JXTA SIP SIPGateway MediaServer H323Gateway H323 MixAudio AGGateway ConvertCodec AccessGrid uri="http://grids.ucs.indiana.edu/ptliupages/presentations/iccsapril02" email="gcf@indiana.edu"

  29. XML General Session Protocol I <xs:complexType name="SessionDes"> <xs:sequence> <xs:element name="SessionName" type="xs:string"/> <xs:element name="SessionID" type="SessionID"/> <xs:element name="SessionCreator" type="UserURL"/> <xs:element name="SessionInfo" type="xs:string"/> <xs:element name="SessionTime"> <xs:complexType> <xs:sequence> <xs:element name="StartTime" type="xs:dateTime"/> <xs:element name="EndTime" type="xs:dateTime"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="SessionURI" type="xs:anyURI"/> <xs:element name="SessionParticipants" maxOccurs="unbounded"> <xs:complexType> <xs:complexContent> <xs:extension base="UserURL"/> </xs:complexContent> </xs:complexType> </xs:element> <xs:element name="ContactInfo" type="UserURL"/> </xs:sequence> </xs:complexType> “random”fragment uri="http://grids.ucs.indiana.edu/ptliupages/presentations/iccsapril02" email="gcf@indiana.edu"

  30. XML General Session Protocol II <xs:complexType> <xs:sequence> <xs:element name="MediaCodec" type="xs:string"/> <xs:element name="CodecParam"> <xs:complexType> <xs:choice> <xs:element name="H.261" type="xs:H.261"/> <xs:element name="H.263" type="xs:H.263"/> <xs:element name="G.711" type="xs:G.711"/> <xs:element name="G.722" type="xs:G.722"/> <xs:element name="G.723" type="xs:G.723"/> <xs:element name="G.728" type="xs:G.728 "/> <xs:element name="G.729" type="xs:G.729"/> <xs:element name="GSM" type="xs:GSM"/> </xs:choice> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> uri="http://grids.ucs.indiana.edu/ptliupages/presentations/iccsapril02" email="gcf@indiana.edu"

  31. 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 XGSP uri="http://grids.ucs.indiana.edu/ptliupages/presentations/iccsapril02" email="gcf@indiana.edu"

  32. Portals and Web Services • Web Services allow us to build a component model (see CCA) for resources. • Each resource naturally has a user interface (which might be customized for user) specified in WSRP/WSIA from OASIS • Web Service <--> Portlet • Natural to use a component model for portal building displayed web page from collection of portlets • So can customize each portlet and customize which portlets you want • Apache Jetspeed seems good open source technology supporting this model • JSP model is better than say a client-side Java integration in that also message based so this is “Portal as a Web Service” uri="http://grids.ucs.indiana.edu/ptliupages/presentations/iccsapril02" email="gcf@indiana.edu"

  33. Application as a WSGeneral Application PortsInterface with other WebServices PortalUser ProfileAggregateUI Fragments Client WSDL W S Application orContent source R P Web Service User Face ofWeb ServiceWSRP Ports define WS as a Portlet Integrate Multiple Portlets User Customizationat either Portal or if complicated at WS WSRP Structure of a Portlet • When one has multiple components in the UI one must extend Web Service picture to include Portal and Portlets • WSRP and indeed WSDL details unimportant. Need basic architecture with message based middleware WSRP isWeb Services for Remote Portals1st Meeting OASIS March 18 2002 uri="http://grids.ucs.indiana.edu/ptliupages/presentations/iccsapril02" email="gcf@indiana.edu"

  34. Online Knowledge Center built from Portlets A set of UIComponents • Web Services provide a component model for the middleware (see large “common component architecture” effort in Dept. of Energy) • Should match each WSDL component with a corresponding user interface component • Thus one “must use” a component model for the portal with again an XML specification (portalML) of portal component uri="http://grids.ucs.indiana.edu/ptliupages/presentations/iccsapril02" email="gcf@indiana.edu"

  35. 4 available portletslinking to Web ServicesI choose two Jetspeed Computing Portal: Choose Portlets uri="http://grids.ucs.indiana.edu/ptliupages/presentations/iccsapril02" email="gcf@indiana.edu"

  36. Choose Portlet Layout Choose 1-column Layout Original 2-column Layout uri="http://grids.ucs.indiana.edu/ptliupages/presentations/iccsapril02" email="gcf@indiana.edu"

  37. Two Computing Portlets uri="http://grids.ucs.indiana.edu/ptliupages/presentations/iccsapril02" email="gcf@indiana.edu"

  38. Portal Shell • Our Gateway portal supports many methods or Sub Web Services • Over 80 is a lot to agree on – need to breal up into Services with a few parts (methods) • Think of as a Portal Shell invoking many specific other services such as • run myws, ls, cd, cat mwsarchive, visualize …. • Both Shell and sub services could have separate UI components • Services like ls could be instantaneous or updated as needed • If instantaneous, need to archive results as portlet lasts a different length of time from transient ls uri="http://grids.ucs.indiana.edu/ptliupages/presentations/iccsapril02" email="gcf@indiana.edu"

  39. WSDL WSDL W S Application orPortal WS Factory WS R P Web Service Web Service WSDL W S Portal Shell R P Web Service WSDLArchive Transient or “Permanent” or WSDL PersistentContent WS WSRP Integrate Multiple PortletsUser Customizationat either Portal or if complicated at WS User Face ofWeb ServiceWSRP Ports define WS as a Portlet ClientRender PortalUser ProfileAggregateUI Fragments uri="http://grids.ucs.indiana.edu/ptliupages/presentations/iccsapril02" email="gcf@indiana.edu"

  40. WordWSFactory fred.doc Wordas aWS UserI/O FileI/OWS Portal myWSarchive.wsdl I • Please imagine that Microsoft Word becomes a Web Service ….. • We are familiar with a file like fred.doc on our PC where .doc indicates the appropriate handler for file • fred.doc will be mix of XML (meta)data and perhaps binary attachments • Several web services (Word, StarOffice ..) can produce fred.doc • They all support same Word.wsdl interface • Even more web services can process (handle) fred.doc • Word, StarOffice, Notepad (XML dump), Copy are WordWS handlers • These correspond to different ports specified directly (as XML) or indirectly (as URI) in fred.doc uri="http://grids.ucs.indiana.edu/ptliupages/presentations/iccsapril02" email="gcf@indiana.edu"

  41. UserI/O Job PortalShell Portal Transient for length of job FileI/OWS myWS myWS (handler)Factory PersistentmyWS.wsdl FileI/OWS UserI/O myWS Handler Portal Transient for length of user portal session myWS.wsdl myWSarchive.wsdl II • We build our environments in terms of Web Services which can be transient as well as persistent Web Service documents analogous to fred.doc myWS.wsdl can bemultiple files with XML wrapperdefining actionof handlers uri="http://grids.ucs.indiana.edu/ptliupages/presentations/iccsapril02" email="gcf@indiana.edu"

  42. Collaborative Web Services • First note that there are two distinct concepts • Collaboration as a Web Service • Such as “Audio-Video Conferencing” as a Web Service or “Text Chat as a Web Service” • Collaborative Web Services • Here we view a Web Service as specifying a (distributed) object and wish to share an object • Object could be a Web page, a Job status form, a scientific visualization, a PowerPoint slide etc. (not all of these are Web Services but all should be) • There is an overall framework (part of collaboration as a web service) specifying such items as members of collaborative session and their preferences. There is a mechanism to make Web services collaborative within this framework uri="http://grids.ucs.indiana.edu/ptliupages/presentations/iccsapril02" email="gcf@indiana.edu"

  43. Why Web Services for Collaboration • Well everything is meant to be a Web Service but also: • Web Services are MUCH EASIER to make collaborative than other objects because all input and output is defined by uniform XML messages • You need to teach your message service about collaboration! • Note local applications are NOT Web Services – input is things like “user mouse click” represented by “method events” (UI program interrupts) not “XML message events” • The elegance of collaborative web services suggest that it could be easiest to make object X (such as PowerPoint or SVG) collaborative not by traditional direct methods but by converting to a Web Service uri="http://grids.ucs.indiana.edu/ptliupages/presentations/iccsapril02" email="gcf@indiana.edu"

  44. Key Types of Collaboration • Shared Display: here one shares the rendering of a Web Service. No modification is needed of the web service. Rather this is handled by the portal controlling the user interface • Collaborative Replicated Web Services: here one replicates several instances of a web service and the task is to keep these copies consistent. This synchronizes inputs to multiple Web Services • Collaborative Web Service Access: here one has multiple clients accessing a single instance of a web service and obtaining consistent views. This multicasts output of a single Web service to multiple clients uri="http://grids.ucs.indiana.edu/ptliupages/presentations/iccsapril02" email="gcf@indiana.edu"

  45. SharedWeb Service SharedDisplay Shared Export Shared Event Object Viewer Object Display Object Object’ Object’’ In these and following diagrams, we havethree collaborating clients; is masterwhile and are non-masters Collaboration: Shared Display • Sharing can be done at any point on “object” pipeline Master Event(Message)Service Object Display Shared Display shares framebuffer with eventscorresponding to changedpixels in master client. Object Display uri="http://grids.ucs.indiana.edu/ptliupages/presentations/iccsapril02" email="gcf@indiana.edu"

  46. Object Viewer Object Display Collaborative Web Service Access • Web Service either supports collaboration directly or uses event service Web Service InterceptorProviding General Services Set Collaboration Mode Master WebService Object Object Viewer Object Display Web Service has a porton which collaborativemodes set Web Service can be“front-end” (in middletier) to complex back-end object Event(Message)Service Object Viewer Object Display uri="http://grids.ucs.indiana.edu/ptliupages/presentations/iccsapril02" email="gcf@indiana.edu"

  47. Web Service Interceptor • Collaborative Web Services are implemented “just” by replicating the messages that are output by the Web service • This replication is provided by the event service which needs both client and service dependent information • The service specific message function is provided by an interceptor or an adaptor which takes care of issues like security, collaboration, management, service information, which message service to use • The client specific function specifies the client profile telling event service how to filter events for each client • Depending on system implementation, the interceptor is either built into web service or a wrapper provided by event service • The latter implies that all messages between clients and (all) web services are handled by event service • There are ports on the interceptor allowing specification of Collaboration Session and giving event service access to information needed for appropriate filtered (as per profile) message delivery to clients uri="http://grids.ucs.indiana.edu/ptliupages/presentations/iccsapril02" email="gcf@indiana.edu"

  48. WSDL Application orContent source Web Service Collaborative Portlets II • Collaboration is gotten by extending the WSRP Interface Collaborationas a WebService Interceptor W Control S R P PortalUser ProfileAggregateUI Fragments Client WorkflowFilterPub-Sub Event(Message)Service uri="http://grids.ucs.indiana.edu/ptliupages/presentations/iccsapril02" email="gcf@indiana.edu"

  49. WebService WebService WebService Object Viewer Object Display Collaborative Replicated Web Services I • This uses event multicast to support replicated web services Web Service InterceptorProviding General Services Set Collaboration Mode Master Object Object Viewer Object Display Event(Message)Service Object Viewer Object Display uri="http://grids.ucs.indiana.edu/ptliupages/presentations/iccsapril02" email="gcf@indiana.edu"

  50. Collaborative Replicated Web Services II • The event service now replicates the messages INPUT to the master web service (In Collaborative Web Service Access we replicated messages OUTPUT to the client) • Again we use a special “collaboration” port on the Web Service to set up links between clients • Note publish/subscribe mechanism in the events service supports the late joiners (in other collaboration models as well) • The event service can also handle messages between Web services and clients and provide the user customization service but this is not shown on previous foil uri="http://grids.ucs.indiana.edu/ptliupages/presentations/iccsapril02" email="gcf@indiana.edu"

More Related