The Vision of NextGRID

Imagine a world where Grid technologies have been a total success. The Grid is now a global phenomenon, and the Web is plenty of service providers offering their Grid Services for anything you may need. Some of them are free, but in most cases they are not.

In order to bring some order to this myriad of disparate services, the Grid has become semantic. Standard ontologies have been developed for many fields of knowledge and business, and now services can be accurately described by using one or more standard ontologies to build a semantic description of the service constraints and capabilities. What is more, Semantic Registries, containing information about hundreds and thousands of these services, are now as wide spread as the DNS system.

In this scenario, Grid Services can be easily orchestrated. With the aid of visual tools, programmers build their programs by drawing diagrams that describe the interaction among a set of processes, just like in a flowchart.

In these diagrams, let's call them "workflows", some nodes are just semantic descriptions of what the actual Service will have to do when invoked. Through a discovery mechanism, querying the Semantic Registries, some of these descriptions will be resolved at runtime into real services, while others will be translated to more or less complex workflows, which will be integrated into the global one.

Therefore, Semantic Registries can contain not only the descriptions of final services, but also the description of workflow "templates", which can be integrated at runtime into the workflow being executed.

Of course, these diagrams must be translated into something a computer can understand and use. The visual tools for workflow authoring, the engines that enact (resolve, execute and monitor) the resulting workflows, as well as the Registries containing the templates; all of them must share an agreed Process Model, which will allow interoperability among different products.

Back to the Present Day

Nowadays, there is no standard specification for service workflows that covers the whole range of functionalities such scenario requires. To fill this gap, two complementary models were designed. First, a Workflow Programming Model, which led to the specification of OWL-WS. Second, the Grid Virtual Infrastructure Model , which describes what the workflow components, the services and their environment are like, and how they interact.

And it is here where the Adaptive API comes into scene. This API provides a common programming "language" to build workflows, and to enact them. It aims to be a framework for everybody acting as a client of the Grid, from the final programmers trying to enact a pre-authored workflow, to the developers of sophisticated WYSIWYG workflow authoring tools.

But the Adaptive API does not stop here. Rather of limiting it to the OWL-WS language, it has been designed as a syntax-agnostic engine, able to support other standard or popular workflow representations. What is more, its plugin-based architecture allows extending it to support new service types, new control-flow constructs, or even proprietary systems.

And now to the Future

Adaptive API is not dead at all. It is still a live project with the aim of giving prodution-quality workflow support to anybody that needs it.

With this goal in mind, research will continue and its results will be fed back to the project code base. What is more, the companies that participated in the birth of this project will have always a privileged seat in its Management Board (we are the copyright owners after all).

Of course, contributions will be always welcome wherever they come from. If you like this project, we are looking forward for your feedback.