OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm-ra message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


Ditto..
 
It is important to distinguish between infrastructure services that implment cross-cutting functionality that should be externalized and consitently implemented in all business/data services in a SOA (e.g. Authentication, Authorization, logging/auditing, metrics etc.) from other capabilities that are embedded into the biz logic of the service itself.
 
Regards,
 
- Anil


From: Ken Laskey [mailto:klaskey@mitre.org]
Sent: Sat 3/24/2007 12:09 PM
To: Duane Nickull
Cc: michael.poulin@uk.fid-intl.com; soa-rm-ra@lists.oasis-open.org
Subject: Re: [soa-rm-ra] Interacting w/Services Model Updated (a start on EDA & event-driven SOA)

Duane,

One collection of services that has surfaced are those identified on some projects as Enterprise Service Management (ESM).¬  These provide logging, auditing, metric collection, load balancing, etc. functions.¬  I think some of the functions you list are generic ESM and are infrastructure used by many (most? all?) services.¬  Some, like thread management, are specific to the service (and underlying capability) implementation and are opaque to the SOA level, i.e. I know the ways to enter and leave the container but not what happens inside.

Ken

On Mar 19, 2007, at 1:30 PM, Duane Nickull wrote:

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"

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¬  ¬  ¬  ¬  ¬  ¬  ¬  ¬  ¬  ¬  *
**********************************************************


------------------------------------------------------------------------------------------
Ken Laskey
MITRE Corporation, M/S H305¬ ¬  ¬ ¬ phone:¬ ¬ 703-983-7934
7515 Colshire Drive¬  ¬  ¬  ¬  ¬  ¬  ¬  ¬  ¬  ¬  ¬  ¬ ¬ fax:¬  ¬  ¬  ¬ ¬ 703-983-1379
McLean VA 22102-7508






[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]