Re: [soa-rm-ra] Interacting w/Services Model Updated (a start on EDA & event-driven SOA)

[michael.poulin@uk.fid-intl.com]

Duane, as a possible model, a service container is attractive. Nevertheless, I am afraid of making the same 'issue' (I do not say mistake) as J2EE with its containers.

I see a lot of trends in the industry to rid of the containers (Spring as an example) though personally I do not like such trends. So, should we also observe a 'containerless' model? Why we always require an intermediary (like broker, manager, container)? Such things are very good for certain types of tasks, not for all tasks however.

Here is an example of a centralized service 'conductor' and the service that sends notification events by itself. Assume we have a GRID where we have deployed one centralized service 'conductor' and multiple services (or service instances) that  have registered with the conductor. When a conductor gets a task/request, it checks what services are available and commands them to perform related sub-tasks. Upon completion, each service reports to the conductor, i.e. sends notification message.

I do distinguish between container and invocation layer thinking that the latter is quite useful.

- Michael