DEN and XSUL

XSUL is a modular Java Library to construct Web and Grid Services [33, 34]. It has been developed by Extreme Lab at Indiana University. It provides a framework for XML based processing and supports doc-literal, request-response and one-way messaging. Furthermore, it contains modules for a lightweight XML/HTTP invoker and processor. It also supports SOAP 1.1/1.2 and digital signatures. Moreover, it has an ability to provide dynamic service invocation.

DEN addresses the performance and scalability bottleneck [35]. It targets directly to the Web Service Security Processing steps without touching the Service logic at all. It granulates the application and makes the pieces separate processing nodes. These nodes are distributed across the Grids. It is able to execute these processing nodes concurrently. They must be independent entities to be executable parallel, though. The whole scenario is depicted in Figure 2-9.

34

The latest version of XSUL, XSUL2, allows a request goes through a chain of handlers until it reaches the destination. DEN by utilizing XSUL2 is able to separate the handlers from Web Service endpoint and distribute them as individual service nodes within a chain. The service nodes use a context to convey supplementary information for. A context stores intermediate processing results for the nodes. It is passed inside of the SOAP header through the handler chain.

Design of DEN is not restricted with only SOAP style Web Service interactions. It also utilizes generic HTTP commands such as GET. Moreover, XSUL2 offers an environment to benefit Web Service Definition Language (WSDL) by using GET command. P1 _Pt-1 P1 P1 Pt-1 Pt-1 WSD Gateway Web Service Logic Grids and its services with replications

Figure 2-9 : DEN: WS Processing in Grids

Additionally, DEN utilizes a table, a hash table with registered service names as keys and endpoint vectors as values, for the routing purpose. Endpoint vectors contain at least one reference. These vectors are bounded with either intermediary processing nodes or final destination of the interaction.

DEN and XSUL is able to utilize asynchronous messaging by using WS- Dispatcher. The dispatcher allows internal services to be exposed to Internet. With the

35

support of asynchronous messaging, a WS-Security implementation is divided into sub- atomic tasks and deployed as services. Some tasks are executed in a parallel manner to gain performance and to remove the bottleneck.

2.1.4.1 Differences

The differences can be categorized into two: conceptual and architectural differences. DEN and XSUL distribute handlers as Web Services. Each handler utilizes a WSDL to broadcast information about how to be communicated. On the other hand, DHArch keeps the status of handlers unchanged; they architecturally remain as handlers. The distributed handlers in DHArch do not prefer utilizing a WSDL to be communicated even though it is possible to do so. DHArch prefers using the handler interfaces of the underlying containers and its customized handler interfaces. Hence, a currently implemented handler can be easily deployable without any modifications.

The conceptual differences let the architectures evolve into different directions. Since DEN and XSUL exploit Web Service Framework to deploy handlers, it makes use of HTTP protocol for communication purposes. The handlers are orchestrated by using a routing table. In contrast, DHArch utilizes a MOM to provide communication between the distributed handlers. On the top of this communication mechanism, an orchestration module organizes the distributed handler execution.

In short, even though some common issues originated from the utilization of the additive functionalities are targeted, the approaches differ conceptually and architecturally. Section 2.1.4 and CHAPTER 3 provide the architectural details of DEN+XSUL and DHArch respectively. We will look at the strong points and advantages of these approaches in the following section.

36

2.1.4.2 Strong points and advantages

DEN and XSUL together target directly to the Web Service security processing steps without touching the Service logic at all. They tear and granulate the security processing node and deploy the security tasks as individual services. This approach sets an example to distribute the handlers as Web Services.

Utilizing Web Service approach for the handlers provides several benefits. The first benefit is to be able to remove bottlenecks from the SOAP processing pipeline with a very well-known style. Additionally, service based approach improves the interoperability of the deployment. Moreover, this approach is able to utilize the tools that have been already implemented for the Web Services. For instance, many service level orchestration tools can be easily utilized. On the other hand, DHArch follows a different approach to provide a scalable, efficient and modular environment for the handlers. It is basically a distributed Web Service Handler Container. It also removes the bottlenecks from SOAP processing pipeline by using additional resources and providing an environment for the concurrent execution. Additionally, DHArch is able utilizes a Message Oriented Middleware (MOM) for the transportation purpose. MOM is a powerful tool to provide asynchronous, reliable, efficient delivery mechanism. In addition to excellent messaging capability, it can provide a queuing mechanism for the handler execution to regulate the message flow.

Furthermore, DHArch has its own handler orchestration mechanisms. The orchestration separates the description from the execution. This allows having a very simple and efficient execution structure while offering a very powerful expressiveness for the orchestration.

37

Moreover, DHArch provides a control mechanism for the pipelined message executions. The number of executable messages is kept in optimum level to prevent the performance degradation because of too many messages processing in a moment.

DHArch utilizes a context that allows a message based execution. Every message may have an individual handler execution sequence; DHArch may employ a different handler execution sequence for each message. It is not centralized. Instead, the sequence that is kept in the context may differ from message to message.

While we were deciding about the best way of carrying the data to the distributed handlers, we conclude that having a format which wraps the SOAP message and additional data is more efficient. The whole SOAP message does not have to be parsed in order to get necessary information to carry out the distributed execution. The format should be simple but not have any deficiency. Hence, the specific messaging format, agreed between the computing nodes, is created.