Subject: RE: [soa-rm-ra] A general comment on the SOA RA
Sorry Michael, I did not mean to strike the nerve. I have noticed that the group in general is not too fond of IBM. I am not married to them either and had quite a few heated discussion, but in general, such test helps to set some boundaries and worked really well for me in a previous life. I think that the mere fact of us having this lively discussion vouch for the necessity of having some or all of this in SOA RA. Also see some comments below: -----Original Message----- From: Mike Poulin [mailto:email@example.com] Sent: Thursday, April 09, 2009 5:31 PM To: Lublinsky, Boris; Francis McCabe Cc: Estefan, Jeff A; firstname.lastname@example.org Subject: RE: [soa-rm-ra] A general comment on the SOA RA Boris, the Litmus test came with SOMA - methodology from IBM Global Services. SOMA declares that service=WebService and service=interface. After such definitions, I do not trust this methodology, sorry. The same is confirmed in the variants of the Litmus test (they are self-contradicting) >>> I am sorry, but it does not. Actually IBMers were one of the first ones saying that service is an architectural construct, while Web services is middleware often used for implementing communications. They also never said that service=interface, but rather that service is defined by interface >>> In particular, requirement of 'service stateless' is total BS (which does not stand for Business Service). Just open the T.Erl's books and read what the principle of statelessness means - a lot but stateless service. I have reviewed all SO Principles in my BLOG and received very good support: many of those principles became obsolete and I re-defined them (http://www.ebizq.net/blogs/service_oriented/2009/02/principles_of_servi ce_orientation_reviewed.php) >>> If you do not like IBM, I am not a big T Erl fan, but this aside. I will make sure to go through your post in details, but... statelessness is one of the most fundamental requirements for service scalability. Stateless service is a shorthand for stateless service invocation and means only one thing - service does not maintain conversational state - service requests are self contained and independent from each other. >>> Then, "Is the business willing to fund the service through its lifecycle" - if business is not willing to fund something, this may not be a criteria of defining the something as non-service. But, for consultants - it is the end of the deal; no deal - no service. >>> Well its more then just consulting. I have been on both sides of the isle, and if business funding is not there it is the end of the story. Period. >>> Service is self-contained - in plain English this means it can operate without help of others, i.e. it may not engage other services. It is not about deployment but about run-time behavior. One task is substituted by another one and... treated as criteria. >>> I am at disadvantage here - English is my second language(ESL) - and it still often shows. Self containment is complex and it is relevant, at least for me, through the complete service life cycle - from design through development, deployment and run time. For me, it means that all this stages service can be treated as an independent unit, which does not preclude it from using (invoking) other services - see SCA >>> If the first variant talks about self-containing, another variant talks about autonomy and composability. If a service is self-contained, it cannot be composable, i.e. cannot consist of other services. Autonomous services are non-composable as well. So, these criteria together constitute another BS. >>> Again I will hide behind ESL, but composability, to me, means the ability to participate in composition. So I do not see contradiction here. See also the previous comment >>> Talking about 4 major areas of test criteria, I cannot resist myself and should say that 1) presence of funding unrelates to the service definition. It only indicates that SOA architect did not do his/her work well <<< Its not about funding, but rather about alignment to business model. I have seen enough crappy services in my life to be a strong believer in this, >>> 2) finally, they got it - "consideration of state management aspects" instead of statelessness 3) "Externalized service description: Focusing on the presence of an external service description (such as WSDL), the ability to support service discovery and binding via the service description, and providing meta data as part of the service description" - a total mess. WSDL is NOT as service description but description of one of the service interfaces. SOA RM clearly stays this and many SOA leads agree with this ( QCon-2009 confirmed this in full, ask Stefan Tilkov). Service Description does not deal with binding, this is the interface's 'business' >>> I think I can't convince Stefan, he as all Rested, aka no interface just URL, but I still like working with him. Lets agree that external service description is necessary. Then I would argue that it consist of several important parts: Business description - definition of service functionality Interface data model - definition of service parameters and their business meaning Pre/Post conditions for service methods Technical description for implementing service invocation (possibly WSDL) >>> 4) "Redundancy elimination" and reuse require special explanations; reuse does not eliminate redundancy. Service reused not when it used in pre-defined Execution Context many times but when it used in different context. Redundancy may be necessary for business services in the form of redundant access to the business functionality. Such redundancy forks for business continuity that business services (implementing business functions) must preserve. >>> Yeh, I am with you here. I do not care about reuse, it's over rated. As for redundancy elimination - I am a big fan. The way I see redundancy although is slightly different. I see service implementation separating cleanly business functionality from communication support. We have the same service being invoked using, JMS, SOAP, Rest and POX. This is fine, all interface handlers invoke the same business service implementation and this is important. >>> I do appreciate the IBM's attempt in setting a formal test for defining 'service' but particular attributes of current Litmus test compromise and undermine the value of this initiative. - Michael > ----- Original Message ----- > From: "Lublinsky, Boris" <email@example.com> > To: "Francis McCabe" <firstname.lastname@example.org>, "Lublinsky, Boris" <email@example.com> > Cc: "Estefan, Jeff A" <firstname.lastname@example.org>, email@example.com > Subject: RE: [soa-rm-ra] A general comment on the SOA RA > Date: Tue, 7 Apr 2009 08:35:54 -0500 > > > Frank, > There is no such thing as useless calculations. On another hand there is > a lot to be said about usefulness of a service. > For example, there is a definition of a service Litmus test in > http://www.gse-nordic.org/Working%20Groups/WebSphere/Conferences/2006/ri > ga_presentation/d2t4s1.pdf > Business Alignment: The service must be traceable back to a business > task or goal or it may not yield benefits required for SOA > implementation. > 1: Does the service provide a required business functionality that > supports business processes and goals? Is there a business goal that > this service directly (versus "inherits" from its children) supports? > 2: Is the business willing to fund the service through its lifecycle: > provisioning, management, governance, and maintenance? > 3: Is the business willing to share the service internally or externally > with clients or business partners? For example, implications may be > additional costs, business secrets, security, and so on. > Composability: Composability is defined as an attribute that enables the > service to participate in a service composition. > 1: Does the service meet the required QoS attributes as defined in the > composition's NFRs? > 2: Is the service stateless? > 3: Is the service self-contained? (Can it be deployed independently to > meet a business goal although it may cooperate with other services at > run-time to perform business processes? There are no implicit > dependencies of the service on other embedded functionality. All > dependent services are either replaceable or self-contained.) > 4: Is the service's implementation technology neutral? Technology > neutral means that the service does not impose support of non-standard > (and unknown to the consumer) protocols or devices; for example, the > constituent component requires intervention through a non-standard > application interface. > > Another variation of Litmus test - > http://ea.typepad.com/enterprise_abstraction/2006/08/service_litmus_.htm > l > > Essentially, ask the questions, is (or can) the component in question > be: > > * stateless > * discoverable > * autonomous > * loosely coupled > * composable > * abstract > > If the answer to any of these is no, then you probably are not looking > as something thats an appropriate service. > > And finally from > http://www.ibm.com/developerworks/websphere/techjournal/0706_col_simmons > /0706_col_simmons.html > > The Service Litmus Test is a defined set of criteria to resolve whether > a candidate service should be exposed. The criteria fall into four major > areas: > > 1.Business alignment: Focusing on business relevance of the service, > the presence of a funding model to support development and maintenance, > and the ability to share the service across the organization. > 2.Composability: Focusing on consistency with non-functional > requirements at the composite level, consideration of state management > aspects, identifying service dependencies, and supporting > technology/platform neutrality. > 3.Externalized service description: Focusing on the presence of an > external service description (such as WSDL), the ability to support > service discovery and binding via the service description, and providing > meta data as part of the service description. > 4.Redundancy elimination: Focusing on the ability to reuse the > candidate service across multiple composite scenarios where the specific > function is needed. > > Through this set of questions and optional extensions and > customizations, as appropriate for the specific organization, the design > team can make appropriate architectural decisions regarding which > services should be developed, exposed, and managed as service > implementations. > > > > -----Original Message----- > From: Francis McCabe [mailto:firstname.lastname@example.org] > Sent: Monday, April 06, 2009 9:25 PM > To: Lublinsky, Boris > Cc: Estefan, Jeff A; email@example.com > Subject: Re: [soa-rm-ra] A general comment on the SOA RA > > Boris > The calculation performed by turbotax is a great deal more than > 'mere' calculation -- the entire business model is predicated on this. > In any case, I challenge you to introduce a meaningful dividing line > between meaningful calculations and meaningless calculations. > Anyone can say "I pronounce you man and wife", but only in certain > situations does it convey a real world effect. > Frank > On Apr 6, 2009, at 5:55 PM, Lublinsky, Boris wrote: > > > Jeff, I looked quickly through the previous version and did not find two > > much changes, compared to the current one. Yes you renamed the > > viewpoint, but it even in the previous version, the word business was > > there as just a name. The content was very similar to what it is now: > > > > "View focuses on what a SOA-based system means for people using it to > > conduct their business.9 The mode of business in a SOA-based system is > > characterized in terms of providing services and consuming services to > > realize mutually desirable real world effects." > > The word real world effect is vague enough to mean anything. Besides, > > and here is a kicker, service invocation does not really have to create > > a real world effect to be useful. Here is an example of using Turbotax > > service online (very appropriate timing wise). When you use this > > services you submit your financial documents and receive back the amount > > of tax that you owe or government owes to you. This is quite useful > > service, but a pure calculational one. It does not change anything in > > the world - just massage numbers. One can of course, say that returning > > back a tax amount is a real world effect, but is it really? And there is > > quite a few services like that, for example, calculating insurance > > quote. On another hand, if I am using a banking service to do money > > transfer, this one has a true real world effect - amounts are changing > > in my accounts. But I consider all of these service useful services. > > Now let's take a notorious example of temperature converter. From the > > outside it seems like a valid service, but in reality you will rarely (I > > think never) use this service in your SOA implementation. The reason is > > twofold: > > - I would be hard pressed to consider this one a useful business > > service; > > - The granularity of this one is so low, it does not make sense. > > So if I am developing SOA I need to know: > > -what constitutes a good service? > > -how do I ensure that my services are aligned and supporting my > > business? > > -how do I decide, which services makes sense for my business? > > -Do I grow my services organically - bottom up or do I try to develop > > overall enterprise model - top down. > > > > I think that in order for RA to be successful this considerations should > > be part of the document, even if they are just asked, not necessary > > answered. There is plenty of sources concentrating on this issues. > > > > -----Original Message----- > > From: Estefan, Jeff A [mailto:firstname.lastname@example.org] > > Sent: Monday, April 06, 2009 12:20 PM > > To: email@example.com > > Subject: RE: [soa-rm-ra] A general comment on the SOA RA > > > > Folks, > > > > Here is a link to our Public Review Draft 1 (PDR1) version of the RA > > released almost a year ago (I can hardly believe it!): > > > > http://docs.oasis-open.org/soa-rm/soa-ra/v1.0/soa-ra-pr-01.pdf > > > > In it, you will see the former name of the first viewpoint and > > associated view, which was referred to as the "Business via Services" > > viewpoint/view. It was renamed to the "Service Ecosystem" > > viewpoint/view based on feedback from the tutorial given at last year's > > OASIS Symposium and post subcommittee discussions. I would encourage > > you to have a look at the content of the former viewpoint reflected in > > PRD1 to if the spirit of the message has been lost given all the changes > > that have been made this past year; far too many in my opinion. I think > > we strayed from the 'business' focus of that viewpoint/view into a far > > too an abstract perspective leveraging the ecosystem concept. Those of > > you on the subcommittee already know that I have expressed my opinion on > > this matter a number of times. I think what Frank had captured in the > > PRD1 variant was closer to the mark but too many folks taking shots at > > it have muddled the message. Once again, I suggest it is time to > > re-assess. Wasn't that an action item a few months back? We simply > > dropped it. Shame on us. > > > > Finally, we need to be very clear about the distinction between the > > organizational principle of "service orientation" versus SOA. I see a > > lot of the former in the recent threads. > > > > Cheers... > > > > - Jeff > > > > > > > > --------------------------------------------------------------------- > > 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 > > > > > > > > The information contained in this communication may be > > CONFIDENTIAL and is intended only for the use of the > > recipient(s) named above. If you are not the intended > > recipient, you are hereby notified that any dissemination, > > distribution, or copying of this communication, or any of its > > contents, is strictly prohibited. If you have received this > > communication in error, please notify the sender and > > delete/destroy the original message and any copy of it from your > > computer or paper files. > > > > --------------------------------------------------------------------- > > 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 > > > > > > The information contained in this communication may be CONFIDENTIAL > and is intended only for the use of the recipient(s) named above. > If you are not the intended recipient, you are hereby notified that > any dissemination, distribution, or copying of this communication, > or any of its contents, is strictly prohibited. If you have > received this communication in error, please notify the sender and > delete/destroy the original message and any copy of it from your > computer or paper files. > > --------------------------------------------------------------------- > 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 > -- Be Yourself @ mail.com! Choose From 200+ Email Addresses Get a Free Account at www.mail.com The information contained in this communication may be CONFIDENTIAL and is intended only for the use of the recipient(s) named above. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please notify the sender and delete/destroy the original message and any copy of it from your computer or paper files.