GRIMOIRES doing funny things

As I mentioned in my past two posts, that I have been trying to use GRIMOIRES as the registry in my dynamic deployment work. The idea is that when a service is deployed on a node, it will be registered with the GRIMOIRES registry, which is the basic concept of UDDI. What we are trying to add is a dynamic deployment feature, where the Service Provider will advertise a set of services, which may or may not be deployed somewhere. The flow is as follows:

A consumer contacts the Service Provider (SP) and finds the services that are supported by the SP. The consumer then decides which service is to be invoked, and sends a request message (SOAP) to the SP. The SP looks up the registry and finds out on which nodes this service is already deployed. If such a node is found, the request is forwarded to that node and on completion, the response is sent back to the consumer. But, if there are no nodes on which the service is already deployed, the SP sends a message to a suitable host to deploy this service dynamically. In this message, the SP provides the service name/ID and the location where the deployment code can be found. In the DynaSOAr work, we have already developed this infrastructure (except the registry), where the deployable code can be fetched from a code-store (which is again a service). I am now trying to develop a registry, and that is where GRIMOIRES comes in. I could have developed a simple MySQL-based utility to store all the information required in the MySQL backend, but then it defies the purpose of UDDI.

So, I need to add "businessEntities" and "businessServices" to the GRIMOIRES registry. The services would have more than one bindingTemplates - because a service can be deployed on more than one nodes. Each service should also have a reference to the Code-Store URL, from where the service code can be fetched during hot-deployment. UDDI specs allow more than one bindingTemplates and there is a concept of tModels, which can be used for reference purposes - which eactly suits the requirement for the reference to the Code-Store. This is what I tried to do. Adding a businessEntity and a businessService din not prove to be difficult at all. But the problem cropped up when I added the bindingTemplate, more specifically more than one of those. It seems GRIMOIRES creates duplicate entries while doing this via the UDDIBrowser. So, once I add a bindingTemplate to a service, the registry is updated, and when the businessEntity (under which the businessService is created) is expanded, multiple copies of the same entry is displayed (using UDDIBrowser). But, funnily, if a query is sent to the registry (via the same UDDIBrowser) inquiry interface, it returns the correct number of services...I suspect it sends a "select distinct"-like query to the database.

Other than this, I think I am comfortable with the tModel concept for CodeStore. So, each of the services registered with the registry will have multiple bindingTemplates, and one tModel reference. I have created a tModel as follows:

<tmodel tmodelkey="some tModel key - uuid">
<name>CodeStoreLocation</name>
<description lang="en">some description</description>
<overviewdoc>
 <overviewurl>http://codestore.url</overviewurl>
</overviewdoc>
</tmodel>

And I am using this as a reference within the businessServices - as categoryBag entries.

<businessService
businessKey="544d3b47-c908-449a-9f2d-8f5c4f69fa9e"
serviceKey="cdb0c903-839b-4a74-ae1d-c3981e55e27a">
<name>QueryEvaluationService</name>
<bindingTemplates>
 <bindingTemplate
   bindingKey="c8cdc9a5-f070-4e16-9e09-f78b3842f9c3"
   serviceKey="cdb0c903-839b-4a74-ae1d-c3981e55e27a">
   <accessPoint URLType="http">serviceURL</accessPoint>
   <tModelInstanceDetails>
     <tModelInstanceInfo tModelKey="some key"/>
   </tModelInstanceDetails>
 </bindingTemplate>
 <bindingTemplate
   bindingKey="ca8d1c0e-9312-4b92-9d80-edb7c247a813"
   serviceKey="cdb0c903-839b-4a74-ae1d-c3981e55e27a">
   <accessPoint URLType="http">service URL</accessPoint>
   <tModelInstanceDetails>
     <tModelInstanceInfo tModelKey="some key"/>
   </tModelInstanceDetails>
 </bindingTemplate>
</bindingTemplates>
<categoryBag>
 <keyedReference
   keyName="CodeStoreLocation"
   keyValue="http://codestore.is.somewhere"
   tModelKey="dqp:uk.org.ogsadai:codestore:location"/>
</categoryBag>
</businessService>

I guess this should work...

UDDI Registry And tModels

For the past few days I have been scratching my head on how to describe the services that I will put in the DynaSOAr registry for the dynamic distributed query processing work. I have been exploring GRIMOIRES as a possible option. It provides a GShell interface to interact with the registry and alternatively the UDDIBrowser can be used to browse the contents and publish/query entries in the registry. Unfortunately, UDDIBrowser contains minimal (rather no) documentation which led to several problems in publishing new entries, especially tModels. A google search led me to this article on tModels - I found it quite useful. I have a clearer idea on describing the services to be exposed by the registry - specially, identifying the code store repository from where the service code can be fetched in case of dynamic deployment, and also information about the service or the virtual machine image...

I still have problems with GRIMOIRES, which I think is possibly a bug in the UDDI server - because similar steps against jUDDI were successful.

Thoughts about OGSA-DQP and DynaSOAr

We have just released OGSA-DQP 3.0. The previous two releases received fair amount of positive feedback from the community, and we hope this new release will have similar fate. DQP-3.0 is based on OGSA-DAI WSRF 2.1 and OGSA-DAI WSI 2.1. This release contains major bug-fixes, performance enhancements and most importantly, it allows the co-ordinator component to be deployed on Windows. Now I will be able to concentrate on my research – hoping to be able to start writing my thesis sometime next summer.

So, what am I trying to achieve?

In the past few months, we have also produced a Dynamic Service Oriented Architecture framework, called DynaSOAr. It provides an architecture for dynamically deploying web services remotely on a grid or the Internet. When a web service provider receives a request for a web service, it checks to see if this web service is already deployed. If it is, the call is routed straight to the deployed web service. If the web service is not deployed, the web service code is fetched from a repository and the web service is deployed on a host provider under the service provider's domain. One potential use for this architecture is for moving web services which access a database and perform analysis on the data closer to the database.

I am trying to use this idea of DynaSOAr inside OGSA-DQP by allowing dynamic deployment of the query evaluation component of DQP (called evaluator) on target hosts, dynamic deployment of analysis services, and also packaged virtual machines containing services or databases.

The evaluators are already compatible with DynaSOAr. I have also been able to create Virtual Machines using VMWare Workstation, start them on Linux hosts from a suspended state using the VMWare Player, and invoke services on them. The challenge is in transporting those VMs on the fly to and from different hosts, for which I am planning to explore several technologies like GridFTP, Peer-to-peer, etc.

Right now, I am fiddling with GRIMOIRES, a UDDI registry released by the University of Southampton. I’m planning to use it within the dynamically deployabale version of DQP. This registry will store information about the services, where they are deployed, and from where the service code can be found in case a hot-deployment is required…

Data and SOA

I just finished reading an excellent article on Service Orientation. It’s written by Pat Helland (from Microsoft), and titled – "Data on the Outside vs. Data on the Inside". Pat explores the concepts of Service Orientation, and talks about how data should be structured within the service and outside the service boundary – which has always been an interesting topic since the advent of Web Services…

Devonshire Building

This is the Devonshire Building where I work. The building is "supposedly" environment friendly, although you would see lots of screw-ups frequently, and sometimes I feel that the building looks like a huge toaster. But, what the hell, this building is quite famous now:-))

The building houses several research groups, and we are on the second floor with the Informatics Research Institute sharing the floor with us. We even have a state-of-the-art VR (Virtual Reality) suite for the VR and Imaging research...