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] Questions on action model


Title: RE: [soa-rm-ra] Questions on action model
Clalrification inline:

At 9:30 AM +0100 10/16/07, Poulin, Michael wrote:
I agree with Rex, we need a directive case in the RA showing how aggregated service might deal with an unexpected change.
 
Actually, I have two points here. One is about some explanations given by Rex, and another one about the change.
 
I am not sure I fully understand why "become a service consumer, yet must provide information to this other service provider about how it wants to aggregate that other service". If Rex means a Service Contract between an aggregate service producer and a "leave"/aggregated service producer, I would agree  with the statement though the former (consumer), probably, has not to provide much information to the provider in the Service Contract...

When the aggregate service  is consuming an aggregated service, the aggregated service producer may want or require to know what other services will be aggregated with its service. This is a real example, though I can't use the real names. One service producer who supports opensource will not allow its service to be aggregated with services that use certain commercial products.

The negotiation mentioned below applies to my example.

 
Plus, the aggregate service producer has to negotiate the Service Contract with the aggregateD service producer BEFORE publishing the aggregate Service Descriptor only in the case where a business value, provided by the aggregateD service producer, has to be mentioned in the aggregate Service Descriptor. Otherwise, the Contract with the aggregateD service producer gets totally invisible to the end-consumer and aggregate Service Descriptor may stay unchanged despite changes in the Service Contract with the aggregateD service producer.
 
Talking about an unexpected change, I meant a change in the consumer needs, i.e. business requirements. I use word 'unexpected' just to outline that the service design does not include new 'thing', caused by the change, as is. This does not mean that the service is incapable to adopt the change. For example,  a service with Web Service interface process a data structure described by an XML Schema. The new thing is an additional field in the data structure. So, the same service can process that field via the same operation if the XML Schema gets extended and accommodates new field. Another example may be a change dictated by new industry regulations and it affect the service w/o any efforts from the consumer side.

The unexpected change described above is not included in my real example, though it is in a different real world example where a specific external Standard goes through a version change, 1.0 to 1.1 for example, and then a 1.1 errata is made where one field is added, but, to make life more interesting, the errata is added at exactly the same time that a different SDO issues a duplicate of the standard in ASN.1 format including the field from the errata.

This has ramifications where some end-user consumers can consume only XML or only ASN.1. (I'm not asking that this complex example be included in the RA). However, I think the simplest case should be considered of two services aggregated together with the need for some structured or mediated communication between the producer of the aggregate service as a consumer of the aggregated service and the producer of the aggregated service. The issue of unexpected change should perhaps be mentioned as another factor for which an RA may need to allow.

Cheers
Rex
 
Now, the aggregateD service gets changed. This leads to the re-negotiation of the Service Contract between the aggregate and aggregateD service producers. This may cause a chain re-negotiation back to the end-consumer and, probably, versioning of the services to provide a graceful transition onto new services.
 
I am trying to say that an unexpected change is not the same as an unexpected system failure and has to be treated via the governance - policies and processes.
 
- Michael


From: Rex Brooks [mailto:rexb@starbourne.com]
Sent: 15 October 2007 17:05
To: Ellinger, Robert; Poulin, Michael; Ken Laskey; Scott Came
Cc: soa-rm-ra@lists.oasis-open.org
Subject: RE: [soa-rm-ra] Questions on action model

Hi Everyone,

I have followed this thread and was tempted a couple of times to put in my $.02, and now that is has wound down on a couple of specific points, I think I should. This particular collection of included posts doesn't specifically include Duane's comment about consumer use of service description, let alone in the context of "unexpected change." However, that's what I'm interested in because it is problematic.

I am specifically concerned about aggregation chains where we will find a service producer who, in order to successfully aggregate a service from another service producer, become a service consumer, yet must provide information to this other service provider about how it wants to aggregate that other service. They must do this first in order to provide their own service description of the aggregated services they will, in turn, provide to endpoint customers or to other service providers.

I think we should provide for the simplest of these cases in the Reference Architecture. I'm also concerned that our mechanisms account from crossing boundaries between public and private enterprises.

Now, when unexpected changes happen in the simplest case, how do we deal with it most efficiently?

Cheers,
Rex

At 6:23 AM -0500 10/15/07, Ellinger, Robert wrote:
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:Michael.Poulin@uk.fid-intl.com]
Sent: Monday, October 15, 2007 6:20 AM
To: Ellinger, Robert; Poulin, Michael; Ken Laskey; Scott Came
Cc: soa-rm-ra@lists.oasis-open.org
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:robert.ellinger@ngc.com]
Sent: 15 October 2007 11:15
To: Poulin, Michael; Ken Laskey; Scott Came
Cc: soa-rm-ra@lists.oasis-open.org
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:Michael.Poulin@uk.fid-intl.com]
Sent: Monday, October 15, 2007 5:44 AM
To: Ellinger, Robert; Ken Laskey; Scott Came
Cc: soa-rm-ra@lists.oasis-open.org
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:robert.ellinger@ngc.com]
Sent: 11 October 2007 23:55
To: Ken Laskey; Scott Came
Cc: soa-rm-ra@lists.oasis-open.org
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:klaskey@mitre.org]
Sent: Thursday, October 11, 2007 2:09 PM
To: Scott Came
Cc: soa-rm-ra@lists.oasis-open.org
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.
Thanksgood discussion!
--Scott

From: Ken Laskey [mailto:klaskey@mitre.org]
Sent: Wednesday, October 10, 2007 7:12 PM
To: Scott Came
Cc:
soa-rm-ra@lists.oasis-open..org

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 boundarieswhat 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 processyou 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:klaskey@mitre.org]
Sent: Tuesday, October 09, 2007 7:31 PM
To: Scott Came
Cc:
soa-rm-ra@lists.oasis-open.org
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
scott.came@search.org



-----------------------------------------------------------------------------
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


--
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-898-0670


--
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-898-0670


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