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:]
Sent: 28 September 2007 00:04
To: Duane
Nickull
Cc: Jeffrey A. Estefan;
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" <>
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" <>
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" <>
To:
<>
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
