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


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

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

Subject: Re: [soa-rm] On POAs and SOAs

My personal thoughts on this are that we should be part of a layered 
approach.  We should just stick to SOA, perhaps with a non-normative 
note that explains the relationship that SOA concepts may be "part of" a 
POA.  The reasoning is as follows:

1. If we explicitly associate SOA with POA, we would probably have to 
consider other things that SOA can be used within.  This may be a 
pandora's box since POA is not the only other architectural paradigm 
associated with SOA (Even driven architectures, client-server 
architectures, distributed system architectures, component based 
architecture, etc.)

2.  POA should probably be defined as a POA Reference Model outside of 
the SOA RM.

3. It is not in our charter to tackle POA.

4. POA directly is probably not a core element of SOA, although many SOA 
implementations will be used as part of a POA environment.  The main 
implications for SOA is that conceptually, services may need to be 
robust enough to include the items that POA would demand of it.  This is 
very concrete thinking however.  Must stay abstract.


Frank McCabe wrote:
> I think that the distinction between SOAs and POAs may be getting 
> clearer -- although I personally would like to see more clarity on POAs.
> However, this leaves a big question mark -- is the *industry* looking to 
> us to define what *we* think is an SOA, or what *they* expect to see in 
> an SOA.
> (Of course, I am aware that there is no *they* there ..)
> Speaking for ourselves,  we definitely *include* concepts such as 
> security, service composition, management in what *we* think of as SOA.
> I would like us to consider whether we can encompass a broader view of 
> SOA in our reference model -- specifically to include process 
> management/composition. I believe that the security story will come out 
> adequately in the current direction of the RM.
> Frank

Senior Standards Strategist - Adobe Systems, Inc. - http://www.adobe.com
Vice Chair - UN/CEFACT Bureau Plenary - http://www.unece.org/cefact/
Adobe Enterprise Developer Resources  - 

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