[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] Groups - Draft version of Discovery Section (SOARM_DiscoveryPresenceandAvailability_05-05.doc) uploaded
Joe, Wes mistakenly uploaded this to soa-rm instead of soa-rm-editors. I'd prefer if you held on for draft 07, and made comments with line and section references so that we can track issues properly. I cannot process issues that are not made against a proper draft. And before you ask...I am only waiting on a couple sections now, and we should be seeing an actual draft that you can comment on within days. Thanks, Matt Chiusano Joseph wrote: > Here are my comments on the first few sections: > > Section: “Discovery”: > > <Quote> > > Discovery, in the context of Service Oriented Architecture, is the act > of detecting, identifying, understanding > > </Quote> > > Discovery does not have to do with understanding a service – I believe > it has to do with understanding a service description (which is where > semantics come in). > > <Quote> > > and selecting a service within the constraints and boundary conditions > of a service fabric > > </Quote> > > Please define “service fabric”. > > <Quote> > > It must immediately be pointed out that it is the service description > that is discovered not the service itself > > </Quote> > > If one discovers a WSDL document that is a service description, and > that WSDL document contains a binding that has a SOAP binding with a > soap:address element that specifies the location of the service itself > (a URI), hasn’t the service itself been discovered? Not sure that > breaking this out into 2 levels really helps the reader (too much detail). > > Section: “Structured vs. Unstructured Discovery” > > <Quote> > > By and large, unstructured service descriptions > > </Quote> > > Recommend striking this entire paragraph (sorry!:). Rationale: What is > an “unstructured service description”? All service descriptions that I > know of are structured (WSDL documents, CPP/A, etc.). Do we mean > “service specifications”? If so, a service specification is not used > for discovery purposes but rather for design, development, and > implementation. > > Section: “Service Fabric Constraints” > > <Quote> > > Should a service participate in a fabric > > </Quote> > > Again, need to define “fabric” otherwise the reader cannot fully > understand what is meant by this section. No further comments provided > on this section because I am not sure what we mean by “fabric” (I am > very familiar with WebMethods “Fabric” and “Glue”, but it is not clear > that that is the concept that we mean). > > Section: “Discovery Methods” > > <Quote> > > The broadcast method for information (in our case service) discovery > is used in a number of technologies and on the Internet today with > some success > > </Quote> > > What are examples of these technologies? > > <Quote> > > For example, if an entity issues an information broadcast, > specifically a service description “push”, and the other entity > (service consumer) is not in a state capable of receiving it, the > information is not captured, cannot be acted upon, and is considered > lost. > > </Quote> > > Why can’t the information be queued in an asynchronous manner? > > <Quote> > > Accidental detection is haphazard at best and reward less at worst > > </Quote> > > Why? But primarily, what is “accidental detection”? Should define it > here before going further. > > <Quote> > > A consumer looking for a suitable service could search previously > known locations and if unsuccessful, could then search other random > locations ad infinitum. > > </Quote> > > That sounds intentional to me – the consumer intends to find a service > and is searching intently for it. > > <Quote> > > But, how does the consumer know all replies have been received and > hence the choice made the correct one? > > </Quote> > > If they are unsure they should allow more time for the replies. This > seems more like an implementation issue than an issue for our spec (?). > > <Quote> > > Intentional discovery by detection > > </Quote> > > Recommend simplifying the term and calling it “Intentional Discovery” > or “Discovery by Detection”. > > <Quote> > > is typically through a known medium > > </Quote> > > Why is this different than what is being called “accidental > detection”? The Internet can be used for accidental detection, and the > Internet is a known medium. > > <Quote> > > This method of discovery has seen support from the standards bodies > and significant investment by the industry > > </Quote> > > What standards bodies? What standards? What industry? Why be vague? > > <Quote> > > Technologies such as registries and standardized search engines > provide for well-defined query semantics > > </Quote> > > Is Google a standardized search engine? It is not clear from the > description here. If it is, does it have well-defined query semantics? > Some would say yes (search rules are made known), and some may say no > (it is not possible, for instance, to say “find me all references to > the term title, but meaning the title of a house rather than a book” > > <Quote> > > simplifying and removing the burden from the service consumer and > placing it onto a well-known entity or agent > > </Quote> > > What does “well-known” mean here? Well-known to who? > > <Quote> > > There are several competing standards that satisfy the requirements > for intentional discovery by detection each with known issues and > limitations > > </Quote> > > What are these standards? Do you mean UDDI and ebXML Registry? If so, > these are not completely competing standards. > > Next up: Section “Identification, Understanding and Matching” > Thanks for considering these, > Joe > > Joseph Chiusano > > Booz Allen Hamilton > > Visit us online@ http://www.boozallen.com > <https://webmail.bah.com/exchweb/bin/redir.asp?URL=http://www.boozallen.com/> > > > ------------------------------------------------------------------------ > *From:* mcgregor.wesley@tbs-sct.gc.ca > [mailto:mcgregor.wesley@tbs-sct.gc.ca] > *Sent:* Tue 5/10/2005 9:34 PM > *To:* soa-rm@lists.oasis-open.org > *Subject:* [soa-rm] Groups - Draft version of Discovery Section (SOA > RM_DiscoveryPresenceandAvailability_05-05.doc) uploaded > > This document needs to align with service description. > > -- Mr Wesley McGregor > > The document named Draft version of Discovery Section (SOA > RM_DiscoveryPresenceandAvailability_05-05.doc) has been submitted by Mr > Wesley McGregor to the OASIS SOA Reference Model TC document repository. > > Document Description: > Preliminary thoughts on Service Discovery. > > View Document Details: > http://www.oasis-open.org/apps/org/workgroup/soa-rm/document.php?document_id=12564 > > Download Document: > http://www.oasis-open.org/apps/org/workgroup/soa-rm/download.php/12564/SOA%20RM_DiscoveryPresenceandAvailability_05-05.doc > > > PLEASE NOTE: If the above links do not work for you, your email > application > may be breaking the link into two pieces. You may be able to copy and > paste > the entire link address into the address field of your web browser. > > -OASIS Open Administration >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]