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


Michael - some thoughts on your questions.  Ken

On Sep 28, 2007, at 5:45 AM, Poulin, Michael wrote:

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)

Nothing is absolutely autonomous.  Risks will be evaluated and mitigation plans will exist but there are some dependencies outside your control and you live with these.  A contract with someone says they have a responsibility for managing some risks but you have no 100% guarantee they will be successful.

2) how define a SLA (in the most automated way) for a composite service?

The owner of the composite service needs to evaluate his/her risks and decide what to sign up for in the SLA.  Assumptions will be made, some good and some not so good.  For example, the current sub-prime mortgage crisis has to do with bundling mortgages (creating a somewhat opaque aggregation) and there was not an adequate assessment of the aggregated risk.  In most cases, I expect people will guess right but there will be some notable failures.

3) how 'deep' service hierarchy in the composition is the best practice?

Tell me more about this one -- what is 'deep' service hierarchy?  If you are asking how deep you should go in a service invoking a service which invokes a service which ..., I think again it is a matter of trade off of what are your competencies vs. what lower level things do you basically want to outsource?  Many companies use outside companies for payroll and the payroll company outsources for software and IT, and their suppliers outsource for ...  Doing it with services is no different except the message traffic may give you better metrics and eventual accountability.

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)

If you are interested in the functionality and real world effects of the sequence and not necessarily the parts of the sequence, it sounds like a SOA service to me.  If an organization has a required information flow that invokes security checks at given points, this sounds like infrastructure process where it may be obvious that the business service is accomplished by a SOA service (maybe through other orchestration) taking part in the infrastructure process.

5) how to approach and manage ownership of a composite service? (while a stewardship is more-or-less understandable topic)

The owner is responsible for managing his/her suppliers.  A consumer expects to make use of the composite and not worry about lower level suppliers, although on rare occasions that will become an issue (e.g. if someone decides to boycott rice from Burma).

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'?
 
Testing and certification are very big open issues.  This probably goes beyond RA work would unacceptably lengthen this email :-)

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





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




smime.p7s



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