Next in thread →
Next in month →
Re: [soa-rm] summary of service definition suggestions
I really concern if we go with "IT-oriented definitions" in a White Paper, in SOA-RAF or anywhere else. If SOA-RAF limits itself by "IT-oriented definitions", it will be huge step BACK regarding modern understanding of SOA in enterprises: SOA is really , day by day, getting across the boundaries of IT into Business. SOA in between is the IDEAL position and the definitions of the SOA service should follow this positioning IMO. - Michael Poulin -----Original Message----- From: Rex Brooks <> To: Francis McCabe <> Cc: Ken Laskey <>; Sent: Tue, Jul 20, 2010 1:35 am Subject: Re: [soa-rm] summary of service definition suggestions I think that Ken's suggestion of putting this discussion of notional and IT-oriented definitions of service into a White Paper that includes citing the other definitions is spot on. Let's not spend more time wrestling that alligator. I suggest we hold that discussion in a series of RM meetings separate from finishing up the SOA-RAF. I did not bother even getting started on my own hobby horse here. Suffice it to say that I will contribute it to the White Paper effort. Count yourselves lucky... for now ;-) Cheers, Rex Francis McCabe wrote: > I *was* going to ask why we are revisiting this. But then I reread the > RM; and now I think I understand. I does not meet our 'loose coupling' > criterion. > > My 2 cents (repeated from earlier discussions) > 1. There is some desire to distinguish the 'potential' aspect of > service from the 'actual' performance of service. Both senses are used > and it is therefore easy to talk at cross-purposes. > > 2. There is also the 'thick' view of service compared to the 'thin' > view. If you are a user of a service then you will see the service > 'head-on' as it where, and it becomes essentially a window onto the > capability you are trying to access. From the head-on view, you do not > really see the service itself, you only 'see' the capability -- > through a glass darkly as it were. > > From the 'sideways' view, you see the service as an entity in its own > right that needs policies, management, deployment, testing etc. etc. > This is the thick view of service: thick because there is tangible > 'stuff' between the users of service and the providers, stuff that you > need to know about. > > Again, I think that both aspects are legitimate but confusion can > reign if you do not distinguish these. > > Suggestions: > > (a) A service is an [abstract] resource that permits actors to provide > and access capabilities, together with descriptions that characterize > the capabilities and the means to access them. > > (b) A service is a coherent set of potential objectives that an actor > (or actors) are predisposed to adopt, together with descriptions that > characterize the requirements and the potential objectives. > > The second definition is, of course, informed by Section 3 :) I can > also see people scratching their heads about it. > > Frank > > > > On Jul 17, 2010, at 8:02 PM, Ken Laskey wrote: > >> All, >> I suggest you all reread the threads (see >> http://www.oasis-open.org/apps/org/workgroup/soa-rm/email/archives/201004/msg00026.html >> and >> http://www.oasis-open.org/apps/org/workgroup/soa-rm/email/archives/201004/msg00061.html >> for beginning of threads). They show an order of magnitude more >> insight than the best of other discussions. >> In an attempt to provide a starting point for the RM meeting >> discussion, I provide the following as a capture: a summary >> definition that tries to capture previous points and suggested >> changes beyond that. >> <startingPoint> >> *A service (in the context of SOA) is a capability that exposes a >> business function in the context of the following constraints:* >> - *The service is offered and packaged by a provider and made >> accessible to consumers* >> - *access is provided using a prescribed interface that abstracts (or >> hides) the implementation details of the capability or function, and* >> - *the service is exercised consistent with the contracts and >> policies as specified by its description. * >> *In general, the specifics of the business function should be known >> independent of the service that exposes it.* >> specific suggested changes: >> 1. “*access is provided using a prescribed interface, and”* and drop* >> “that abstracts (or hides) the implementation details of the >> capability or function”* >> 2. *A service (in the context of SOA) is a capability that **is >> exposed as a** business function in the context of the following >> constraints…* rather than ***exposes*** >> 3. “A service (in the context of SOA) is a business-aligned >> capability …” or more specifically, “A service (in the context of >> SOA) is a business-aligned IT capability …” >> 4. Additionally: “A capability is the ability to perform a function >> or set of functions based on expertise and capacity.” >> </ startingPoint > >> I did not try to capture discussions that did not offer specific >> wording. This is meant without prejudice to those discussions, but I >> found no way to do those justice. Also, while those discussions bring >> up important points for additional expansions, I do not think they >> materially affect the summary. >> Feel free to augment my capture. >> I look forward to reaching consensus. >> Ken >> P.S. We will also need to decide what to do with the result. At one >> point I raised the possibility “I suggest we write it up as a white >> paper that is endorsed by the TC, have it announced as appropriate by >> OASIS, and ask the TC members to include appropriate discussion of >> this in their blogs.” Other suggestions are welcome, including a new >> version of the RM. Give the possibilities some thought. >> --------------------------------------------------------------------------- >> Dr. Kenneth Laskey >> MITRE Corporation, M/S H305 phone: 703-983-7934 >> 7515 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 --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
Next in thread →
Next in month →