[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm-ra] multiple descriptions [was: [soa-rm-ra] Questionson action model]
Good business managers (Yes Virginia there are some :-) have been developing and successfully using complex business processes for quite some time. These processes are made up of interacting activities, many of which cross ownership boundaries and are mixed and matched in different processes. Does anyone have access to one or more such managers and if so, would it be worth while to find out the type and structure of the descriptions for the activities and how they are used by the various parties in the chain? I realize that some of the descriptions are word-of-mouth, but in large multi-national companies or governments, complex processes can not be executed efficiently only by word-of-mouth. Not everything would be useful to us, but common successful strategies might be of use. Don Ken Laskey wrote: > Frank, > > The assumption is that most of the nuts & bolts description, e.g. > WSDL, comes from the service provider. If *Mart twists the provider's > arm to do things a certain way, that may be irrelevant to other > consumers who are only interested in using what is there, not where > there came from. [Parse that carefully ;-) ] > > As for consumer input, that is why I included Annotations. > > As for Authoritative, that is why the model for associating > description values has a spot for who authored the value. Given that > information, it is up to the consumer to decide what is authoritative. > > Ken > > On Oct 16, 2007, at 12:08 PM, Francis McCabe wrote: > >> Ken & Michael >> Is a description of a service that was *not* originated by the >> *owner* of the service not still a description of the service? >> This might be thought of as a corner case, but in fact is far from >> that. It is not always the case that the owner of a service is the >> stronger partner: the consumer may be; the classic example of which >> is *Mart where the buyer in the supply chain dictates: you *shall* >> offer a service whose description is ... >> >> Similarly, the manageability description of a service may have >> nothing to say to consumers of the service; but is also a description >> of the service. >> >> Once you open your mind, it is easy to see lots of potential >> examples here. >> >> On the other hand, it may be a good idea to borrow from DNS the idea >> of the *authoritative* description; but that authority would have to >> be qualified: "this description is authoritative for the purposes of >> using a service" (or whatever) >> >> Frank >> >> On Oct 16, 2007, at 8:27 AM, Ken Laskey wrote: >> >>> Michael, >>> >>> I see your discomfort and if all we had were multiple, independently >>> generated descriptions, this would certainly lead to ambiguity and >>> contradiction. >>> >>> I have often talked about a service description as being a table of >>> contents, so less than the source of many description elements, it >>> is the collection points of things created for other, related >>> purposes. For example, I do not see writing policies into each >>> service description but I see those with expertise in rules systems >>> developing policies in parallel and the service description author >>> would link to the existing policies. In the same way, I do not see >>> duplicating my address and phone number for every service for which >>> I am a responsible party, but I do see a link to the resource where >>> my contact (and possibly other personal information) is maintained. >>> >>> In this way, a different subset of possible description could be >>> emphasized for different contexts, but the subsets would leverage >>> common resources for the description elements. >>> >>> At one time, I advocated the idea of a "complete description" where >>> the description would explicitly collect the description elements >>> needed for the context but would provide other links where >>> additional description sets or description elements could be found. >>> The idea was a given description would highlight what was needed for >>> the context but there would be tendrils to the rest of the world >>> where more information resides. >>> >>> Ken >>> >>> On Oct 15, 2007, at 4:43 AM, Poulin, Michael wrote: >>> >>>> Duane wrote: "In an ecosystem of services, there could potentially >>>> be many service descriptions for a service. The service >>>> description a consumer uses may be dependent on the entity the >>>> consumer interacts with when they use the service, or it could be >>>> dependent on the particular context the service description is >>>> provided. Because of unforeseen possibilities for a service to >>>> have multiple service descriptions, I do not think the OASIS SOA RA >>>> can qualify one service to one service description." >>>> >>>> I have a lot of concerns about underlined statements. >>>> >>>> 1) Service description gets used as the service definition now. I >>>> agree that in an ecosystem not all information about the service is >>>> in the Service Descriptor. However, in this case, I prefer to >>>> recognise that I have different 'domains' in the ecosystem of >>>> services (voice, signs, UDDI, etc.) where the Service Description >>>> is the single unique one. >>>> >>>> 2) To me, the "service description a consumer uses may be >>>> dependent on the entity the consumer interacts with when they use >>>> the service" looks much more like an execution context and related >>>> Service Contract than a service description. Again, "be dependent >>>> on the particular context the service description is provided" is >>>> either services ecosystem domain specific Description or the EC and >>>> Service Contract. >>>> >>>> 3) as I mentioned before, SOA RM states that EC is not a context of >>>> service interaction only ( though in many places it says so ) but >>>> also the context of service execution per se. If we allow "a >>>> service to have multiple service descriptions" (w/o defining >>>> concrete conditions where it is possible), we have to clearly >>>> distinguish it from a service to have multiple service descriptions >>>> in multiple service execution contexts - interaction and execution >>>> ones. >>>> >>>> 4) I, personally, dislike the idea of "a service to have multiple >>>> service descriptions", at least, in the same Service Description >>>> Repository. Though this is a lower level technical implementation >>>> detail, it is VERY important for practical use of SOA and quoted >>>> statement above can easily screw it, which I hate. >>>> >>>> - 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: Duane Nickull [mailto:dnickull@adobe.com] >>>> Sent: 12 October 2007 16:49 >>>> To: Ken Laskey; Scott Came >>>> Cc: soa-rm-ra@lists.oasis-open.org >>>> <mailto:soa-rm-ra@lists.oasis-open.org> >>>> Subject: Re: [soa-rm-ra] Questions on action model >>>> >>>> Concur. Look at the cardinality of WSDL. Not everything is >>>> mandatory either. On a purely logical level, consumers can use >>>> only that which they require. It is unlikley that any one service >>>> description artifact would in fact contain *all* the information >>>> required. >>>> >>>> At least some info is known via alternative mechanisms (voice, >>>> signs, UDDI, etc.) >>>> >>>> Duane >>>> >>>> >>>> On 10/11/07 6:22 PM, "Ken Laskey" <klaskey@mitre.org >>>> <mailto:klaskey@mitre.org>> wrote: >>>> >>>> The RM says >>>> >>>> The service description represents the information needed in order >>>> to use a service. In most cases, there is no one “right” >>>> description but rather the elements of description required depend >>>> on the context and the needs of the parties using the associated >>>> entity. >>>> >>>> Thus, the implication is there may be overlapping descriptions >>>> relevant to different contexts. >>>> >>>> Ken >>>> >>>> On Oct 11, 2007, at 8:08 PM, Scott Came wrote: >>>> >>>> Danny: >>>> I don't personally have a strong feeling one way or the other on this >>>> issue. I did sense the "one description" position as the subcommittee >>>> consensus, however...mostly from reading the RA 0.2 draft. >>>> Thanks. >>>> --Scott >>>> -----Original Message----- >>>> From: Danny Thornton [mailto:danny_thornton2@yahoo.com] >>>> Sent: Thursday, October 11, 2007 3:55 PM >>>> To: Scott Came; soa-rm-ra@lists.oasis-open.org >>>> <mailto:soa-rm-ra@lists.oasis-open.org> >>>> Subject: RE: [soa-rm-ra] Questions on action model >>>> >>>> Scott, >>>> >>>> Thank you for the summarization. The only statement I >>>> have an exception with is 3, A service has one >>>> description. >>>> >>>> In an ecosystem of services, there could potentially >>>> be many service descriptions for a service. The >>>> service description a consumer uses may be dependent >>>> on the entity the consumer interacts with when they >>>> use the service, or it could be dependent on the >>>> particular context the service description is >>>> provided. Because of unforeseen possibilities for a >>>> service to have multiple service descriptions, I do >>>> not think the OASIS SOA RA can qualify one service to >>>> one service description. >>>> >>>> Danny >>>> >>>> --- Scott Came <scott.came@search.org >>>> <mailto:scott.came@search.org>> wrote: >>>> >>>> >>>> Subcommittee: >>>> >>>> >>>> >>>> I'd like to take attempt a summarization of this >>>> thread. Note the word >>>> "attempt"...please let me know if I've misconstrued >>>> anything said so >>>> far. >>>> >>>> >>>> >>>> 1. The action model of a service may contain >>>> multiple actions >>>> 2. The actions in a given service's action model may >>>> produce >>>> distinct real-world effects, meaning that a consumer >>>> may choose to >>>> interact with (invoke?) some subset of actions and >>>> not others >>>> 3. A service has one description, but that one >>>> description may make >>>> specific reference to particular actions in order to >>>> describe their >>>> individual effects, and it also may specify specific >>>> policies for >>>> individual actions, though those specific individual >>>> policies can be >>>> viewed as part of one whole policy for the service. >>>> 4. The process model of a service shows how a >>>> consumer may interact >>>> with (invoke?) specific actions in sequence to >>>> accomplish some business >>>> function aligned with the service's RWE >>>> 5. There may be multiple processes in the process >>>> model, involving >>>> different sequences and different functions >>>> 6. A consumer may interact with (invoke?) a single >>>> action to >>>> achieve a particular effect (whether that is a >>>> process with one step, or >>>> no process, is an issue I suppose) >>>> 7. The mechanism by which a consumer interacts with >>>> a service is by >>>> invoking an action through message exchange; that >>>> is, the consumer and >>>> service exchange information (in the form of a >>>> message) to achieve some >>>> effect >>>> 8. Interaction with different actions can be by >>>> different MEPs >>>> 9. The decision about service boundaries-which of >>>> all possible >>>> actions should be in a given service's action >>>> model-can be productively >>>> guided by a set of design principles, which the RA >>>> may include at some >>>> future time. Principles should be carefully and >>>> precisely defined. >>>> >>>> >>>> >>>> The example again is an Employee Time Management >>>> service. The action >>>> model of this service might consist of four actions: >>>> add time records, >>>> update existing time records, delete time records, >>>> and view time >>>> records. A process model for this service may, for >>>> example, indicate >>>> that it makes sense to view time records prior to >>>> updating them. But, >>>> it is also possible to add time records in >>>> isolation...without any of >>>> the other actions being involved. The overall RWE >>>> of this service is >>>> management of employee time, but each action has a >>>> separate effect of >>>> independent value to a consumer. There is no >>>> absolute rule regarding >>>> whether it makes sense to include all four of these >>>> actions in one >>>> service-without more analysis, it is not clear >>>> whether this is a "good" >>>> service model or not. However, there are some >>>> design principles that an >>>> architect (creator of a concrete architecture) can >>>> apply in making this >>>> determination: loose coupling, statelessness, >>>> autonomy, abstraction, >>>> etc. >>>> >>>> >>>> >>>> Thanks. >>>> >>>> --Scott >>>> >>>> >>>> >>>> ________________________________ >>>> >>>> From: Ken Laskey [mailto:klaskey@mitre.org] >>>> Sent: Thursday, October 11, 2007 11:09 AM >>>> To: Scott Came >>>> Cc: soa-rm-ra@lists.oasis-open.org >>>> <mailto: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 >>>> >>>> >>>> === message truncated === >>>> >>>> >>>> >>>> >>>> ________________________________________________________________________ >>>> ____________ >>>> Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's >>>> updated for today's economy) at Yahoo! Games. >>>> http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow >>>> >>>> >>>> >>>> ----------------------------------------------------------------------------- >>>> 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 >>> >>> >>> >>> >> > > ----------------------------------------------------------------------------- > Ken Laskey > MITRE Corporation, M/S H305 phone: 703-983-7934 > 7151 Colshire Drive fax: 703-983-1379 > McLean VA 22102-7508 > > > > -- Don Flinn President Mansurus LLC e-mail: flinn@alum.mit.edu Tel: 781-856-7230 http://mansurus.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]