Deploying the NaradaBrokering Substrate in Aiding Efficient Web ...

> Fox-Pallickara
Fox-Pallickara < encapsulating them in specialized messages, which we call events. Events can encapsulate information pertaining to transactions, data interchange, method invocations, system conditions and finally the search, discovery and subsequent sharing of resources. NaradaBrokering places no constraints either on the size, rate and scope of the interactions encapsulated within these events or the number of entities present in the system. Events encapsulate expressive power at multiple levels. Where, when and how these events reveal their expressive power is what constitutes information flow. NaradaBrokering manages this information flow. A. Broker Organization Uncontrolled broker and connection additions result in a broker network susceptible to network-partitions and devoid of any logical structure thus making the creation of efficient broker network maps (BNM) an arduous if not impossible task. The lack of this knowledge hampers the development of efficient routing strategies, which exploit the broker topology. Such systems then resort to flooding the entire broker network, forcing entities to discard events that they are not interested in. In NaradaBrokering we impose a hierarchical structure on the broker network [2,3], where a broker is part of a cluster that is part of a super-cluster, which in turn is part of a supersuper-cluster and so on. Clusters comprise strongly connected brokers with multiple links to brokers in other clusters, ensuring alternate communication routes during failures. Such a scheme ensures that the average communication pathlengths between brokers increase logarithmically with geometric increases in network size, as opposed to exponential increases in uncontrolled settings. This distributed cluster-based architecture allows NaradaBrokering to support large heterogeneous client configurations. Creation of BNMs and the detection of network partitions are easily achieved in this topology. We augment the BNM hosted at individual brokers to reflect the cost associated with traversal over connections, for e.g. intra-cluster communications are faster than inter-cluster communications. The BNM can now be used not only to compute valid paths but also for computing shortest paths. Changes to the network fabric are propagated only to those brokers that have their broker network view altered. B. Dissemination of events An event comprises of headers, content descriptors and the payload encapsulating the content. An event’s headers provide information pertaining to the type, unique identification, timestamps, dissemination traces and other quality of service (QoS) related information pertaining to the event. The content descriptors and the values these content descriptors take collectively comprise the event’s content synopsis. Entities within the system can register their interests by specifying constraints on the event’s synopsis. The destinations associated with an event are computed based on the registered interests and the event’s synopsis. In NaradaBrokering this synopsis could be based on tag-value pairs, Integers and

2 Strings. Entities can also specify SQL queries on properties contained in a specialized message. The synopses could also be XML documents, in which case XPath constraints can be specified. More recently support for regular expression queries on an event’s content synopsis. Every event has an implicit or explicit destination list, comprising entities, associated with it. The brokering system as a whole is responsible for computing broker destinations (targets) and ensuring efficient delivery to these targeted brokers en route to the intended entity(s). Events as they pass through the broker network are updated to snapshot its dissemination within, which eliminates continuous echoing. The BNM at individual brokers is used to compute best broker hops to reach target brokers. The routing is very efficient [4] since for every event, the associated targeted brokers are usually the only ones involved in disseminations. Furthermore, every broker, either targeted or en route to one, computes the shortest path to reach target destinations while eschewing links and brokers that have failed or have been failure-suspected. 1)

Profiling the matching engines The matching engine is responsible for computing destinations associated with an event based on the profiles available at a node. Depending on the type of applications, standards, events and subscriptions that need to be supported there would be multiple matching engines residing within every processing broker node. We now provide some results pertaining to the matching engines residing in brokers within NaradaBrokering. These results are for stand-alone processes, where we computed the matching times as a function of the number of subscriptions maintained. In each case, an event is matched to retrieve every matching subscription. For every matching engine, the number of subscriptions is varied from 10,000 to 100,000. The results were measured on a machine (1GHz,256MB RAM) running the process in a Java-1.4 Sun VM with a high-resolution timer for computing delays. The richer the constraints, the greater the CPU-cost associated with the matching process. As can be seen the average delays for matching increases progressively (String to SQL to XPath in that order) as the complexity of the matching increases. For String based matching, as depicted in Figure 1, the average delay for matching subscriptions generally increases as the size of the topic String increases. The increase in delays for matching as the topic String size doubled from 16 to 32 was in the range of 1 microsecond. The results demonstrate that it is feasible to have real time interactions that are based on the simple String constraints. Figure 2 contrasts the costs involved in matching JMS events to stored SQL-92 based selectors on the properties contained within the JMS message and XML events to stored XPath conforming constraints. Of course these costs can vary significantly depending on the type of the query. For our experiments we used XPath and SQL queries, which we felt were comparable. The cost of a single matching operation involving an XML event and an accompanying XPath query is around 3 milliseconds.

