Re: [ebsoa] Process-Oriented Architectures (POA)

["David RR Webber" <david@drrw.info>]

Mark,

I agree - this is TMI in my book regarding when and how enforcement
takes place - it should be implementors who
decided how to configure descrete enforcement mechanisms.

We can state that there should be mechanisms - and the behaviours
and compensation strategies et al - but no need for us to be
too explicit as to where and how.

Its an architecture component - and other pieces of the architecture
should know how to interact with it - but we do not need to
explicitly pin it to only one locale.

BTW - in this whole area is the Linking and Switching component
from BCM - for state management and related process direction.

Anyway - this probably touches off more discussion as to exactly
how we define the architecture and components and their
critical behaviours.... ; -)

My sense is we need to get the highlevel picture clearly agreed
before we deep dive into nitty gritty parts.  Eating our own
dog-food - BCM teaches - stay at highest level possible for
as long as possible while doing initial analysis - and separate
the required solution into layers - as per the layer method...

Thanks, DW.

----- Original Message ----- 
From: "Mark Yader" <mjyader@comcast.net>
To: "Chiusano Joseph" <chiusano_joseph@bah.com>; "Duane Nickull"
<dnickull@adobe.com>
Cc: "David RR Webber" <david@drrw.info>; "ebSOA"
<ebsoa@lists.oasis-open.org>; "Monica J. Martin" <monica.martin@sun.com>
Sent: Tuesday, April 06, 2004 9:56 PM
Subject: Re: [ebsoa] Process-Oriented Architectures (POA)


> I question this: "The ability to support processes requires additional
> functionality in the transport layer where the rules of the process should
> be enforced."
>
> Does this "additional functionality" (business processs support) lead us
> away from the KISS principle for the architecture. Again, I'm getting
> confused as to how much fits under the umbrella of ebSOA. Can we design an
> architecture in which the enforcement for business process rules is not
part
> of the SOA ? Is this really a "transport layer" function ?
>
> Mark
>
>
>
> ----- Original Message ----- 
> From: "Chiusano Joseph" <chiusano_joseph@bah.com>
> To: "Duane Nickull" <dnickull@adobe.com>
> Cc: "David RR Webber" <david@drrw.info>; "ebSOA"
> <ebsoa@lists.oasis-open.org>; "Monica J. Martin" <monica.martin@sun.com>
> Sent: Tuesday, April 06, 2004 12:00 PM
> Subject: Re: [ebsoa] Process-Oriented Architectures (POA)
>
>
> > Duane Nickull wrote:
> > >
> > > The way I understood it is that the term "Process Oriented
Architecture"
> > > refers to the business or other end users point of view whereas SOA
> > > really a FSV term.  This aligns with the UMM and other higher level
MDA
> > > approaches.
> > >
> > > The ebXML TA and UN/CEFACT eBusiness Architecture both support
> > > processes.  The ability to support processes requires additional
> > > functionality in the transport layer where the rules of the process
> > > should be enforced.
> > >
> > > Another term that has recently gathered momentum is "event driven
> > > architecture".
> >
> > Yes - Gartner has been heavy on this one.
> >
> > > All SOA's are event driven by nature.
> >
> > Agree. Eric Newcomer made the same comment at a recent session here in
> > DC.
> >
> > Joe
> >
> > > We may still have to explain this.
> > >
> > > Duane Nickull
> > >
> > > Chiusano Joseph wrote:
> > >
> > > >David RR Webber wrote:
> > > >
> > > >
> > > >>Joe,
> > > >>
> > > >>I humbly submit this is a redherring.
> > > >>
> > > >>Service Oriented IMHO already implies Process by extension  - since
> > > >>behind the delivery of any service there must be a process
> > > >>controlling and facilitating it.   Tha'ts why BPSS and BPEL are part
> > > >>of the SOA stack.
> > > >>
> > > >>
> > > >
> > > >Thanks David - but according to whom are they part of the SOA stack?
> > > >
> > > >Joe
> > > >
> > > >
> > > >
> > > >>We need another acronym like a hole in the head - let's leave that
> > > >>stuff to the professionals at Gartner to dream up, eh?  ; -)
> > > >>
> > > >>Cheers, DW.
> > > >>
> > > >>----- Original Message -----
> > > >>From: "Chiusano Joseph" <chiusano_joseph@bah.com>
> > > >>To: "ebSOA" <ebsoa@lists.oasis-open.org>
> > > >>Cc: "Monica J. Martin" <monica.martin@sun.com>
> > > >>Sent: Tuesday, April 06, 2004 9:30 AM
> > > >>Subject: [ebsoa] Process-Oriented Architectures (POA)
> > > >>
> > > >>
> > > >>
> > > >>>I know that our concentration is to be service-oriented
> architectures,
> > > >>>but at the same time I'm thinking about what will lie beyond (so
that
> we
> > > >>>can best prepare). A term popped into my head on the way home
> yesterday
> > > >>>(the DC Beltway apparatentely inspires me): Process-Oriented
> > > >>>Architecture, or "POA".
> > > >>>
> > > >>>Has anyone heard this term used before? I Google'd it and found few
> > > >>>hits, all of which seemed to be individual (rather than corporate)
> > > >>>references.
> > > >>>
> > > >>>As you can tell from the term, just as SOAs enable (involve, pick
> your
> > > >>>favorite word here) the use of shared services, POAs will extend
SOAs
> to
> > > >>>enable the use of shared Web Services-based processes that are
based
> on
> > > >>>shared Web Services that are defined within SOAs, working in
concert
> > > >>>with each other. So for a US federal application (my primary
client),
> > > >>>this could mean a set of shared Web Services-based business
processes
> > > >>>for federal agencies, in a flexible, agile, process environment.
> > > >>>
> > > >>>Does this concept resound with anyone?
> > > >>>--
> > > >>>Kind Regards,
> > > >>>Joseph Chiusano
> > > >>>Associate
> > > >>>Booz | Allen | Hamilton
> > > >>>
> > > >>>
> > > >>>
> > > >
> > > >
> > > >
> > >
> > > --
> > > Senior Standards Strategist
> > > Adobe Systems, Inc.
> > > http://www.adobe.com
> >
> > -- 
> > Kind Regards,
> > Joseph Chiusano
> > Associate
> > Booz | Allen | Hamilton
> >
>
>
>