I don't believe that trying
to change the scope and focus of our work more than halfway through, and when
the scope and focus have been discussed and debated at great length prior to
your joining our TC, is very wise or productive, or respectful of the work that
has been done to date. I recommend you go back through our archives and meeting
minutes to understand the background behind our decisions before trying to
suggest changes of this magnitude.
Joe
From: Jones, Steve G
[mailto:steve.g.jones@capgemini.com] Sent: Wed 9/28/2005 7:09
AM To: Chiusano Joseph; soa-rm@lists.oasis-open.org Subject:
RE: [soa-rm] Metadata
I don’t think that the
_document_ says that at all, the
examples are mostly non-software. My point is that by scoping to software
only it loses its power as a reference model, it might be pedantic but focusing
means that is where we are concentrating our effort, while “scope” means
limiting our domain. I’ll raise the element as an issue, if we change from
scope to focus then I think this better reflects the overall document which
covers both software and non-software services rather well
IMO.
Steve
From: Chiusano Joseph
[mailto:chiusano_joseph@bah.com] Sent: 28 September 2005 12:00 To: soa-rm@lists.oasis-open.org Subject: RE: [soa-rm]
Metadata
Saying that we are
scoping to software architecture is different than saying "SOA is purely a
software thing". To be more direct, I believe that your impression that we are
saying that "SOA is purely a software thing" is completely
wrong.
From: Jones,
Steve G [mailto:steve.g.jones@capgemini.com] Sent: Wed 9/28/2005 6:57 AM To: Chiusano Joseph;
soa-rm@lists.oasis-open.org Subject: RE: [soa-rm]
Metadata
Line 28, top of page
2
“This Reference Model
scopes itself to the field of software architecture”
On my list too
J
I’d like to see us also
include services that are provided by non-technology means, the reason for that
is it makes models more complete and also helps when turning something from
manual into automated as you’ve already identified it as a service (e.g. paper
based timesheet “service” is replaced by desktop application, SLA remains the
same but the interface has changed).
Steve
From: Chiusano Joseph
[mailto:chiusano_joseph@bah.com] Sent: 28 September 2005 11:51 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.
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.
|
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.
|
|