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

["Lublinsky, Boris" <boris.lublinsky@navteq.com>]

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:mpoulin@usa.com] 
Sent: Thursday, April 09, 2009 5:31 PM
To: Lublinsky, Boris; Francis McCabe
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 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" <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



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.