Thursday, December 28, 2006

Service Aggregation (In Fada/Servent)

Inspired by one of the examples (Aggregation) available on swallow cvs, the following code example/tutorial shows how we can search for services on the P2P based on their FADA entries. The FADA entries are usually the SMID or Service Manifest ID.

For simplicity, the examples have a simplified HelloWorld service that uses straight POJOs than do not use xmlrpc holders like in the other previous examples.

On the example 2 services are deployed which implement the same interface, and are published with the same SMID.

Once the services are published (done identically to the previous tutorials where we execute the included deploy.sh), we can inspect the Items registered in our local FADA node. The figure above illustrates the Items in our node with the one of the Entries (the SMID) equal to "SampleAggregator".

With this information and the java class interface, we can then lauch an search to find services that interface and that has Entries. This is achieved with the following code:


Our method receives a String Array of SMIDs (only one in our example) and uses that and the class signature to search for suitable services. The search is a boolean search (1 or 0) in the sense that only returns services that exactly match our query*.

In our example, we simple execute a remote method that retrieves the endpoint of the service. The figure below illustrates the output results once the services are deployed and running.



Please download below the Eclipse projects with source code and scripts necessary to run this example. The file contains 3 projects, one for the ClientAggregator and two identical modified HelloWorld sample services that can be used for testing.

AggregationExampleProjects.zip

* This is as far as I can tell, however it might not be

Quick Service Prototyping




The following presentation illustrates how to do quick service prototyping. Instead of using DBEStudio to create service semantics and generate service skeletons (and implementation and service deployment), we just code the adapters directly and copy the classes to the servENT deploy directory. We achieve service re-deployment by simpy copying the classes on top of the old ones and restarting the servENT.

This technique could be useful when we want to quick turnaround for service prototyping.

QuickServicePrototyping.ppt

Sample Service Project for Eclipse with shell scripts (bash). This example is used in the presentation.
HelloWorldServiceProject.zip

Friday, December 22, 2006

10 Reasons Why SOA/Software as a Service Means Business

http://blogs.zdnet.com/service-oriented/?p=781

DBE service Execution: Give it a REST*

A typical DBE Client requires several parameters to make a call to a service. For example to invoke a remote method requires 3 pieces of information (at least):

- The service manifest ID (or SMID). This is the unique identifier of a service on the DBE. The service semantics (BML) is usually wrapping the SMID and when you search for services using BML, you end up getting lists of SMIDs which can be executed. SMIDs are similar to GUIDs.

- The operation name, or method that we want to execute. In our case, this is the getMessage(method) (see below)

- Input and output parameters (class as signatures and object references to the input values and the output holders). In our case signatures are [String.class,StringHolder.class].

(See the client example below)


Following a similar principle to the DBEPortal (DBEPortalClient) in which services are executed ondemand via a "proxy" which figures out how to call the service given the SDL , one of the ideas could be to provide a REST [1] like mechanism to the DBE that could work the same way, where just by reading/writing (GET/POST/PUT/DELETE) URIS, we could easily interop with services deployed on the DBE. However there is a small problem:

Conceptually REST is designed for resource update/retrieval and the DBE P2P service execution paradigm does not map directly (technically or conceptually) to the REST philosophy. Discussing this idea with the servENT guys (thanks Juanjo!), some of the issues were highlighted. However REST have been used in many different context regardless of a pure “REST” approach.

With this in mind, I have developed a very simple servlet that allows the execution of service via a REST-like interface if you provide (skipping the SDL, BML, etc).

The idea is to pass the necessary information for the service to be executed as url parameters (servlet uses GET, not POST, it should be implemented correctly). This makes possible to call the service from any scripting language or anything that can read an url, including wget J and of course a web browser.

The URI would look like this:

http://localhost:8080/servlets-examples/servlet/RESTAdapter?

servENT=http://localhost:2728& (Entry point to the P2P network)

smid=SM-809a38c771586296bc35988043ebf8a81f5724d5-10& (the SMID of the service)

method=getMessage& (what method we want to execute)

inputValues=HelloWorld& (values, comma separated such value 1,value2, etc...)

inputTypes=String&(types of our input objects)

outputTypes=StringHolder (types of our output objects)

The approach is the following, we pass the node entry point (servENT), the smid, the method we what to execute, the values (inputValues, and the method signature (inputTypes&outputTypes). As we are executing the service directly (no BML/SDL), we need to specify the signature. This is basically the same info that the ClientHelper needs to execute the service as shown earlier. This is OK for prototyping.

The results of this approach are displayed on the image below, where you can for example from python quickly execute the service/method once it is deployed:

Please contact me if you are interested in discussing/improving something like this.

[1] Some rest resources:

Introductory article:
http://www.xml.com/lpt/a/2004/12/01/restful-web.html

Original Concept
http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

An Practical Example
GData protocol that uses REST, RSS and extends the Atom protocol to provide a simple approach for resource reading/writting/updating/deleting (service execution in our context)
http://code.google.com/apis/gdata/protocol.html

*(This post is concerned mainly with service execution using fada/servENT not so much with the service semantics, BML and so on)

Update: Forgot to mention that this approach can only work at the moment with simple types (Integer, String, etc) and XML RPC Holders in Java speak.