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

[Duane Nickull <dnickull@adobe.com>]

Michael:

I use the term container in the same pretest as ESB - a conceptual
collection designed to break the whole down into smaller parts, grouped by
function. Neither should constrain implementations from following the model.

As such, container was perhaps a bad choice of words but given it had been
used before, it seemed the most logical choice.

Starter set of major functions of a service could be:

Invocation layer
State management (for the state of a single service call execution. If the
service call involves making several internal calls to endpoints and
aggregating those to calculate a response, that is done here)
Validation (syntrax, business rules)
Logging
Thread manangement
Link to capability provider
Intermediary (registry lookup for mapping invocation requests to
capabilities behind the service)
Communication logic handler (talks to invocation layer to provide
instructions for return routing, fault generation etc.)

...



Duane


On 3/18/07 2:54 PM, "michael.poulin@uk.fid-intl.com"
<michael.poulin@uk.fid-intl.com> wrote:

> 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 

-- 
**********************************************************
Sr. Technical Evangelist - Adobe Systems, Inc.           *
Chair - OASIS SOA Reference Model Technical Committee    *
Blog: http://technoracle.blogspot.com                    *
Music: http://www.mix2r.com/audio/by/artist/duane_nickull*
**********************************************************