Monday, November 26, 2007

Google shows phone prototype to vendors

Very interesting to see the war in getting closer to the customer/user is finally in the form of mobile phones. In the IT sector, it started with the PCs, then to Laptop, PDAs, MP3 Players and finally to an all in one form. Let's keep a close watch on how this area develops.

Labels: , ,

Tuesday, January 30, 2007

Training Content

This is more or less the technical DBE training content available on this weblog. While not a perfect structure (pretty much all the materials overlap more or less), it is structured in terms of technical areas such as servENT/DBEStudio, presentations, videos and demos.


- What Time is IT? Date GUI Service


- What Time is IT? Date Service


- From WebService to DBE Service


- Service Aggregation


- Quick Service Prototyping


- DBE Service Execution: Give it a REST


- Service as a Webpage: Information Handlers in servENT



- Importing OWL Ontologies to DBEStudio


- Create your Own (DBE) Semantic Search Engine


- Tagging/Labeling Software Services “Web 2.0” Style


- DBEPortal Service in servENT


- DBEStudio Tutorial


- BML and Bio/NanoTech Scenario



- BML presentation


- BML TreeMaps


- DBE at LUG Radio Live 2006


- Creating a Development Work-Flow Poster


- BML For Business Networking


- DBE Recommender



- DBE (ExE) P2P WebCam Demo


- DBE (ExE) DateService with OpenLaszlo Interface


- WebCamera Semantic Search: A Trivial Example


- SugarCRM + DBE + OpenLaszlo


- Calendar Demo with Semantics


Thursday, January 18, 2007

A true DBE community

A brief overview of software services that have been integrated into the Digital Business Ecosystem Project.

Tuesday, January 09, 2007

Service as a Webpage: Information Handlers in servENT

During the previous examples we have seen that we can invoke services via a custom commandline client or even using a REST-like approach. As the servent is integrated with Jetty, it is possible to extend the our service to implement a Handler (org.dbe.servent.http.ServiceHandler) that extend (or is based) the Jetty Handlers.

By implementing the ServiceHandler interface (2 methods init() and handle()) we can provide the service with a Web interface via the service real endpoint that can be used to interop with the service. This way is also ideal for implementing the REST that we discussed earlier. (However we need to search for the service as we need to know the real endpoint)

To integrate a ServiceHandler in our service, we need to do a couple of things. First of all is to declare in deployment.props that our service has a Handler. This is done by assigning the property “handler” to point to the class that implements the ServiceHandler interface (see below)

File: deployment.props

The second thing that we need to do is to implement the declared hander. See example below. In our case we have called the service itself from the Handler.

And it is accessed with for example with a web browser by pointing to the endpoint of the service, as a standard URI. In our example the output is the webpage itself.

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, 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.

* 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.


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

Friday, December 22, 2006

10 Reasons Why SOA/Software as a Service Means Business

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:


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:

Original Concept

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)

*(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.

Thursday, November 30, 2006

DBE & RedHat/JBoss & Codecamp

Some ideas as a result of the workshop:
  • JBoss could implement some servENT architectural pattern
  • or the ExE could be integrated into JBoss
  • A JBoss node could be a DBE Node
  • and services deployed on JBoss could be accesible via the DBE
This is my interpretation of the events, so for a more detail summary, head to the ITA DBE blog:

Also, a codecamp was run with 20+ companies:

You can see the results and feedback from the codecamp here: