[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] Questions on action model]
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 >> 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> 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 >> 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> 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 >> 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 > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]