Re: [soa-rm] comments collected from SOA-RM presentation

[Danny Thornton <danny_thornton2@yahoo.com>]

Ken, thanks for sending the comments.  I've provided a
few more inline comments.

On Mar 26, 2006, at 6:41 PM, Ken Laskey wrote:

>>
>>
>> 1.  As expected, there was considerable discussion
on how SOA is  
>> different, especially how it relates to OO.  Some
points from  
>> emails, real-time discussions, and after
discussions for  
>> consideration in expanding our discussion in the RM
follow.
>>
>> - 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.

Frank McCabe Responded:

>There are some hidden assumption in OO that do not
show up in the  
>promotional literature. I agree that the "what is an
X?" question  
>often dominates and it can get heated. But, I would
say that OO  
>started out as a programming paradigm; SOA starts out
as a  
>architectural paradigm.


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

In support of Ken and Frank's comments, SOA is as much
an evolution (or more so) to OO as OO was an evolution
to procedural style APIs.  Procedural style APIs focus
on the natural ability to solve problems via a
functional process, how do I get from point A to point
B.  OO focuses on combining concepts in the form of
objects containing data and methods which helps solve
the problem of how do I get from point A to point B in
a way that will also be good to get to point C.  
However, OO evolved prior to the common distributed
computing environments that we have today.  Enterprise
tiered architectures demonstrated that combining
methods with data between tiers worked against
scalability and loose coupling of the enterprise
system, thus the use of data transfer objects between
tiers and the focus on the data model for
communication between tiers of the enterprise system. 


Up to the year 2000, individual computing systems
remained relatively self-sufficient.  The pre SOA
tiered enterprise architectures and implementations
did not provide a good solution for computing
specialization and computing interdependence at a
business or government level.  SOA exploded from the
evolution of the tiered enterprise architectures and
pressures to provide specialized B2B and G2B
interoperability.  Only under the realm of SOA are the
concepts of Visibility, Service Descriptions,
Interaction, Contracts and Policies, Real World
Effects, and Execution Contexts combined to provide
the architectures and implementations for the
automated computing needs of modern consumer/producer
relationships.  IMO, SOA is the first computing
architecture that lays the groundwork for the
industrialization of computing systems.


>> 6. There was a question whether an SOA service had
to be network- 
>> accessible.  What if all the services are on the
same machine?   
>> What if the data transfer was sneaker-net on a
floppy?  The essence  
>> of my response (and later thought) was that
everything on the same  
>> machine and specifically designed just to be on the
same machine is  
>> not SOA.  Everything can be on the same machine as
an  
>> implementation but it should have been designed
with the idea that  
>> it could be distributed and the parts could be
owned by different  
>> entities.  As far as sneaker-net, that is a data
transfer  
>> capability that may be brought to bear through a
service  
>> interaction, but it is an implementation that is
opaque to the  
>> requester.

>I think that, technically, you can go back to a
single computer  
>system and ask if its SOA-like. But this is where the
hidden  
>assumptions start to show up again. If you build a
system that is  
>intended to be used in a single machine then you are
not likely to  
>follow the constraints and approaches suggested by
SOA. You are  
>likely to take advantage of the fact that 'everything
is close at  
>hand'; and, as soon as you do that you will probably
stray away from  
>the SOA approach.

During the process of defining services for high
assurance information sharing systems, the services
were thought of in such a way that they could be
distributed around the world or reside on a single
device the size of a thumb drive.  I see the question
of a SOA service having to be network-accessible as an
implementation detail. At the architectural level,
there does not have to be a distinction or
qualification about which environment a service may
execute in.

Danny



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