[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] [Quick Afterthought on Instantiation] RE: [soa-rm] for discussion - additional suggested changes to PR1 (Part 1)
Certainly, but I would definitely say that
instantiation is a topic for an RA rather than the RM. In some architectures,
instantiation may be a non-event… -matt From: Chiusano Joseph
[mailto:chiusano_joseph@bah.com] Regarding our discusison of instantiation below and in
previous e-mails for this thread: I wonder if for SOA (and particularly how we define it in
our spec), "instantiation" could be represented by those actions that
are taken in order to establish the execution context - e.g. establishment of
contracts/agreements, infrastructure capabilities, etc. Just a quick thought. Joe Joseph Chiusano Associate Booz Allen Hamilton O: 202-508-6514
C: 202-251-0731 Visit us online@ http://www.boozallen.com From: 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: 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. --- MITRE Corporation,
M/S H305 phone: 703-983-7934
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]