- 18.1 PEER-TO-PEER GRIDS. - In Section 18.2, we describe the overall architecture of a P2P Grid emphasizing the role of Web services and in Section 18.3, we describe the event service appropriate for linking Web services and other resources together. - 18.2 KEY TECHNOLOGY CONCEPTS FOR P2P GRIDS. - Figure 18.1 shows a traditional Grid with a Web [Open Grid Services Architecture (OGSA)] mid- dleware mediating between clients and backend resources. - Figure 18.2 shows the same capabilities but arranged democratically as in a P2P environment. - As shown in Figure 18.3, these are linked by. - Figure 18.1 A Grid with clients accessing backend resources through middleware services.. - Integrate P2P and Grid/WS Web service interfaces. - Web service interfaces Event/. - Figure 18.2 A Peer-to-peer Grid.. - a collection of Web services [7]. - Web service (WS). - Figure 18.3 Role of Web services (WS) and XML in linkage of clients and raw resources.. - Another key concept – that of the resource – comes from the Web consortium W3C. - One can consider the URI as the barcode of the Internet – it labels everything.. - Finally, the environments of Figures 18.1 to 18.3 are built with a service model. - The resultant environment is built in terms of the composition of services.. - In Section 18.1, we described how P2P and Grid systems exhibited these services but with different trade-offs in performance, robustness and tolerance of local dynamic characteristics.. - Both P2P and Grids need messag- ing, although if you compare JXTA [8] as a typical P2P environment with a Web service–based Grid you will see important differences described in Section 18.3. - Application metadata needed to describe all stages of the scientific endeavor.. - Collaboration is described in Section 18.4 and can use a common mechanism for both P2P and Grids.. - Figure 18.3 is drawn as a classic three-tier architecture: client (at the bottom), backend resource (at the top) and multiple layers of middleware (constructed as Web services).. - Figure 18.4 Middleware Peer (MP) groups of services at the ‘edge’ of the Grid.. - Figure 18.4 redraws Figure 18.2 with Grids controlling central services, while ‘services at the edge’ are grouped into less organized ‘middleware peer groups’. - One ends up with a model shown in Figure 18.5 for managing and organizing services. - Figure 18.5 A hierarchy of Grid (Web) services with dynamic P2P groups at the leaves.. - 18.3 PEER-TO-PEER GRID EVENT SERVICE. - As shown in Figure 18.6, we see the event service as linking all parts of the system together and this can be simplified further as in Figure 18.7 – the event service is to provide the communication infrastructure needed to link resources together. - SOAP ‘just’ defines the structure of the message content in terms of an XML syntax and can be clearly used in both Grid and P2P networks. - We will see an important example of this in Section 18.4 when we discuss collaboration. - Figure 18.6 One view of system components with event service represented by central mesh.. - Figure 18.7 Simplest view of system components showing routers of event service support- ing queues.. - (P2P) Community Figure 18.8 Distributed brokers implementing event service.. - Thus, as in Figure 18.8, it is natural to employ routers or brokers whose function is to distribute messages between the raw resources, clients and servers of the system. - This will be discussed a little later as shown in Figure 18.9. - Here we note that we design our event systems to support some variant of the publish–subscribe mechanism. - Note that in Figure 18.3, we call the XML Interfaces ‘virtual’. - Less trivially, we could define a linear algebra Web service in WSDL. - Web Service 1. - Web Service 2 WSDL. - Figure 18.9 Communication model showing subservices of event service.. - We term the message queues in Figures 18.7 and 18.9 virtual to indicate that the implicit publish–subscribe mechanism can be bypassed if this agreed in the initial negotiation of communication channel. - One could build such capabilities into each Web service but this is like ‘inlining’ (more efficient but a job for the run-time compiler we mentioned above). - Figure 18.9 shows the event or message architecture, which supports communication channels between Web services that can either be direct or pass through some mechanism allowing various services on the events. - As an example, consider an audio–video-conferencing Web service [12, 13].. - The video could either be sent directly from publisher to subscriber or alternatively from publisher to Web service and then from Web service to subscriber. - as a third option, we could send it from the Web service to the client but passing it through a filter that converted one codec into another if required. - 18.4 COLLABORATION IN P2P GRIDS. - Nevertheless, we can expect that Web service inter- faces to ‘everything’ will be available and will take this point of view later where Word, a Web Page, a computer visualization or the audio–video (at say 30 frames per second) from some videoconferencing system will all be viewed as objects or resources with a known Web service interface. - today, then one must use Microsoft COM as the object model for Word but architecturally at least, this is similar to a Web service interface.. - Ports defining Web service. - Web service. - Figure 18.10 (a) Web service pipeline (flow) from originating resource(s) (objects) to display, (b) Web services can have resource-facing and user-facing ports and (c) portal as part of display. - ‘Web service’ aggregating user-facing fragments from multiple Web services.. - In order to describe a general approach to collaboration, we need to assume that every Web service has one or more ports in each of the three classes shown in Figure 18.10. - The first class is (resource- facing) input ports that supply the information needed to define the state of the Web service. - URL for a Web page or body of an e-mail message) needed to define a Web service (display Web page or browse e-mail in examples).. - If one examines an object, then there is typically some pipeline as seen in Figure 18.10 from the original object to the eventual displayed user interface. - as described above, let us assume that each stage of the pipeline is a Web service with data flowing from one to another. - Figure 18.10 shows the role of portals in this approach and we will return to this in Section 18.5. - We can identify three particularly important cases illustrated in Figures 18.11 to 18.13. - In each collaboration mode we assume there is a single ‘master’ client that ‘controls’ the Web service. - In shared display model of Figure 18.11, one shares the bitmap (vector) display and the state is maintained between the clients by transmitting (with suitable compression) the changes in the display. - Figure 18.11 Shared display collaboration.. - Figure 18.12 Shared Web services using input ports (messages).. - In the shared input port (or input message) model of Figure 18.12, one replicates the Web service to be shared with one copy for each client. - Then sharing is achieved by intercepting the pipeline before the master Web service and directing copies of the messages on each input port of the ‘master’ Web service to the replicated copies. - Here all the clients have a copy of the PowerPoint application and the presentation to be shared. - Master Web service message. - Figure 18.13 Collaborative Web services using shared user-facing ports.. - as currently shipped is not set up as a Web service with a messaging interface. - One can build a similar shared Web browser and for some browsers (such as that for SVG from Apache) one can in fact directly implement the Web service model. - The shared output port model of Figure 18.13 only involves a single Web service with user-facing ports giving a messaging interface to the client. - As in the next section and Figure 18.10, a portal could manage these user-facing ports. - Since (by definition) the user-facing ports of a Web service define the user interface, this mechanism simply gives a collaborative version of any Web service. - Of course, the replicated Web service model of Figure 18.12 offers even greater customizability as each client has the freedom to accept or reject data defining the shared Web service.. - Figures 18.12 and 18.13 point out that collaboration is itself a Web service [12, 13] with ports allowing sessions to be defined and to interact with the event service. - This collaboration Web service can support asynchronous and all modes of synchronous collaboration.. - Here we suggest that sharing either the input or the user-facing ports of a Web service allows one to build flexible environments supporting either the synchronous or the asynchronous collaboration needed to support the communities built around this infrastructure.. - 18.5 USER INTERFACES AND UNIVERSAL ACCESS. - There are several areas where the discussion of Section 18.4 is incomplete and here we clarify some user interface issues that we discuss in the context of universal accessi- bility, that is, ensuring that any Web service can be accessed by any user irrespective of their physical capability or their network/client connection. - This principle implies that the modular pipeline of Figure 18.10 is deficient in the sense that there must be a clear flow not only from the ‘basic Web service’ to the user but also back again. - This can be quite compli- cated and it is not clear how this is achieved in general as the pipeline from Web service to the user can include transformations, which are not reversible. - We can consider the output of each stage of the Web service as a ‘document. - At this stage we must assume that this problem is solved perhaps with a back channel communicating directly between the user interface and the Web service. - In any case some virtual back channel must exist that translates user interaction into an appropriate response by the Web service on the user-facing ports. - A selector in Figure 18.14 combines a user profile from the client (specified on a special profile port) with this menu to produce the ‘specification of actual user output’. - The result of the transformer may just be a handle that points to a user-facing customized output port.. - Customized user-facing output port that delivers the selected view from step 1 from the Web service to the client. - The conversion between codecs could in fact involve a general filter capability of the event service as another Web filter service as illustrated in Figure 18.7. - It seems appropriate to consider interactions with user profiles and filters as outside the original Web service as they can be defined as interacting with the message using a general logic valid for many originating Web services.. - User-facing input/output port, which is the control channel shown in Figure 18.14.. - Figure 18.14 Architecture of event service and portal to support universal access.. - Note that in Figure 18.14 we have lumped a portal (such as Jetspeed [21, 22] from Apache) as part of the ‘event service’ as it provides a general service (aggregating user interface components) for all applications (Web services). - (2002) Integration of NaradaBroker- ing and audio/video conferencing as a Web service. - Proceedings of the IASTED International. - Proceedings of the 2002 International Conference on Parallel and Distributed Pro- cessing Techniques and Applications (PDPTA http://grids.ucs.indiana.edu/ptliupages/. - To appear in the Proceedings of the 2002 International Conference on Internet Com- puting (IC http://grids.ucs.indiana.edu/ptliupages/projects/NaradaBrokering/papers/. - Proceedings of the 2002 International Conference on Internet Com- puting (IC-02), Las Vegas, USA, June http://grids.ucs.indiana.edu/ptliupages/. - Proceedings of the International Conference on Information and Knowledge Engineering , 2002, http://grids.ucs.indiana.edu:9000/slide/ptliu/research/gateway/Papers/OKCPaper.pdf.
Xem thử không khả dụng, vui lòng xem tại trang nguồn hoặc xem
Tóm tắt