> Fox-Pallickara
Fox-Pallickara
Fox-Pallickara
1 GB) into smaller fragments and publish fragmented events. Upon reliable delivery at the server-proxy, NaradaBrokering reconstructs original payload from the fragments and delivers it to the GridFTP server.

0

Standard deviation for Content Payloads (3 broker network). NB-Best Effort(TCP) Versus NB-Reliable Delivery(UDP) 3.5 NB-Reliable (UDP) NB-Best Effort (TCP) 3 2.5

Time and Buffering Services The substrate also includes an implementation of the Network Time Protocol (NTP). The NaradaBrokering TimeService [7] allows NaradaBrokering processes (brokers and entities alike) to synchronize their timestamps using the NTO algorithm with multiple time sources (usually having access to atomic time clocks) provided by various organizations, like NIST and USNO. The NaradaBrokering time service plays an important role in collaborative environments and can be used to time order events from disparate sources. The substrate includes a buffering service which can be used to buffer replays from multiple sources, time order these events and then proceed to release them.

2

4)

1.5 1 0.5

0

1000 2000 3000 4000 5000 6000 7000 8000 900010000 Content Payload Size in Bytes Figure 8: Standard Deviation comparison (3 brokers)

In the reliable delivery case there is an overhead of 4-6 milliseconds (depending on payload size) associated with the archival of the event, with an additional variable delay of 0-2 milliseconds due to wait()-notify() statements in the thread which triggers archival. These factors, in addition to retransmissions (NAKs) triggered by the subscribing entity due to lost packets, contributed to higher delays and higher standard deviations in the reliable delivery case. It should be noted that we can easily have an optimistic delivery scheme which does not wait for archival notifications prior to delivery. This scheme would then produce overheads similar to the best effort case.

D.

The transport framework NaradaBrokering incorporates an extensible transport framework [20] and virtualizes the channels over which entities interact with each other. Entities are thus free to communicate across firewalls, proxies and NAT boundaries which can prevent interactions from taking place. Furthermore, NaradaBrokering provides support for multiple transport protocols such as TCP (blocking and non-blocking), UDP, SSL, HTTP and RTP. The typical delays involved with NaradaBrokering’s transport framework in LAN settings is around a 1 millisecond. Additional information regarding measurements within the transport framework can be found in Ref [8].

2)

Mean transit delay (Milliseconds)

Dealing with large payload sizes: Compression/Fragmentation To deal with events with large payloads, NaradaBrokering provides services for compressing and decompressing these payloads. Additionally there is also a fragmentation service which fragments large file-based payloads into smaller ones. A coalescing service then merges these fragments into the large file at the receiver side. This capability in tandem with the reliable delivery service was used to augment GridFTP to provide reliable delivery of large files across failures and prolonged disconnects. The recoveries and retransmissions involved in this application are very precise. Additional details can be found in Ref [6].

Performance Monitoring Services Connections originating from a broker are tracked by a monitoring service. The factors measured on individual links include loss rates, standard deviations and jitters. This can then be used to augment the weights associated with edges in the BNMs to facilitate real-time responses, by the routing algorithms, to changing network conditions.

400

Transit delays for Content Payloads. Brokers at Cardiff and UCL, Clients at Indiana Delay

350 300 250 200 150 100 100

1000 Content Payload Size in Bytes

10000

Figure 9: Transit delay for message samples (UCL, Cardiff and IU)

