RE: [soa-rm-ra] A general comment on the SOA RA

["Mike Poulin" <mpoulin@usa.com>]

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)

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_service_orientation_reviewed.php)

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.

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.

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.

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

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" <boris.lublinsky@navteq.com>
> To: "Francis McCabe" <frankmccabe@mac.com>, "Lublinsky, Boris" <boris.lublinsky@navteq.com>
> Cc: "Estefan, Jeff A" <jeffrey.a.estefan@jpl.nasa.gov>, soa-rm-ra@lists.oasis-open.org
> 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:frankmccabe@mac.com]
> Sent: Monday, April 06, 2009 9:25 PM
> To: Lublinsky, Boris
> Cc: Estefan, Jeff A; soa-rm-ra@lists.oasis-open.org
> 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:jeffrey.a.estefan@jpl.nasa.gov]
> > Sent: Monday, April 06, 2009 12:20 PM
> > To: soa-rm-ra@lists.oasis-open.org
> > 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