[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [Quick Afterthought on Instantiation] RE: [soa-rm] for discussion - additional suggested changes to PR1 (Part 1)
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
700 13th St. NW, Suite 1100
Washington, DC 20005
O: 202-508-6514
C: 202-251-0731 Visit us online@ http://www.boozallen.com From: Ken Laskey [mailto:klaskey@mitre.org] Sent: Thursday, April 13, 2006 12:24 PM To: Metz Rebekah Cc: SOA-RM Subject: Re: [soa-rm] for discussion - additional suggested changes to PR1 (Part 1) On Apr 12, 2006, at 3:02 PM, Metz Rebekah wrote: 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. 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.
---
Ken Laskey
MITRE Corporation, M/S H305 phone:
703-983-7934
7515 Colshire Drive
fax:
703-983-1379
McLean VA 22102-7508
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]