| The OGSI, as we have already noted, provides a rich and robust infrastructure for the implementation of Grid Computing environments. This section addresses the .NET solutions, in conjunction with the OGSI. Architecture Overview The concept of the .NET framework is centered on the service instance requirements for the management between the client invocations, and using the Internet Information Server (IIS) to dispatch the client request to the actual instance. Although .NET provides a rich set of Web services capabilities, the evidence of these two basic requirements for a grid service being apparent is somewhat less than remarkable . To satisfy these requirements, the OGSI.NET team must construct the architecture to maintain the service instances between the client invocations, and the ability to then dispatch the requests to the correct service instances. The architecture suggests the introduction of a concept of grid service wrappers and a dispatcher. These are .NET AppDomains, self-contained entities that can execute objects in its own memory space. This concept provides a number of advantages including scope the code execution, fault isolation, and security isolation. The grid service wrappers (GSW) are OGSI grid service instances that are created in its own AppDomain. The dispatcher is the pivot AppDomain that contains references to the grid service wrapper objects in another AppDomain and executes methods upon it. This concept of creating grid services using wrappers with AppDomain isolation provides security, memory, and code isolation. Any problem (fault or exceptions) with the specific service may not affect other services in the same container. Yet another important functionality of these wrappers is that they are self-contained with the necessary serializer, deserializers, and portType implementations required for the service operation dispatch. Another important architectural decision is the extension of the request dispatching functionalities of the IIS. A client request is filtered by the OGSI.NET ISAPI (Internet Server API) filter. This filter intercepts the client requests, then rewrites the request and dispatches this request to the HttpHandler provided by the OGSI.NET framework. This Http handler routes the messages to the OGSI.NET container process. This process, in turn , handles this raw message in one of its threads. The Dispatcher AppDomain takes over the raw request message in the thread and this dispatcher routes the messages to the GridServiceWrapper class for further processing. This dispatching is done based on the instance URL. The above request processing is illustrated in Figure 15.1. Figure 15.1. The OGSI.NET architecture and request flow.  Let us now spend some time analyzing the internal functionalities of the GridServiceWrapper. This wrapper is running in its own AppDomain. It maintains a list of portTypes implemented by the service and contains the necessary information to serialize and deserialize the SOAP messages coming from the client. The framework also provides capabilities to plug in message handlers for SOAP message header processing. The standard SOAP-based headers (for example, WS-Security) are processed using the Web service Enhancement (WSE) handlers. [3] Once the message is deserialized and the operation is identified from the raw SOAP message, a runtime reflection is executed on the service to invoke the operation. The responses from the method invocations are serialized and sent back to the client. The discussion topics below on the architectural components helps us to better address an improved programming model. Dispatcher The main function of the Dispatcher AppDomain is to route the request from the client to the appropriate service instance and return the results to the client without any processing. It keeps a list of URIs to the service instance for proper instance dispatching. This architecture helps to isolate the security and other runtime problems to an isolation level of service instance AppDomain. Grid Service Wrapper This is a wrapper executing in its own AppDomain and providing functionalities, such as: -
Pluggable, service-specific message handlers to process messages prior to dispatching to the service instance -
Mechanism to specify portTypes similar to OperationProviders in GT3 -
Pluggable implementations for system-defined portTypes -
Built-in support of extended standard-based SOAP headers using WSE The wrapper is initialized with the necessary assemblies needed for the service as specified by the service class. This includes portType implementations, serializers, deserializers, and message handlers. One important thing to notice is that the complete processing of the message is accomplished on the thread provided by the container. So if the service needs to create more threads it must create the .NET-provided soft threads in the AppDomain using the .NET-provided System.Threading.Thread class. Factory Factories are service instances that can create other service instances and wrappers in different AppDomains. They implement OGSI Factory portType with createService operation. These service instance wrappers are remote referable objects of the type MarshalByRefObject and stored in the Dispatcher AppDomain. The Dispatcher stores these objects in a table with service instance handle (GSH) as the key. Message Handlers OGSI.NET provides two message handlers, one for SOAP messages and the other for .NET "remoting" message formats. We will see how we can configure these handles later in the configuration section. These message handlers will deserialize the request message and identify the operation to invoke and create the needed parameters from SOAP body. On the completion of the call, the client serializes the message to byte stream and returns the binary stream back to client. The current runtime uses the Microsoft WSE pipeline mechanism to process the standard defined SOAP headers such as WS-Security and WS-Addressing. For application specific headers we must provide custom handlers. Security The message-level security is handled using WS-Security and the WSE extensions for WS-Security. One thing to notice is that this is handled in the service instance wrapper domain. The concept of wrapping service instance in an AppDomain provides security, memory protection, and other .NET protections including code access, assembly access, and so forth. Persistence The framework provides a soft state service destruction pattern as defined by OSGI specification. This enables a service client to define a lifecycle time for a service instance. There is a garbage collector thread running with the dispatcher AppDomain, which is responsible for this service destruction on timeouts. Programming Model Now let us discuss the programming model constructs provided with this framework. One noticeable feature of this framework is its alignment with the .NET programming model for Web services. The use of "attributes" in service class is one such interesting aspect of the programming model. Attribute-Based Programming One of the most attractive and powerful features in .NET is the attribute-based programming. This feature is used to annotate the classes, methods, and code blocks with metadata. This language feature is extensively used in .NET to support Web services. OGSI.NET uses this facility to define some commonly defined attributes for grid services to help the service developer form the inner details of the implementations. OGSIPortTypeAttribute This tells the GSW that the service implements a particular portType. NotificationSourcePortType This service implements a NotificationSourcePortType functionality as defined by the OGSI OGSIOperationOverrideAttribute. This enables a service author to override some of the portType methods using OGSIPortTypeAttribute, OGSISoapHeaderAttribute, and OGSIRemotingHeaderAttribute. These attributes provide additional header information to these operations. This is a replacement for the .NET SoapHeaderAttribute, which provides no type information, as shown below: [OGSISoapHeader("invocationID", "http://ogsa.globus.org/", typeof(InvocationID))] versus [SoapHeader("invocationID")] Listing 15.1 illustrates the use of attributes in a service class. Listing 15.1. A sample attribute-based programming for OGSI. [OGSIPortType(typeof(GridServicePortType))] [OGSIPortType(typeof(NotificationSourcePortType))] public class AcmeService : GridServiceSkeleton{ } Listing 15.1 specifies that Acme Service is implementing the GridServicePortType and NotificationSourcePortType. Configuration Let us now move on to the configuration of a service. We can best explain the configuration process through Listing 15.2. Listing 15.2. The grid service configuration. <service name="ph/acme/AcmeSearchFactoryService"> <parameter name="schemaPath" value="schema/core/factory factory_service.wsdl"/> <parameter name="class" value="ph.acme.Factory.AcmeSearchFactoryService, ph_acme.dll"/> <parameter name="messageHandlers" value="UVa.Grid.SoapMessageHandlerLib.SoapMessageHandler, SoapMessageHandlerLib.dll; UVa.Grid.SoapMessageHandlerLib.RemotingMessageHandler, SoapMessageHandlerLib.dll"/> <parameter name="createSchemaPath" value="schema/gridbook/base/ acme_search_service.wsdl"/> <parameter name="createClass" value="ph.acme.basic.impl.AcmeSearchService, ph_acme.dll"/> <parameter name="createMessageHandlers" value="UVa.Grid.SoapMessageHandlerLib.SoapMessageHandler, SoapMessageHandlerLib.dll; UVa.Grid.SoapMessageHandlerLib.RemotingMessageHandler, SoapMessageHandlerLib.dll"/> </service> Upon careful examination of the above grid service configuration, we could infer that: -
Every service factory has a unique name and uses the OGSI-defined factory _service.wsdl. -
The real implementation factory class is defined using the "class" parameter, which accepts the class name and the assembly name. -
A list of handlers for the service factory is specified in the "messageHandlers" property. -
The service must provide its wsdl and class name using createSchemaPath and createClass parameters, respectively. -
A list of handlers for the service instance is specified in the "createMessageHandlers" property. | 