OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

[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]