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:]
Sent: Sat 3/24/2007 12:09 PM
To: Duane Nickull
Cc: ; 
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, ""

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

**********************************************************

------------------------------------------------------------------------------------------

Ken Laskey

MITRE Corporation, M/S H305     phone:  703-983-7934

7515 Colshire Drive                        fax:        703-983-1379

McLean VA 22102-7508