I've spent the last two days in the Digital Business Ecosystem (DBE) Workshop arranged by Hermia Science Park in Tampere. DBE is an EU-funded Open Source technology for enabling small and medium-sized enterprises to work together in P2P fashion.

DBE basics

The DBE website is quite bogged by acronyms and marketese, but what the project actually boils down to is an application called DBE Servent written in Java. The Servent communicates with other DBE installations using a P2P protocol and some intelligent networking tools. The DBE Servent is used by business applications for communicating with each other using a set a defined Web Services.

DBE itself doesn't define these Web Services, it only provides the "wire protocol" for the Web Services to talk with each other, and ensures that different nodes in the network find each other, and find the services they require. The actual services are provided as SOAP Web Services conforming to a specified WSDL definition. This means that the applications utilizing DBE should be developed following the Service-Oriented Architecture model.

DBE is part of the €16 billion EU Framework Project 6. EU's interest in the DBE project is fostering a heavily localized Open Source business applications market, and support European SMEs in networking. The idea is that "an ecosystem of networked SMEs can evolve and adapt faster and more safely than the huge corporations". Participants in the DBE project include Sun, IBM, T6 and Soluta.net.

The development phase of the DBE project will end in 2006. Prior to that the project will make a first release of the 4Mb Java-based DBE Servent in April 2005. The participants are planning to move the project to SourceForge after this first release.

OpenPSA possibilities

With OpenPSA, the case for using DBE would be quite clear. We've already been thinking of implementing Web Services to make it easier for networked companies to work with each other more easily, and what DBE would add on top of those would include caching and asynchronous RPC support. In practice this would be we would only need to define the APIs used for the different services in OpenPSA, and then pass those to DBE. The Servent would then handle the actual connections between the different installations and dealing with nodes that are offline.

This way OpenPSA would enable organizations to manage all their operations with parners and subcontractors using DBE-compatible applications transparently. DBE-enabled OpenPSA would look approximately the following:

Supporting the Service Oriented Architecture would be a major change in OpenPSA code. We would have to encapsulate all data handling parts of the system with classes that would be able to store and fetch information using both local Midgard storage and remote Web Service APIs.

DBE risks

While the DBE concept sounds promising, it is still an unreleased piece of software. Additionally, it has not been tested outside academic circles, so the promises of scalability and automatic networking might not materialize in the real world.

Another problem is standardization of the Web Service interfaces used for different business scenarios or transactions. It has traditionally been a big problem to get an industry to work together on developing standard vocabularies and APIs, and DBE doesn't really address that. As the developers say, it is only the "TCP for business applications".

This might or might not be a problem. We could easily define a set of APIs using the taxonomies familiar in OpenPSA, and the rest of the industry could just follow us. This is what has pretty much happened with the different ad-hoc standards defined by the blogging world. However, it would require that our API would be generic enough, and that the developers of different project applications would find it easily. This all would hinge on the popularity of the DBE platform.

Project possibilities

The risks and non-existing user base of DBE are somewhat alleviated by EU funding for first companies developing services for the platform. We haven't yet made any decisions but we'll definitely think about utilizing DBE. OpenPSA needs some kind of Web Services interface to support networked business, and despite risks this would be a quite appealing solution.