edis edis
 
   

Event Driven Interprise Symbiosis

Since million of years interaction is evolution

We are talking about event driven middleware software. How do we harmonize the information flow in the small scale layer like embedded systems, sensors, and actors up to interprise (inter-enterprise) level, for example complex business transactions.

The EDIS (Event Driven Interprise Symbiosis edis.name) paradigm is the key to build such loosely coupled inter-operable systems in the future.

Coming from an existing and available open source approach (xmlBlaster) we are seeking the breathtaking next generation solution of middleware.

Terminology

  • Interprise: is an abbreviation for iter-enterprise, i.e. breaking the border a single enterprise.

    • Symbiosis A stable and reciprocally profitable association between two different living organisms, or

    • Symbiosis: A relationship of mutual benefit or dependence.

Communication Layer

A conversation between actors only makes sense if the involved parts understand each other. To get there, some conditions must be fulfilled. First of all the low level communication protocol must be established and secondly the communication language.

As a metaphor consider two persons willing to communicate to each other. They not only need to establish a common language, they also need to decide the sense which has to be used: visual, auditive or tactile. Here the choice mainly depends on

  • perceptive abilities of the involved parts

  • cultural background of involved parts

  • conditions of the environment

  • context of the conversation

  • security and privacy

For a simple conversation the natural choice would be to speak. For cases where one or more of the involved parts are deaf, or if the discussion would need to be persisted, written form will probably be preferred.

In some circumstances the environment is the predominant component for the choice of the communication: where the environment noise is high, an alternative to speech is needed. At this stage the context becomes the predominant factor for the choice of a fallback communication. If the content is simple and short, then some mimics would do it. If the context is more complex, written form will be preferred.

As already briefly mentioned, security and privacy can be important when it comes to decide the communication means. Obviously if the conversation has to stay confidential, then an informal and "volatile" conversation is well suited.

For a communication to be successful there is the need of a contract between the involved parts regarding the transport of the information. In the case of communication between people there was the need to decide sense and language to be used. In a middleware context this translates to an low level communication layer and an optional wrapper (or wrappers) on top of it. For example you could use CORBA with a generic enough idl. You could also use HTTP as the transport mechanism and on top of it XML-RPC or SOAP. As for the examples between people, here too different aspects determine which one of the technology which is best suited for the task.