To Scott's "to group actions into a
single service when they are not (necessarily) related through a process
model" - I see "group actions into a single
service" based on "a process model" as a
specific task for a mediating service. In other cases, I base action grouping on
the business service/function/unit of work model, not on a process. That is, the
business model implemented by SOA Service actually sets the boundaries of what
may be in the service (the task left is to decide if I need to group all
identified actions into one service or split them between several
services).
Plus, if the relationship between business
services/functions/units of work gets understood in the enterprise, it allows
for reasonable prognosis of what might be changed in the future (by the
business) and how far existing service(s) may be extended (to agile with
business requirement changes)
- 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: Scott Came
[mailto:]
Sent: 10 October 2007
15:53
To:
Subject: RE:
[soa-rm-ra] Questions on action model
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
PM
To: Scott Came
Cc:
Subject: 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
