I think we are violently agreeing...I tried to use the
terms the way you are using the terms and was out voted.
Bob
From: Poulin, Michael
[mailto:]
Sent: Monday, October 15,
2007 6:20 AM
To: Ellinger, Robert; Poulin, Michael; Ken Laskey; Scott
Came
Cc:
Subject: RE:
[soa-rm-ra] Questions on action model
You are right. With "business" I meant whatever business of
the organisation - government, non-profit, etc., not only those who produces
revenue. "Market" in this context is the external forces that cause changes to
the business needs...
- Michael
From: Ellinger, Robert
[mailto:]
Sent: 15 October 2007
11:15
To: Poulin, Michael; Ken Laskey; Scott Came
Cc:
Subject: RE: [soa-rm-ra] Questions on
action model
That's fine and where we started from...except...What
about governments and other non- "business" or not for profit
organizations? The term "business" is overloaded to some degree as is
the term "market." That is the reason we didn't keep those terms...but I
have no real objection.
Bob
From: Poulin, Michael
[mailto:]
Sent: Monday, October 15,
2007 5:44 AM
To: Ellinger, Robert; Ken Laskey; Scott
Came
Cc:
Subject: RE:
[soa-rm-ra] Questions on action model
Bob, I do not think that SOA is the instrument related to
the "change in the organization's environment". If I may, here is my
adaptation for SOA: "The ability to successfully respond to unexpected change
in the business needs in the market"
- 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: Ellinger, Robert
[mailto:]
Sent: 11 October 2007
23:55
To: Ken Laskey; Scott Came
Cc:
Subject: RE: [soa-rm-ra] Questions
on action model
Hi:
I guess I have to put my oar in this water. At the
Agility Forum at the Iacoa Center (for the Agile Enterprise) at Lehigh
Univ., I was on a team called the Agile Virtual Extended Enterprise
technical committee and I supported the DARPA/NSF effort called Next
Generation Enterprise on the Virtual Enterprise Team. Both of these
organizations used the following as the definition of agility--"The ability
to successfully respond to unexpected change in the organization's
environment."
What do you think?
Bob
From: Ken Laskey [mailto:]
Sent: Thursday, October 11, 2007 2:09 PM
To: Scott
Came
Cc:
Subject: Re:
[soa-rm-ra] Questions on action model
Scott,
Indeed I do not expect we (and anyone else) will provide a definitive
cookbook for defining services. However, it is exactly those guiding
principles that I think will be valuable and with which the RA should be
consistent. Thomas Erl's book may provide a good starting point.
If anyone can summarize between now and when I eventually make it to a book
store (or log into Amazon), we can begin considering those.
Note when we mention principles, we have to do much more than use terms
which are familiar but overused and never really defined. The RM
specifically took shots at loose-coupling and coarse-grained. I also
put agility into that category. When we state the principles (assuming
we can), those SHOULD be phrases that convey enough meaning that they cannot
be automatically misconstrued (by accident or on purpose) and then crisply
elaborated.
Again, I'm energized to revise the service description model but have a
long list of household chores to catch up on first. Keep sending
ideas. Alternately, you can come over and fix the lawn mower.
Ken
On Oct 11, 2007, at 1:35 PM, Scott Came wrote:
Ken:
Regarding
your #1…
I think
this kind of specific guidance is best reflected in a set of
principles. I don’t believe there will be a “one size fits all” set
of rules that tell you, in every situation, how to design a service
properly. The best you can do is identify the principal forces at
play—those factors that, at a minimum, the designer should at least
consider when setting service boundaries. Those forces are
represented in principles that say what should characterize a proper
service. Proper application of these principles (selecting among the
sometimes competing forces) requires the skill of a designer, but
well-stated principles accelerate the design process and bound the
designer’s discretion somewhat, in pursuit of an overall design
objective.
And not
just any old set of principles will do. SOA has an overall
purpose—to increase agility, adaptiveness, responsiveness to change—so the
principles should be included only to the extent they promote the design
of services that contribute to this purpose.
Some
design principles commonly identified with SOA are: loose-coupling,
abstraction, autonomy, statelessness. These were articulated, among
other places, in Thomas Erl’s “SOA: Concepts, Technology, and
Design”. I see he has a new book out that explicitly focuses on
principles. I know of no open-standard (e.g., OASIS) statement of
these principles; I think it would be great if the RA could reference them
somehow. I’m also not aware of any articles specifically addressing
design principles, but will look and post anything I find.
Regarding
your #2…
I believe
a single service description artifact is the right approach, largely for
the reason of discoverability as you mention. But, within that
single artifact, I believe there will generally be policy statements that
apply to individual actions.
Thanks…good
discussion!
--Scott
From: Ken Laskey [mailto:] Sent:
Wednesday, October 10, 2007 7:12 PMTo: Scott
CameCc: : Re:
[soa-rm-ra] Questions on action model
Scott,
I'll agree with your
analysis in principle but I'd like to get more specific for the
RA.
1. What can we say
as specific guidance about defining the service boundaries and what is the
range of things it makes sense to include as operations of a
service? With your example of the Time Management Service, it is
also possible that I have a general purpose Viewing Service and the time
record is one of the things I can view. Now the partitioning may
just fall onto the combination of competency and artistry of the service
designer, but I hope we can say more.
2. If I attach
things such as policies at the endpoints, how do I reflect that in the
service description? As I mentioned before, if the service
description is the information set on which I base discovery, I am
assuming I can't have things sprinkled outside of the service description
that might be critical criteria for the user.
Also, I'm always up
for collecting (and hopefully eventually reading) good, concise analyses
of how to approach these problems. Books are sometimes tough to
consume but articles and chapters are more doable. If you have any
particular favorites for providing insight, please pass these
along.
Ken
On Oct 10, 2007, at
10:53 AM, Scott Came wrote:
Ken:
Thanks
for your reply. I agree that stock quote checking, credit card
payment, and spouse reminder transmission are very likely to be properly
offered through separate services.
I also
agree that there probably should be only one service description
“artifact” (whatever that might be), with one policy “artifact”, but I
would add that the description and policy may have distinct provisions for
each action. This seems to be true whether all the actions of a
service are part of a single process model or not. For instance, in
the example you offered, there may be policy provisions for the account
debit action that have nothing to do with the notification about the final
bill payment. If it’s a corporation using the service, there may
well be rules that say the cardholder (ordinary employee) can receive
notification that the bill has been paid, but only accounting can
authorize the debit to the account.
While it
is true that WSDL places no limits on what you can “pack into a service”,
there are some good principles of design that you apply to choose service
boundaries. I would think the same principles would apply to any
service, regardless of the transport/messaging protocol being used (e.g.,
web services or not). As I suggested in my original post, the loose
coupling, autonomy, and encapsulation principles (I’m paraphrasing here)
proposed by Thomas Erl and others suggest a balance of loose coupling and
high cohesion. The architect designing a service (establishing its
boundaries…what actions belong in the service and which ones don’t) should
apply these principles to maximize the resiliency and agility that SOA
strives for.
While the
linkages of actions in a particular process certainly would have
significant bearing on the application of these principles, there are
other factors that would have a bearing as well. Information model
dependencies are a good example. One reason you wouldn’t want the
stock quote checker and the weather report in the same service is that
their information models are likely to vary independently. You
wouldn’t want to force the weather checkers to change their consumer
implementations (having to deal with a new service interface) just because
a new piece of information is added to the stock quote. They would
view that as absurd.
But in
the Employee Time Management service, if corporate accounting updates the
chart of accounts, it’s likely that both the viewing of time records and
adding of new time records would be affected. If two objects are
loosely coupled but highly cohesive, they tend to change together or not
at all. So, applying these principles would call for the viewing and
adding of time records being actions in the same service. But they
may not necessarily be part of a single business process…you could view
records without adding new ones, for example.
Bottom
line point: As an architect who designs a lot of services, I would
not want my alignment to the SOA-RM RA to be in conflict with my need to
apply design principles, which principles may call for me to group actions
into a single service when they are not (necessarily) related through a
process model.
On the
MEP issue, I am in agreement (for many of the same fundamental reasons)
that the actions of a service may require different MEPs.
Thanks.
--Scott
From: Ken
Laskey [mailto:]
Sent:
Tuesday, October 09, 2007 7:31 PMTo: Scott
CameCc:
: Re:
[soa-rm-ra] Questions on action model
Scott,
Lines 101-1015 are
trying to wrestle with the question of what actions make sense to have as
part of a single service and if I allow/encourage lots of description to
be connected at the lowest levels of the service, i.e. the endpoints where
I invoke the actions/operations, what does that mean for description of
the service and eventually service discovery.
Let's see if I can
expand on the questions. If I think of the actions as being similar
to WSDL operations, there is no limit to what I can pack into a single
service. So I can have a service with operations to check stock
quotes, to pay my credit card bill, and to send reminders to my
wife. If fact, I can have a single Ken's Service with many, many
operations that does all the computer-initiated tasks I can think
of. Then, certainly I would need to fully describe the RWE of each
operation and the associated policies would probably vary enough to merit
individual treatment.
Intuitively,
however, this doesn't seem like a good idea. So in the RM we talk
about a service having a resulting set of RWEs and policies about the
interaction, but what is implied is that the various actions are tied
together in the process model because there is a multi-step process that
is necessary to realize the RWE. The RWE is what results from
completing all the steps, and policies would relate at the service level
to say what is required to complete the entire defined process. In
this case, describing the service is fairly straightforward.
Now can one service
(as defined) have more than one RWE? Yes. If I have a bill
paying service and the funds are deducted from my checking account (or any
other account I designate) then RWEs include a debit to my checking
account, a funds transfer to whoever sent me the bill, and possibly some
accumulation of information to the credit bureaus that keeps me in good
standing. There may be multiple actions I need to invoke to handle
parts of the bill paying process and the MEPs used by each action could
differ. So some form of request-response could provide my
credentials whereas a notification of the final bill paying could just be
a one-way notification.
In your time
charging example, I would lean to saying each CRUD operation is a
different service with possibly different policies in defining who is
authorized for each operation. Is there any particular benefit to
bundling these into a single modifyTimeCharging service?
Hopefully, this has
provided you some understanding of my thought process. I'd be happy
to be argued into a different interpretation if that would have a
sounder basis.
Ken
On Oct 8, 2007, at
12:39 PM, Scott Came wrote:
I have
some questions regarding draft 0.2 of the RA, in the area of the action
model. I scanned the list archives for answers, and none were
readily apparent, so…
Regarding lines 1011-1015,
there is a statement that real world effects (note the plural) are defined
for a service, not the individual actions on a service. Similarly,
policies are associated with the service and not individual
actions.
I am
struggling with the practical implications of this.
It seems
if you allow a service to produce multiple real world effects, and the
plurality of effects is of significance to consumers, then at least in
some cases I would think you’d want to provide independent access to
those. (Otherwise, you may as well just roll them all up into one
macro “effect”.) So, if you accept that a consumer may choose to
achieve some of a service’s effects and not others during a particular
interaction, how would the consumer do so other than by invoking specific
actions? And, if the consumer is to invoke specific actions to
achieve particular effects, wouldn’t the service provider necessarily need
(per awareness) to tell the consumer which actions produce which
effects? Otherwise what distinguishes the actions?
An
example may help… A corporate accounting department provides a
service for business units to use in managing employee timesheets.
(The corporation is large and diverse enough that business units may build
their own time accounting systems, but by policy everyone must access the
central corporate capability for some basic functions.) The time
accounting service provides access to basic CRUD capabilities for employee
time: add time records, read (view) them, update existing ones, and
(perhaps) delete records under certain circumstances. If you are
willing to grant that these four actions (create, read, update, delete)
are appropriate within a single service action model, then clearly they
produce distinct (though related) real-world effects (underneath the
“umbrella” effect of “manage employee time records”), and certainly will
have different policies associated with them (there may well be tighter
access control on changing data than viewing data, for
example).
A
possible objection to this characterization of the service is that it
tightly couples each of the four C/R/U/D operations in a single
service. The problem with this objection is that there is no
universal benchmark for tight-coupling. Coupling and cohesion are
competing forces that need to be balanced in any design decision.
Achieving that balance is an engineering problem solved based on the
particulars of the situation. In an SOA, since one of the primary
objectives is agility and resiliency, I would hope the architect would
make that decision primarily on the basis of whether the four actions are
likely to change at the same time, or not at all. But certainly
other factors may come into play.
It seems
you would want to give the architect the freedom to achieve the right
balance there, rather than force his or her hand by saying services must
be designed such that the actions do not achieve distinct objectives and
do not have distinct policy requirements.
This
line of reasoning may be completely out in left field; however, if it is,
I would urge some more thorough discussion in section 4.2.2 of how service
design principles should impact the scoping of services, their RWEs, and
their action models.
I also
have one more specific follow-up question, not addressed in section
4.4.1.2: In an RA-conformant concrete architecture (as such is
envisioned now), can the actions in a single service’s action model use
different MEPs? Can one action use request/response and another use
event notification?
Thanks
for your help!
--Scott
Scott
Came
Director, Systems and
Technology
SEARCH--The National Consortium
for Justice Information and Statistics
(916)
212-5978
(916)
392-2550 x311
-----------------------------------------------------------------------------
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
-----------------------------------------------------------------------------
Ken Laskey
MITRE Corporation, M/S H305
phone:
703-983-7934
7151 Colshire Drive
fax: 703-983-1379
McLean VA 22102-7508