Standard Deviation (Milliseconds)

> Fox-Pallickara
Fox-Pallickara < A. Grid Services and Web Services It should be noted that more recently there has been an effort to factor the OGSI [11] functionality to comprise a set of independent Web service standards. These specifications align OGSI with the consensus emerging from the Web Services Architecture working group of the World Wide Web Consortium. The specifications that comprise the new proposed framework – the WS-Resource Framework (WSRF) [12] – leverages, and can leverage, specifications in the Web Services area such as, but not limited to, authentication, transactions, reliable messaging and addressing among others. WSRF specification also includes WS-Notification [13] which abstracts notifications using a topic based publish/subscribe mechanism. Work is presently underway to provide support for WS-Notification within NaradaBrokering and a prototype version will be part of a release scheduled for May 2004. Throughout our discussions when we refer to services as Web Services the term refers to services that are parts of the Service Oriented Architecture, and includes both Web Services and Grid Services (which is also a Web Service). The strategies that we discuss through this paper are thus applicable to both the domains – traditional business oriented Web Services and the science/traditionally-academia oriented Grid Services architecture. Thus the discussion on load balancing service instances (in a section 5) would be valid for managing stateful resources exposed using the WS-Resource specification.

IV. APPROACHES TO INTERACTING WITH WEB SERVICES In this section we describe approaches to incorporating support for Web Services within the NaradaBrokering substrate. The first involves using a NaradaBrokering-proxy that acts as an interface between services and the messaging substrate. The second approach provides an end-point NaradaBrokering “plug-in” that can be used by a Web Service to provide direct connectivity to the NaradaBrokering network. Since the plug-in resides as a handler within the handler-chain associated with the SOAP processing stack at a service endpoint, no changes are needed to either the service implementations or the service requestors. This involves a one-time effort of writing NaradaBrokering handlers for SOAP implementations in different languages such as Apache Axis (such a handler can be used with Sun’s JAX-RPC with no changes), gSOAP and Soap::Lite. It should be noted that the schemes outlined in the earlier section, using either the proxy approach or processing based on SOAP messaging, should be able to interoperate with each other. A. Proxy Approach This approach is based on SOAP and involves using the proxy architecture to deploy Web Services within the system. Here a client’s service invocation, contained in a SOAP message, is intercepted by the proxy. This SOAP message is then encapsulated in a native NaradaBrokering event and the substrate routes it to the proxy associated with the service

7 instance. This proxy then recreates the SOAP message from the native NaradaBrokering event and forwards the SOAP message to the Web Service. Faults and responses generated by the Web Service are routed back using the same principles which govern the invocation scheme. This approach is a simple one and the costs (specifically network cycles) associated with the additional proxy redirect can be alleviated by collocating the proxy on the same machine as the client and server. This approach has two clear advantages –1. It requires no change to either the original service or the container hosting that service 2. It can be used to facilitate interactions between generic services (perhaps a non WS approach such as IIOP or native Java) and services based on Web Service standards. This solution however was application dependent and the proxy had to be rewritten or tweaked for different applications. Also, since only the proxies were interacting with the substrate all the guarantees/services provided by the substrate were accessible only to these proxies and not to the web service client/service. B. Incorporating SOAP processing into the substrate Incorporating SOAP processing into the substrate eliminates the need to interact with the substrate via a proxy. This is a very useful feature which will eventually allow Web Services to interact directly with the substrate. To achieve this interaction with SOAP services we need to address two issues. First, pertains to the ability to use NaradaBrokering as a transport mechanism for SOAP messages. Second, to interact directly with Web Services the substrate should be able to function as a SOAP intermediary. This would allow messages to be redirected into the substrate for specialized processing. 1)

