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  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:
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.
 Some rest resources:Introductory article:
http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htmAn 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)
*(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.