Re: [soa-rm] Definitions

[Don Flinn <flinn@alum.mit.edu>]

Hi Duane

Thanks, this was just the discussion that I hoped to initiate with my
mail.

It was pointed out to me that the submission
soa_rm_paper_matt_duane_rev.d.pdf in the Documents section has
definitions and discussion of some of some of the same terms.  While I
read it a while back I didn't bring it to mind when developing my
definitions.  My bad.  All: Please contrast my definitions with those in
the submission.

To specifics: I agree that we should press ahead.  Since I do not have
any objection to the charter definition, lets ignore mine and use the
one from the charter.  I believe that they are both saying the same
thing, only from a different prospective.

I also go along with your comments on Agent.  It's not abstract.

However, I do think that we need a distinction between the agent as an
application and the provider/requester as a human.  Also, I believe that
the concept of a message is important in the architecture.  The request
and possible reply has to be exchanged between the requester agent and
provider agent.  It might be by means of a Saint Bernard dog or any
other means such as those you have suggested but there must be a concept
of information (request/reply) that is exchanged.  Would you prefer some
other name for the information that is exchanged or is your objection
more fundamental?  Note that I agree that the message does not have to
be physical.

Don


On Thu, 2005-03-24 at 14:24 -0800, Duane Nickull wrote:
> Don:
> 
> Thank you for these initial submissions.  There are certain terms that 
> we already have defined in our charter.  For example, architecture is 
> defined as "A software architecture for a system is the structure or 
> structures of the system, which consist of elements and their externally 
> visible properties, and the relationships among them."  Although this 
> (along with everything else) is open for discussion, I would rather 
> press ahead and keep this definition for now since it is abstracted from 
> generally accepted software architecture principles and widely agreed to.
> 
> The other definitions should remain in the abstract, not concrete tense 
> when defining.  An example of how this may affect certain definitions:
> 
> Instead of:
> "Agent (requester or provider) - Concrete piece of software or hardware 
> that sends or receives messages in an SOA transaction."
> 
> An abstract tense is:
> "An entity acting on behalf of another entity to fulfill a task".  This 
> is in no way specific.
> 
> It as not even been established that messages are part of the core 
> reference model, in fact, I would state they are likely not necessary to 
> be present in all implementations.  A application's service may have a 
> binding that allows someone to submit a message to it, but that message 
> does not have to be physically sent to make the application "service 
> oriented".  Messaging , of course, is absolutely necessary when building 
> a concrete service oriented architecture.
> 
> Messaging is also not present in a transactional sense in all SOA's.  I 
> would consider Bluetooth an SOA yet it does not only employ point to 
> point-cast messaging.  It also uses broad-cast and point-to-multi-cast.
> 
> Duane Nickull
> 
-- 
Don Flinn
President, Flint Security LLC
Tel: 781-856-7230
Fax: 781-631-7693
e-mail: flinn@alum.mit.edu
http://flintsecurity.com