Einstein: an Experimental 4GL for SOA

Posted by Boris Lublinsky on Jun 23, 2008 08:37 PM

Community

SOA

Topics

SOA Appliance ,

Domain Specific Languages ,

SOA Platforms

Tags

Services

SOA implementation typically requires usage of multiple technologies for implementing things like distribution, parallel processing, orchestration, etc. Although there are multiple tools supporting these requirements, including Web Services frameworks for invocations, Enterprise Service Buses (ESB) for routing, Orchestration engines for business process implementations, etc. SOA implementation remains a daunting task, requiring, at a minimum, understanding of these very different technologies their programming models, their implementation and deployment approaches, etc.

One of the possible solutions to this complexity are "SOA programming languages" - Domain Specific Languages for SOA, for example Wsper or Einstein. The motivation behind these languages is to further raise the level of abstraction to move it closer to the actual SOA development concerns. As Edsger Dijkstra Notes:

A most important, but also most elusive, aspect of any tool is its influence on the habits of those who train themselves in its use. If the tool is a programming language this influence is, whether we like it or not, an influence on our thinking habits.

Wsper is well described in Jean-Jacque Dubray’s InfoQ book on Composite Software Construction, thus the rest of this this post will concentrate on Einstein

Einstein is a language designed for the complex environment of a distributed SOA and is built around following main principles:

• Distributed Einstein was designed so that (potentially) each instruction could be executed on a separate machine to each other. It is then up to the user to decide how much distribution, and concurrency, they wish to actually use in their code.
• Event Driven Einstein is a flow based programming language where instructions communicate through messages.
• Concurrency Friendly Einstein has been written to be concurrency friendly; it uses a combination of proven shared state avoidance techniques (message passing, read only tuples etc.) with runtime awareness of thread safety.
• Complexity friendly Einstein has adopted a few simple techniques to reduce the complexity of implementing distributed systems including Resources and Models.
• A Replacement for a Hodge-podge of Technologies Einstein aims to replace the plethora of technologies used to integrate multiple systems. Currently, when building a cross-resource system, we often rely on a mixture of ESBs, grid technologies, distributed state systems, coordination technologies (like BPEL), and workflow systems, amongst others. Einstein is designed to be a single tool incorporating capabilities of these technologies.

Einstein’s language is based on the following concepts:

• Resources, which can be best compared to variables, but are typically coarse grained. Resources are accessible using URIs. Resources can be characterized as volatile (safe for multithreaded access), local (not intended for multi node access and/or serialization) and idempotent (can receive a message multiple times and achieve the same affect as receiving it once).
• Providers, which give a consistent interface for any resource capable of receiving, transmitting, executing, querying, routing or processing messages in some manner. A Provider can be split into three components: ResourceProvider (acting as a resource factory), Resource (implementation), Facades (views on a Resource exposing a simple coarse grained interface to the functionality provided by the resource). Providers are automatically loaded into the Einstein registry, which contains information about all available resources and providers.
• Messages are the main mechanism for exchanging data between Einstein resources. The payload of a message contains a Data Object rather than a language objects which allows multiple data formats (e.g.: XML, Object Graphs, CSV files, etc) to interact with Einstein.
• Execution groups, including flow execution groups (sequential execution, similar to sequence in orchestration languages), Tuple Execution groups (parallel execution, similar to fork/join in orchestration languages), Compositing execution group (similar to Tuple, but completing apon completion of at least one branch) and Map Execution groups (combination of the above) .

The ultra experimental release 0.1 of Einstein is available now. According to the project’s roadmap core language preview should be available on July 15th, followed by the Core Language release on September 1st.

1. Back to top

   Thanks

   Jun 24, 2008 9:56 AM by Neil Ellis

   Thanks Boris, as you mentioned it's very much early days on Einstein - if anyone digs the ideas behind it please ping me for a chat. Next week I'm doing a webinar which will include a piece on Einstein. We've got a lot going into the future design at the moment; uniting a few diverse concepts such as rules engine, design by contract, state machines and concurrency idioms into a single cohesive syntax and semantic. So I'd recommend anyone interested to pop along to the website and register to get the weekly newsletter or sign up to dev@einstein.codecauldron.org and throw in some ideas.
   
   All the best
   Neil
   

   Reply

• Older >