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:
http://flintsecurity.com
