To the Ken's point #2:
I do not see a problem with attaching policies at the
endpoints unless the attachment happens up-front and remains until removed ( and
announced ). I would not go with any kind of dynamic attachments of policies.
(BTW, dynamic attachments, i.e. attachment of the things unknown at the moment
of discovery and negotiation, may contradict the concept of Service
Contract)
Since provider knows what policies are attached to
particular endpoint, the same provider can mention those policies in the Service
Descriptor. A knowledge about applied policies is the part of the consumer's
decision on selecting discovered service, plus, why it may not be a part of the
discovery query ? (like "I need a service which supports the latest version of
the regulation R").
To my understanding, Service Descriptor is much richer than
a description of the interface and endpoint; it includes all necessary
information needed by a consumer to assess if the service meets consumer needs (
see SOA RM ). This includes information on all policies set by the provider.
Thus, we need certain standardisation of the description language used
in the Service Descriptor.
- 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: 11 October 2007 03:12
To: Scott Came
Cc:
Subject: 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
