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