A transport mechanism for SOAP messages Here we use NaradaBrokering as a transport (depicted in Figure 11 ) for SOAP messages, which have traditionally been sent over HTTP. There are examples of different protocols that have been used. The Apache AXIS project for example has HTTP, SMTP/POP3, Java-RMI and JMS as registered transports. The substrate facilitates communications over a variety of transports, each with different properties. Depending on the SOAP message being issued (large attachments etc) appropriate lower-level transport would be used for routing the SOAP messages. The SOAP messaging would either be based on request/response semantics inherent in RPC-style service invocations or they could be based on asynchronous one-way messaging. In the asynchronous style of messaging, a lookup service locates the appropriate providers that had previously registered with a naming service. This is the precursor to sending SOAP messages. A related issue is that of binding it to a protocol stack so that clients can communicate with the service endpoint using the specified port and address.

> Fox-Pallickara
Fox-Pallickara < generate a fault (messageUnderstand set to 1) or ignore (messageUnderstand if it is not 1) the targeted header that it does not understand. This attribute can be used to impose constraints on the processing of certain header elements. Finally, it must be noted that the substrate can interact with SOAP intermediaries that are not native NaradaBrokering services or for that matter even services that are directly hosted on the substrate.

query’s propagation might take place, thus allowing individual entities to control how localized their services can be. Minute Maid Apple Brazil Coca Cola 2.90 2003

Use of WS-Routing to facilitate static paths

The one disadvantage of the actor attribute is that at a time it is possible to specify only one actor element since the order cannot be determined if multiple intermediaries are specified. This issue can be handled by using WS-Routing [15] which allows us to specify the route a SOAP message will take using the via directive. For reverse paths, (rev) the path is constructed as the event traverses through the forward path. This is sometimes used for request/response semantics such as Web Service invocations but does not seem necessary for most cases. WS-Routing allows us to do without specifying the reverse path.

V. COMPLEMENTING SERVICE INTERACTIONS In this section we identify areas such as discovery and load balancing where the substrate can provide additional functionality to the hosted services. These services are a precursor to a system where the substrate can compose services from discovered constituent services each of which would be chosen from a set comprising multiple instances. The substrate then needs to rely on its capabilities to ensure robust delivery to ensure that a task involving coordinated processing between multiple services (identified based on the task specification) is completed in the presence of failures. The substrate’s capability to provide order also ensures that the invocations/interactions are consistent. Furthermore, the substrate can also be used to cache the results from prior interactions to optimize service utilizations. A. Discovering services using advertisements SOAP handlers can automatically generate service advertisements on service startup. Web Services connect directly to NaradaBrokering and expose their capabilities through advertisements. The substrate supports a wide variety of querying schemes such as XPath queries, SQL queries (through JMS), Regular expressions and simple string matching. One or more of these will be used to support querying of services hosted on the substrate. Entities in the system can advertise their services in an XML schema. These advertisements would be stored in the same way that the profiles are stored within the system. Events propagated by interested clients would essentially be either XPath or Regular expressions-like queries. These events would then be matched against the stored advertisements with the matching ones being routed back to the initiating client. The query events can specify the realms within which the

XPath Query type: /menu/softdrinks[price>1.80] Figure 13: The XML event and XPath query type

Timing results for matching an XPath query to stored XML events 12000

Matching Time

10000

Delay (Milliseconds)

c)

9

8000 6000 4000 2000 0

1

2 3 4 5 6 7 8 9 10 Number of stored XML-events (in thousands) being matched

Figure 14: Matching an XPath query to stored XML events

Figure 14 depicts the matching times for a query against a set of stored XML events/advertisements. For matching XML advertisements, the performance would vary if it is constrained by the number of matched advertisements or stored XML events that need to be included in the query response. The stored XML events (this could of course be a WSDL service advertisement) and the issued XPath query are of the type depicted in Figure 13. For most discovery related operations, similar to those initiated in P2P systems, these numbers indicate adequate performance. When we receive SOAP messages destined to services (either as requests or responses from other services), we use both the advertisements and the directives specified in the SOAP header elements to determine the route for these messages as well as any special processing (compression, archival, signing, credential delegation etc) that might be needed by these messages. B. Using Handlers Special handlers will be associated with service endpoints so that the substrate can interact with these services. These handlers can then be grouped into a handler chain, and can be inserted in the processing path of either the service requestor, service implementation or both. Depending on the configuration of the handler, these handlers will process control messages initiated by the substrate such as heart-beats,

