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] Fw: [soa-rm] Why service composition and composite applications are anti-patterns of SOA


I do agree with Ken - RA has to be concrete about "aggregation consistently instead of composition" (BTW, I have missed the difference between aggregation and composition in the discussion).
 
Based on my recent contacts here in London, this topic gets hot especially in the light of RM. In particular, here are the questions may people ask but answers are questionable ( I will talk about composite services ):
 
1) does SOA principle of Autonomy  - service controls its behaviour - stands with composite services ? A: looks like it doesn't because a composite service may not CONTROL behaviours of engaged services but can be only responsible to the Consumer on the contractual basis ( Service Contract between composite service and engaged services)
2) how define a SLA (in the most automated way) for a composite service?
3) how 'deep' service hierarchy in the composition is the best practice?
4) if one defines a sequence of service invocation via, e.f. BPEL, should it be exposed as a SOA Service or as an infrastructure resource ( even if it exposed via Web Service interface )? (This does not relate to the mediating SOA Service providing a sequence of other service invocations via programmatic service calls)
5) how to approach and manage ownership of a composite service? (while a stewardship is more-or-less understandable topic)
6) what might be the best practice for testing a composite service? The composition can 'extract' an engaged service from the execution context it was tested by the owner and put it into new execution context, at least, business execution context. What should we do in this case to control the 'elephant'?
 
Thanks,
- Michael
 

Important: Fidelity Investments International (Reg. No.1448245), Fidelity Investment Services Limited (Reg. No. 2016555), Fidelity Pensions Management (Reg. No. 2015142) and Financial Administration Services Limited (Reg. No. 1629709, a Fidelity Group company) are all registered in England and Wales, are authorised and regulated in the UK by the Financial Services Authority and have their registered offices at Oakhill House, 130 Tonbridge Road, Hildenborough, Tonbridge, Kent TN11 9DZ. Tel 01732 361144. Fidelity only gives information on products and does not give investment advice to private clients based on individual circumstances. Any comments or statements made are not necessarily those of Fidelity. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If you received this in error, please contact the sender and delete the material from any computer. All e-mails sent from or to Fidelity may be subject to our monitoring procedures. Direct link to Fidelity’s website - http://www.fidelity-international.com/world/index.html

 



From: Ken Laskey [mailto:klaskey@mitre.org]
Sent: 28 September 2007 00:04
To: Duane Nickull
Cc: Jeffrey A. Estefan; soa-rm-ra@lists.oasis-open.org
Subject: Re: [soa-rm-ra] Fw: [soa-rm] Why service composition and composite applications are anti-patterns of SOA

But if we are going to use aggregation consistently instead of composition, we should be clear what we mean and why.  I don't necessarily want to pick a fight with anyone but we should be clear about our own meaning.

Ken

On Sep 27, 2007, at 6:58 PM, Duane Nickull wrote:

I don’t think we would condone fighting others over this, just being accurate in our own work. Let others use the composition convention as they see fit – beyond our control to influence anyways.

/d


On 9/27/07 3:37 PM, "Ken Laskey" <klaskey@mitre.org> wrote:

Let's see what it means to make a clear case for this.  If the path is too tortured, we probably don't want to waste the capital fighting that value.  If it's fairly straightforward, maybe we want to give it a shot.

Ken

On Sep 27, 2007, at 12:35 PM, Duane Nickull wrote:

For accuracy sake, I concur.


On 9/26/07 2:05 PM, "Jeffrey A. Estefan" <jeffrey.a.estefan@jpl.nasa.gov>
wrote:

 
Duane,

Should we revise our discussion of composition of services in the RA we are
developing to state "aggregation of services" or "service aggregation?"  I
certainly see your point and from a UML perspective but I also agree with
you comments in your blog that essentially the 'train has left the station'
so-to-speak for quite some time now and industry is getting very familiar
with the nomenclature of "service composition."  Can we expect to buck the
system via the RA?  Don't know.  Just a question.  And what is the GoF view
on composition say via the structural Composite Pattern?

Others?

 - Jeff E., JPL

----- Original Message -----
From: "Duane Nickull" <dnickull@adobe.com>
To: <soa-rm@lists.oasis-open.org>
Sent: Thursday, September 20, 2007 9:54 AM
Subject: [soa-rm] Why service composition and composite applications are
anti-patterns of SOA


 
http://technoracle.blogspot.com/2007/09/soa-anti-patterns-service-compositio
n.html


-- 
**********************************************************************
"Speaking only for myself"
Blog - http://technoracle.blogspot.com
Community Music - http://www.mix2r.com
My Band - http://www.myspace.com/22ndcentury
MAX 2007 - http://technoracle.blogspot.com/2007/07/adobe-max-2007.html
**********************************************************************

 


 

-- 
**********************************************************************
"Speaking only for myself"
Blog - http://technoracle.blogspot.com
Community Music - http://www.mix2r.com
My Band - http://www.myspace.com/22ndcentury
MAX 2007 - http://technoracle.blogspot.com/2007/07/adobe-max-2007.html
**********************************************************************


 

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








--
**********************************************************************
"Speaking only for myself"
Blog - http://technoracle.blogspot.com
Community Music - http://www.mix2r.com
My Band - http://www.myspace.com/22ndcentury
MAX 2007 - http://technoracle.blogspot.com/2007/07/adobe-max-2007.html
**********************************************************************

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






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