<Quote>
A slight
misunderstanding here (and I have been through the emails and meeting minutes) I
am not suggesting that the current focus should
change
I don't see how statements such as "My point is
that by scoping to software only" (from your
earlier post) can be misunderstood by the reader...I believe the issue is on the
"sender" side. Please be much more careful as to how you phrase things in the
future, so that we don't *understand* you per the words you use to convey your
thoughts, which might not be the appropriate words to begin with. Doing so will
take us off track from our current focus, which would be
unfortunate.
Thanks in advance for your careful attention to
this.
Joe
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
A slight
misunderstanding here (and I have been through the emails and meeting minutes)
I am not suggesting that the current focus should change, just that document
as produced is more powerful than simply being limited to the software scope.
Most of the document is equally applicable to both software and
non-software services, and the examples (e.g. the Utility) often are
deliberately not based around software. I’m not advocating any changes
whatsoever beyond suggesting that in reality what has been produced has a
broader range than implied by the statement on page 2.
Apologies if people
felt I wasn’t respectful of the work done to date, I think it’s superb.
In reading the document it reads as a broad SOA-RM with a specialisation
in Software, rather than being limited solely to issues of software, this is a
much harder feat to achieve and all the better for it.
So in summary, I’m
not suggesting a change in what the group does at all, just pointing out that
(IMO) the document is of a much higher architectural value than just being a
software SOA-RM. If it would cause a massive shift to change the
word “scope” to “focus” then I won’t raise it as an issue, but I will be using
the RM document with clients, as it stands, to apply to software,
infrastructure and business service concepts, it really is very
good.
Steve
From: Chiusano Joseph
[mailto:chiusano_joseph@bah.com] Sent: 28 September 2005 12:18 To:
soa-rm@lists.oasis-open.org Subject: RE: [soa-rm]
Metadata
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.
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.
|
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.
|
|