[Top] [All Lists]

Re: [ontolog-forum] The Open Group SOA Ontology

To: Duane Nickull <dnickull@xxxxxxxxx>
Cc: "[ontolog-forum]" <ontolog-forum@xxxxxxxxxxxxxxxx>, Toby.Considine@xxxxxxxxx
From: Ed Barkmeyer <edbark@xxxxxxxx>
Date: Thu, 17 Jul 2008 18:34:40 -0400
Message-id: <487FC900.4000903@xxxxxxxx>
Duane,    (01)

I don't think we disagree, but we are definitely talking about different 
levels of abstraction.    (02)

you wrote:    (03)

> There are other differences between SOA and OO.     (04)

I fully agree.    (05)

> For starters, OO is a programming level paradigm     (06)

I can agree with that at one level.  I pulled out of "object-oriented X" 
three of the 4 facets that are commonly ascribed to "OO X" for all X: 
encapsulation and interface, instantiation, inheritance (subsumption). 
They all apply to many design concepts above program text.  Only 
"polymorphism" doesn't.    (07)

BTW, 10 years ago, your statement would have gotten a lot of negative 
feedback from the "object-oriented XYZ" crowd.  Fortunately, that fad 
has passed.    (08)

> while SOA is an architectural plane model.     (09)

Agree.  Apples and oranges.  (They are a bit closer than cheese and chalk.)    (010)

> True­ OO impact application architecture but generally, the consensus I have
> seen tends to be that SOA has a higher scope than any single application.     (011)

This seems to compare unrelated facets of different things.    (012)

> I donąt think it serves the community to mix the two up as they are meant for
> different areas of focus.    (013)

I doubt that anyone will confuse them.    (014)

> Another difference is at runtime, objects typically need be be instantiated
> and instrinsic knowledge of a specific environment is required.    (015)

I hope you aren't trying to say that this is not true of SOA services at 
"runtime".  A service must also be "instantiated" by an agent in a 
specific environment.    (016)

>  Consistent with REST principles, Services lie
> in a state of readiness (assuming request-response patterns) and do not need
> to be explicitly constructed by some known factory method.     (017)

How and when a service or object is instantiated is an implementation 
issue.  But both do have to be instantiated.    (018)

   javaw <class> <operands>
is a service request, and the <class> byte-code lies in a state of 
readiness in some folder on the hard-drive until that request is issued. 
  Whether the JVM actually uses "factory methods" to instantiate the 
object that is the running service implementation is beneath my concern.    (019)

And my secretary is placed at her desk by a "factory method" called the 
hiring process, but she "lies in a state of readiness" doing the 
administrivia of the day when the telephone rings and she answers it.    (020)

The principles are the same.  The implementations are ravens and writing 
desks.    (021)

> SOA focuses on
> additional concepts required to make interactions possible on larger than
> single application scopes such as visibility, reachability, service
> description, interaction models, behavior models, real world effects etc.    (022)

Yes.  It is a distributed systems architecture, lately (and not yet 
profitably) coupled with ideas like behavior models.    (023)

> Now this can be argued both ways and it gets a little hard to quantify where
> the exact lines are drawn.  Some principles of OO and SOA are, at some level
> of abstraction, highly alike IMO.    (024)

Indeed.  But you seem to have a very "implementation-oriented" view of 
OO.  Object-orientation is a design paradigm (and not always the best 
one) that happens to have a variety of supporting programming languages 
(from Smalltalk to LISP CLOS to Java and C++ to Ada), which have diverse 
implementation paradigms.    (025)

> One other aspect of SOA that is often ignored is the
> łother-than-request-response˛ interaction patterns. I have published a white
> paper here to try and help people think beyond RR.     (026)

I will look at this paper because I am suspicious.    (027)

With all due respect, I think the request/response interaction paradigm 
is fundamental to "service-oriented".  As discussed in other venues, the 
actual technical interaction can be more complex than request/response, 
but the fundamental paradigm cannot be.    (028)

The nature of a service is that it is advertised and it is requested and 
it is delivered (or not) in response to a request.  It does not 
materialize spontaneously, it does not materialize as an autonomous 
response to an event, and it is not ongoing with occasional interactions 
with other activities.  Both the client and provider roles must be 
filled and are distinguished, and the concept of "delivery" or 
"fulfillment" is well-defined and is the responsibility of the provider.    (029)

But the message protocol that precedes or constitutes or follows a 
request is "a lower level concern".  I can call 911 and engage in six 
question and answer messages that together constitute "making a 
request".  And I can have a service whose delivery involves notifying me 
whenever my silent burglar-alarm is tripped over a 12-month contract period.    (030)

The relationship between a service-oriented interaction pattern and a 
messaging pattern is not well-defined.  The "technical SOA" webservice 
pattern is: one request message, one webservice implementation, one 
response message (out of several choices of response).  But a business 
service could involve 10 of those, or none, or some other pattern entirely.    (031)

-Ed    (032)

Edward J. Barkmeyer                        Email: edbark@xxxxxxxx
National Institute of Standards & Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Stop 8263                Tel: +1 301-975-3528
Gaithersburg, MD 20899-8263                FAX: +1 301-975-4694    (033)

"The opinions expressed above do not reflect consensus of NIST,
  and have not been reviewed by any Government authority."    (034)

Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/  
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/  
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/ 
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx    (035)

<Prev in Thread] Current Thread [Next in Thread>