> Fox-Pallickara < latency measurements and utilization counters among others to facilitate efficient utilization of the resource. It must be noted that these messages need not propagate the entire handler chain. In the case of clients/services invoking other services the handler chain would add headers to enable easier processing within the substrate. In the absence of the handler approach headers pertaining to the value added services would need to be processed within the application logic. This would entail serious rewrites to the application logic and in some cases the complexity of rewrites would ensure that the feature is rejected as a tradeoff. This would also imply that every application would need to be rewritten for every feature. Furthermore, the application would need to be rewritten, retested and redeployed every time there is a change to the value added service. There are several advantages to using the handler approach. First, it facilitates incremental addition of value added functionality to an existing service. This functionality can easily be reused by other services, tested independently of the application logic. Second, it can be used to ensure that enhanced services continue to interoperate with existing services. Handlers within a handler chain can add, remove, process or ignore headers pertaining to incremental functionality. A handler can those choose not to generate faults for messages that arrive without functionality-specific information, thus enabling interaction with services that do not have the requisite handler to generate that information. The handler can in the same vein be used to impose constraints on services that communicate with it. For example in the face of a coordinate distributed denial-of-service attack a handler (or handlers) – which performs packet inspection, checks authentication information and checks from messages from malicious hosts – can be set up to impose new policy and constraints in an easy incremental fashion.

Figure 15: SOAP handler chains and the substrate

The scheme thus allows Web Services to interact directly with the substrate (depicted in Figure 15). Hosted services can utilize substrate properties such as resilience, load balancing etc through the incorporation of the appropriate handlers in the handler chain. It should be noted that the service implementations will not change. We can write these handlers (a one time effort) for gSOAP, SOAP::Lite, AXIS and JAXRPC. This would allow us to communicate with messages issued using gSOAP, SOAP::Lite and Axis SOAP.

10 C. Ability to load balance services Load balancing algorithms operate on the ability to keep track of the number of active service instances as well as the load on these instances. In the substrate this is done by exchanging information with the instances at regular instances. In addition to this substrate also facilitates schemes where an instance may choose not to respond to the discovery request initiated by an entity. This decision is of course predicated on the contents of the discovery request as well as the load at the resource in question. Finally, the substrate also uses round-trip delays from an entity to the replicated resources in question to compute the network distance separating the entity from the resource instance. The resource selection scheme in the substrate utilizes both the usage metric at a resource and the network distance to arrive at a decision regarding the resource to use. To facilitate the same scheme for services, handlers would be registered with the handler chain associated with both the service requestors and the service implementations. These handlers would perform functions such as –• Constructing usage metric: This handler would construct usage metric at a node based on the number of requests processed, the rate of requests and the volume of information transferred. Additionally, this handler would also construct profiles regarding the underlying hardware hosting it – CPU performance, available memory and cache size. • Creating round trip delay request and responses: This handler would facilitate the creation of round trip delay requests, responses and finally calculation of delay based on the response. • Creating heart-beat monitors: This handler would send out heart beats at regular intervals so that the substrate can continue to track its availability. It should be noted that services augmented with this functionality can still continue to interact with services and requestors that do not posses the requisite handlers. Under such circumstances both the service requestor and the service instance involved in the interactions will not have access to certain substrate capabilities. For example, even though a requestor does not have the appropriate handler the substrate will locate the right service; however this service instance might not be the one that it is closest to. D. The role of WS-Addressing WS-Addressing [16] is a way to abstract from the underlying transport infrastructures the messaging needs of an application. The substrate sitting at an organization's boundary could use WS-Addressing for making runtime decisions on where a message arriving from the outside world should be delivered within the infrastructure. Finally we could use WSAddressing for endpoint references to deal with dynamic usage patterns involving WSDL Service descriptions. WSAddressing is used in this scenario to facilitate the identification and specification of service instances for services that would generated dynamically besides enabling exchange of endpoint information.

> Fox-Pallickara
Fox-Pallickara
Fox-Pallickara