[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] Metadata
Cool - this list was getting boring. Glad we are waking up ;-) Three things in life are for sure: death, taxes and Frank challenging my perspectives on SOA (which is generally a good thing) ;-) I think your point #4 is what I tried to say and have no contention with it. I also agree with #1 but only when it does not violate the principles of RM WRT RA (I think we all see eye to eye on this). #2 - not sure what you mean here. Can you elaborate? #3 - I can see your point but feel we have to be very careful to avoid being perceived as making implementation choices in the RM. You are right - degrees more than absolutes. I am confident that the final product will represent a good balance. #5 - I think we have already placed RFC2119 within our spec (line 129~). I did make a mistake however - RFC 22119 keywords SHOULD NOT be used in "non normative" text since it negates their impact. I guess this is an issue for the editors to first note, then the TC to discuss further. Will be interested in hearing how it turns out. Duane -----Original Message----- From: Frank McCabe [mailto:frank.mccabe@us.fujitsu.com] Sent: Wednesday, September 28, 2005 10:50 AM To: Duane Nickull Cc: Chiusano Joseph; soa-rm@lists.oasis-open.org Subject: Re: [soa-rm] Metadata Duane: I need to respectfully disagree here about your conclusions. 1. It is important that we qualify our descriptions -- since they are so clearly important to SOA. 2. It might seem obvious to us that all descriptions are somehow intended to be germaine to the service's use; but this is not actually a foregone conclusion. It needs to be clarified. 3. There is clearly a role for machine processable descriptions in the automation of SOA-based systems. This is not the same as delving into implementation, however. 4. *All data*, including descriptions, eventually rests on human interpretation. Even the apparently obvious snippet: <type>integer</type> relies on a pre-agreed interpretation that the string "integer" refers to the type *integer* that refers to the class of numerals that has some kind of correspondence to the Java type int. It might seem pedantic to stress this, but it strikes at the heart of distributed systems crossing ownership boundaries: all data must rest on pre-agreed interpretations. Normally at multiple levels. The difference between <desc>blue sky</desc> and <interface><input><type>integer</type></input></interface> is only that the level of pre-agreed interpretation for the second is such that it supports more automation than the first. It is all a matter of degree; not of absolutes. However, given that support for automation is a required benefit for SOAs, it seems reasonable to (i) bring the spectrum to the reader's attention and (ii) to call out the machine processable end of things in particular. For better or worse, the term metadata seems to be associated with this machined end of the spectrum; and hence the use of the term. 5. The language of MAY, SHOULD and SHOULD NOT does not seem appropriate for a reference model. We are primarily identifying the important concepts -- we are not, on the whole, establishing best practice. This is, of course a delicate mine field of it own :) Frank On Sep 28, 2005, at 10:17 AM, Duane Nickull wrote: > 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. > > > > Joe > > > > 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. > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]