Re: [soa-rm] for discussion - additional suggested changes to PR1 (Part 1)

[Danny Thornton <danny_thornton2@yahoo.com>]

One idea for a rewording of

* To use an object, it must first be instantiated
while one interacts with a service where it exists.

is

* Object operations are provided for the object's
execution environment.  For SOA, service data can pass
from one execution environment to the next without
being bound to a specific implementation of an
operation.

Someone can articulate this more eloquently than me,
but basically I am trying to capture a methods/data
difference between OO and SOA. The following is my
perspective on this difference:

public class Foo { 
     private String name; 
      public String getName() { 
             loadNameFromSomewhere();
               return this.name; 
      } 
} 

In OO and technologies like Corba and DCOM - the
execution code of the object/component methods is
inseparable from the object/component thus
contributing to object/component opaqueness (black
box).  In a distributed environment based on Corba or
DCOM, the specialized behavior of getName must be
distributed to each execution environment that
provides Foo.  This results in business logic having
to be executed not once, but in all of the distributed
environments for Foo.   Implementing the business
logic for Foo in all of the distributed environments
works against scalability. J2EE tiered architectures
and SOA alleviate having to pass specialized
implementation behavior from one environment to the
next by focusing on the data model being passed
between tiers/environments.  The J2EE data transfer
object is equivalent to the SOA information model.  In
J2EE tiered architectures, the DTOs can travel from
the business tier (implementation of business logic),
through the presentation tier (no implementation of
business logic), to the client.  In SOA, the
information defined in the information model can pass
from the service provider (implementation of a
capability), through 0 or more intermediaries and then
to the consumer.  The SOA intermediaries may route the
data and/or provide capabilities in addition to the
original service provider.  

A key concept to capture for SOA is that data flows
from one execution environment/tier to the next but
functional behavior does not.  

Danny


--- Ken Laskey <klaskey@mitre.org> wrote:

> see inline (and hopefully address subsequent emails
> on this this)
> 
> On Apr 12, 2006, at 3:02 PM, Metz Rebekah wrote:
> 
> >
> > A couple of thoughts on the OO/SOA comments.
> > ________________________________________
> > From: Ken Laskey [mailto:klaskey@mitre.org]
> > Sent: Saturday, April 08, 2006 6:07 PM
> > To: SOA-RM
> > Subject: [soa-rm] for discussion - additional
> suggested changes to  
> > PR1 (Part 1)
> >
> > This is the follow-up to the question I raised at
> the end of the  
> > last telecon on where to suggest other changes to
> PR1.  Many of  
> > these come over from the previous thread on
> "comments collected  
> > from SOA-RM presentation".  Hopefully, I've
> incorporated everyone's  
> > major points but I welcome the coming discussion
> to highlight any I  
> > missed ;-)
> >
> > Note, this email does not include the two points
> requiring  
> > considerably more thought:
> > - how to rephrase (rename) shared state and its
> use with real world  
> > effect in lines 277-286 and in section 3.2.3
> > - arrows and their directions in diagrams
> > These are being worked separately; hence, the
> (Part 1) in the  
> > subject line.
> >
> > 1. Suggest incorporating some of the discussion of
> differences with  
> > OO by adding to lines 218-221 as follows:
> >
> > Unlike Object Oriented Programming paradigms,
> where the focus is on  
> > packaging data with operations, the central focus
> of Service  
> > Oriented Architecture is the task or business
> function - getting  
> > something done. This distinction manifests itself
> in several ways:
> > * OO has intentional melding of methods to a given
> data object.   
> > The methods can be thought of as a property of the
> object.  For  
> > SOA, one can think of the services as being the
> access to methods  
> > but the actual existence of methods and any
> connection to objects  
> > is incidental.
> > [RLM]  Would it be fair to characterize OO as
> follows: The object  
> > (thing) is primary and all other concepts rely
> upon the object as  
> > context?
> >
> The object may not provide context because there is
> very little  
> explanation that goes with an object.  The methods
> of an object allow  
> a fixed set of operations where these operations are
> all that you can  
> do with this object and the operations, no matter
> how generally  
> useful, can only be used on that object.  While
> services may have  
> interface requirements on the objects with which it
> is prepared to  
> include in an interaction, the operation
> (capability) is more  
> generally accessible.
> > * To use an object, it must first be instantiated
> while one  
> > interacts with a service where it exists.
> > [RLM] I suggest that instantiation is strictly a
> technical  
> > implementation term here and would be better
> suited to a discussion  
> > w/in the context of a reference architecture.  
> Both this statement  
> > and the second seem to differentiate OO and SOA
> from a system  
> > design paradigm rather than an architectural
> perspective.  Maybe we  
> > need to poke a bit more at that differentiator?
> >
> Instantiation is a core concept for OO -- a class
> has no real use  
> unless it leads to an instance.  What the instance
> is and how it is  
> used is implementation but not the idea of instance
> itself.
> 
> Frank earlier made the point that a differentiator
> is OO is a  
> programming paradigm while SOA describes
> architecture.
> > * An object exposes structure but no way to
> express semantics other  
> > than what can be captured as comments in the class
> definition.  SOA  
> > emphasizes the need for clear semantics.
> >
> > Both OO and SOA are as much a way of thinking
> about representing  
> > things and actions in the world as these are about
> the specifics of  
> > building a system.  The important thing is
> understanding and  
> > applying the paradigm.  So the question is not
> "what is a service?"  
> > any more than it is "what is an object?"  Anything
> can be a service  
> > in the same way anything can be an object.  The
> challenge is to  
> > apply the paradigms to enhance clarity and get
> things done.  SOA  
> > provides a more viable basis for large scale
> systems because it is  
> > a better fit to the way human activity itself is
> managed - by  
> > delegation.
> 
> ---
> Ken Laskey
> MITRE Corporation, M/S H305     phone:  703-983-7934
> 7515 Colshire Drive                        fax:     
>   703-983-1379
> McLean VA 22102-7508
> 
> 
> 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com