[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] Metadata
+1 Michael At 01:50 PM 9/28/2005, Frank McCabe wrote: >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]