Your first paragraph is correct. We
decided to focus on this aspect of SOA and constrain it to only software architecture.
No more starbucks examples or coffee shop related research L
Within Software Architecture, the human
element is very important. Sure – an application *can* parse anything, however the decisions
based on the metadata are made by humans. Many of these are recorded as a
set of programmatic constructs that take pre-determined actions based on
parsing individual snippets of metadata (such as a Port in a WSDL instance
becoming part of an address to call a service). The philosophical
question of whether humans are involved must also consider design and
deployment phases, not just runtime.
The question is whether we use the
extraneous adjectives “machine processable” as a qualifier for “metadata”.
I would like to see it removed purely for the two reasons that A) it
doesn’t really add anything to the specification (since there are not
similar constraints that everything else must be machine processable), and B) since
it clearly places us into the implementation realm (taboo in abstract models).
If others feels we must capture this
thought somehow, perhaps a non-normative sentence directly below the current
sentence can state that:
“Note (non-normative): metadata MAY
be implemented in such a manner that applications are able to parse it and take
actions based upon the information”
Note the “MAY” since it is
clearly not a “MUST” or even a “RECOMMENDED”.
Duane
From: Chiusano Joseph
[mailto:chiusano_joseph@bah.com]
Sent: Wednesday, September 28,
2005 3:51 AM
To: soa-rm@lists.oasis-open.org
Subject: RE: [soa-rm] Metadata
I'm not certain that we state in our RM
that "SOA is purely a software thing" - if we do, I will probably be
logging an issue that that statement be removed or refined. I believe what we
say is that we are *focusing* on the software architecture aspects of SOA.
Having said that, I believe SOA is much more than software -
it is about *capabilities* that are partially (and greatly) provided/supported
by technical services (I use "technical" rather than
"software" because it sounds more general to me and more correct when
speaking at this level). SOA, in general, can definitely involve people -
consider a supply chain capability that contains a (sub-)capability for
processing purchase orders that is service-oriented (a "service-oriented capability").
That sub-capability can be supported by one or more technical services - for
example, a "purchase order service" that enables such
"operations" as "submit PO", "check PO status",
"add line item to PO", etc.
So it's about technology supporting capabilities that also
involve people. Or put another way, technology supporting capabilities that
support people.
From: Jones,
Steve G [mailto:steve.g.jones@capgemini.com]
Sent: Wed 9/28/2005 4:47 AM
To: Frank McCabe; Ken Laskey
Cc: SOA-RM
Subject: RE: [soa-rm] Metadata
I'm writing up my review notes at the moment.
But this for me is a key area
as to whether SOA is purely a software thing (as stated in the RM) or a
wider architectural approach. The example of the plug-socket I think is a
great example of a physical world SOA, but again there is no technology
(except some complex PAT) that can understand the concept of a plug-socket
and obtain power. The discovery is done by individuals in the same way as
people use ATMs.
So the question is whether, like Soylent Green, SOA contains people.
Steve
> -----Original Message-----
> From: Frank McCabe [mailto:frank.mccabe@us.fujitsu.com]
> Sent: 27 September 2005 19:21
> To: Ken Laskey
> Cc: SOA-RM
> Subject: Re: [soa-rm] Metadata
>
> Getting slightly back on topic .. :)
> The point of bringing out the machine processability aspect is that
> that *is* the intention behind the descriptions of services. An
> example of a deeply unprocessable description is "this service will
> do wonders for your X life".
> Even assuming that you can parse such descriptions, there is no
> foreseable technology that can use such a description to do discovery
> for instance.
> Frank
>
> On Sep 27, 2005, at 11:09 AM, Ken Laskey wrote:
>
> > Today we'll take on the deep meanings of SOA and tomorrow we can
> > deal with the logic of negation.
> >
> > Ken
> >
> > On Sep 27, 2005, at 2:05 PM, Chiusano Joseph wrote:
> >
> >
> >>
> >> I take that double negative as meaning that he is convinced that
> >> it *is* redundant.
> >>
> >> Joe :p
> >>
> >> Joseph Chiusano
> >> Booz Allen Hamilton
> >>
> >
> >
> >>
> >>
> >> 700 13th St. NW
> >> Washington, DC 20005
> >> O: 202-508-6514 <= new office number as of 09/19/05
> >> C: 202-251-0731
> >> Visit us online@ http://www.boozallen.com
> >>
> >>
> >>
> >>> From: Matt MacKenzie [mailto:mattm@adobe.com]
> >>> Sent: Tuesday, September 27, 2005 2:00 PM
> >>> To: Ken Laskey
> >>> Cc: SOA-RM
> >>> Subject: RE: [soa-rm] Metadata
> >>>
> >>> I'm still not convinced that it is not redundant, even with
your
> >>> great description.
> >>>
> >>> -matt
> >>>
> >>>
> >>> From: Ken Laskey [mailto:klaskey@mitre.org]
> >>> Sent: Tuesday, September 27, 2005 1:56 PM
> >>> To: Matt MacKenzie
> >>> Cc: SOA-RM
> >>> Subject: Re: [soa-rm] Metadata
> >>>
> >>> OK, Matt, then I'll attempt to define machine processibility
as
> >>> the representation of information in a standard,
referenceable
> >>> format that conveys the necessary semantics to enable a
machine
> >>> to fully utilize the information for the purpose for which
the
> >>> information was created. General use in a context outside its
> >>> original intent may require additional capabilities which are
> >>> outside the current scope of the discussion.
> >>>
> >>> Ken
> >>>
> >>> P.S. Note, I have not taken a position on whether this is
within
> >>> RM scope or not.
> >>>
> >>> On Sep 27, 2005, at 1:46 PM, Matt MacKenzie wrote:
> >>>
> >>>>
> >>>> "machine processibility" means nothing. I
vote we remove it on
> >>>> that basis. People have been equating machine
processability
> >>>> with XML as a way of promoting the XML revolution. The
nasty
> >>>> secret is that we were processing reams of information
before
> >>>> XML as well. We can build parsers for nearly any
language.
> >>>>
> >>>> Lets just remove it.
> >>>>
> >>>> -matt
> >>>>
> >>>> From: Ken Laskey [mailto:klaskey@mitre.org]
> >>>> Sent: Tuesday, September 27, 2005 1:41 PM
> >>>> To: Duane Nickull; Behera, Prasanta; SOA-RM
> >>>> Subject: RE: [soa-rm] Metadata
> >>>>
> >>>> Duane,
> >>>>
> >>>> This is also somewhat subtle. Is the (desired or
realizable)
> >>>> machine processibility of the metadata a fundamental
concept or
> >>>> is it a nice to have option for the implementer?
The former
> >>>> belongs in the RM, the latter does not.
> >>>>
> >>>> Do log it but also continue to discuss.
> >>>>
> >>>> Ken
> >>>>
> >>>> At 01:16 PM 9/27/2005, Duane Nickull wrote:
> >>>>
> >>>> I would assert that since our model is abstract, the
adjective
> >>>> "machine process-able" is overstepping the
bounds and scope of
> >>>> the spec. As soon as we say this we are being too
concrete. It
> >>>> is equally feasible that a half automated system will
rely on
> >>>> some human to look at *some* aspects of a services
metadata such
> >>>> as who the owner is or something to assure them it is
secure.
> >>>>
> >>>> Recommend we log it as an issue and propose the machine
process-
> >>>> able part be removed.
> >>>>
> >>>> Duane
> >>>>
> >>>>
> >>>> From: Behera, Prasanta [ mailto:pbehera@visa.com]
> >>>> Sent: Tuesday, September 27, 2005 9:44 AM
> >>>> To: SOA-RM
> >>>> Subject: [soa-rm] Metadata
> >>>>
> >>>>
> >>>> Is metadata == "machine process-able
descriptions"?
> >>>>
> >>>> In the 09 draft (section 2.2.3), it seems that we are
making
> >>>> that assertion.
> >>>>
> >>>> I think "machine process-able
description/information" is a
> >>>> component of it.
> >>>>
> >>>>
> >>>> Opinion/thought?
> >>>>
> >>>> (NOTE: This is not a formal issue against _09 draft).
> >>>>
> >>>> Thanks,
> >>>>
> >>>> /Prasanta
> >>>>
> >>>> --
> >>>>
> >>>>
-------------------------------------------------------------------
> >>>> --------------
> >>>> / Ken
> >>>>
Laskey
\
> >>>> | MITRE Corporation, M/S
H305 phone: 703-983-7934 |
> >>>> | 7515 Colshire Drive
fax:
> >>>> 703-983-1379 |
> >>>> \ McLean VA
> >>>>
22102-7508
/
> >>>>
> >>>> -------------------------------------------------------------------
> >>>> ---------------
> >>>>
> >>>>
> >>>
--------------------------------------------------------------------
> >>> ----------------------
> >>> Ken Laskey
> >>> MITRE Corporation, M/S H305 phone: 703-983-7934
> >>> 7515 Colshire
Drive fax: 703-983-1379
> >>> McLean VA 22102-7508
> >>>
> >
> >
----------------------------------------------------------------------
> > --------------------
> > Ken Laskey
> > MITRE Corporation, M/S H305 phone:
703-983-7934
> > 7515 Colshire Drive
fax: 703-983-1379
> > McLean VA 22102-7508
> >
This message contains information that may be privileged or confidential and is
the property of the Capgemini Group. It is intended only for the person to whom
it is addressed. If you are not the intended recipient, you are not
authorized to read, print, retain, copy, disseminate, distribute, or use
this message or any part thereof. If you receive this message in error,
please notify the sender immediately and delete all copies of this message.
|