[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ebsoa] Does SOA Require Registry-Based Dynamic Discovery?
Abstract = concept of mechanism to advertise and discover services
Concrete = registry
;-)
Rajal Shah wrote:
> I agree that SOA-RM should include a function for a registry.
>
> My assumption though is that the registry is for offline discovery and
> it be a reference system to obtain relevant information of services.
> For dynamic (by which I mean runtime) discovery of a service and to
> actually invoke the service, more than likely you would need an SLA
> (Service-level agreement) to be in place prior to the consumer
> accessing the service.. (there will be a lot of free services which
> don’t require the SLA but those would also not guarantee performance,
> uptime etc. to make it part of a serious business workflow).
>
> SOA allows new customers to access services without having the
> provider to support it through custom integration.. But the provider
> would still want to control usage of the service and that will be
> dictated through a manual process of getting the SLA agreed upon by
> all parties before allowing/obtaining access. This manual process of
> SLA seems to the reason why a lot of folks don’t see the requirement
> of the registry product as absolutely essential, but as a nice to have
> feature.
>
> Thus a registry solution is convenient to discover and advertise the
> availability of services.. It is an optional function for SOA. (I am
> looking for ways to make it essential too, but cannot convince
> customers to purchase a registry component).
>
> --
> Rajal
>
> ------------------------------------------------------------------------
>
> From: tmathews@lmi.org [mailto:tmathews@lmi.org]
> Sent: Wednesday, December 15, 2004 12:58 PM
> To: yunker@amazon.com; chiusano_joseph@bah.com; mattm@adobe.com;
> ebsoa@lists.oasis-open.org
> Subject: RE: [ebsoa] Does SOA Require Registry-Based Dynamic Discovery?
>
> This discussion sounds like its coming from a service/application only
> perspective. We need to scope the SOA RM very carefully. If we are
> looking for a SOA RM that can be applied in any domain, then I am
> still not a proponent of calling it an 'SOA' RM. If I apply all
> components of the SOA reference model, then I have an SOA, right? The
> more abstract the reference model the more delta you have between
> implementations/specializations, so the RM really would be only be
> valuable with specializations as a deliverable. Call it a 'web
> services' or equivalent RM, but not an SOA RM. The argument that
> almost everything is an SOA does not hold water with me. SOA in its
> final tangible form has a considerable number of requirements that
> make it unique. I see an SOA RM like a 'three-tier' architecture model
> that would be more effective, we all know that is www/app/db right?
> http://www.sei.cmu.edu/str/descriptions/threetier.html What is it for
> SOA? I argue it should at a minimum include a function/process for a
> registry, in addition it should also include at a minimum 'support'
> for secure communication.
>
> TM
>
> ------------------------------------------------------------------------
>
> From: Yunker, John [mailto:yunker@amazon.com]
> Sent: Wednesday, December 15, 2004 12:35 PM
> To: Chiusano Joseph; Matthew MacKenzie; ebSOA OASIS TC
> Subject: RE: [ebsoa] Does SOA Require Registry-Based Dynamic Discovery?
>
> First, let me agree with Matt that "ebXML Registry (big R)" is just
> one way of discovery, however any discovery requires that what is
> being discovered is registered . Let me further assert that discovery
> outside of a tightly controlled group requires some sort of registry
> (small r) mechanism for discovery to be effective. These are the
> assumptions I started with.
>
> Sorry if your initial question was only directed towards big R
> registry!!! :-)
>
> -----Original Message-----
> From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
> Sent: Wednesday, December 15, 2004 9:13 AM
> To: Yunker, John; Matthew MacKenzie; ebSOA OASIS TC
> Subject: RE: [ebsoa] Does SOA Require Registry-Based Dynamic
> Discovery?
>
> Thanks John - I'm going to take all 4 parts of your excellent
> comments below separately, and comment further. You basically said:
>
> An SOA without registry by definition is limited
>
> [JMC] Limited in what way? I assume because there is no dynamic
> discovery, and if the interface requirements and/or service
> location changed, it would require an out-of-band mechanism. I
> would assert that it is limited if the technical and business
> requirements led to an anticipation of updates to the interface
> requirements and/or service location on a regular basis -
> otherwise, is it *really* limited?
>
> [yunker] Limited in the ability of the SOA to support broad groups
> or communities.
>
> An SOA without registry by definition is private
>
> [JMC] So if a SOA-based system is being used among 2 or more
> organizations, and the technical and business requirements *do not
> lead* to an anticipation of updates to the interface requirements
> and/or service location on a regular basis, then the SOA is
> "private"? Seems orthogonal to me...
>
> [yunker] Private in that some out-of-band communication must be
> supported.
>
> An SOA with a registry is open
>
> [JMC] Open to who? If it does not have a registry, it is not open?
>
> [yunker] Open, in that you don't need to be on the mailing list of
> the service provider to know that a service is available.
>
> An SOA with a registry is dynamic
>
> [JMC] Agree! (one out of 4 ain't bad ;)
>
> Thanks again!
>
> Kind Regards,
>
> Joseph Chiusano
>
> Booz Allen Hamilton
>
> Strategy and Technology Consultants to the World
>
> ------------------------------------------------------------------------
>
> From: Yunker, John [mailto:yunker@amazon.com]
> Sent: Wednesday, December 15, 2004 12:06 PM
> To: Chiusano Joseph; Matthew MacKenzie; ebSOA OASIS TC
> Subject: RE: [ebsoa] Does SOA Require Registry-Based Dynamic
> Discovery?
>
> From my view the "registry requirement" is more a function of
> the distributed nature of the participants, the number and
> type of services, and the amount of change. A registry
> provides a method for decoupling "the use of an SOA" from
> "direct communication of the participants about HOW to use the
> SOA".
>
> An SOA without registry by definition is limited and private
>
> An SOA with a registry is open and dynamic
>
> John
>
> -----Original Message-----
> From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
> Sent: Wednesday, December 15, 2004 9:01 AM
> To: Matthew MacKenzie; ebSOA OASIS TC
> Subject: RE: [ebsoa] Does SOA Require Registry-Based
> Dynamic Discovery?
>
> Thanks Matt. From that I take:
>
> - Discovery in general is required for SOA (cannot
> function without it)
>
> - Whether it is (what I will call) "fundamental" discovery
> - meaning your first example below - or "registry-based"
> discovery depends on technical and business requirements.
>
> I just cannot foresee trying to convince a current or
> potential customer that they have to put up $XX,XXX for a
> registry product if the technical and business
> requirements do not call for it, just to comply with
> someone's definition of the term "SOA".
>
> Kind Regards,
>
> Joseph Chiusano
>
> Booz Allen Hamilton
>
> Strategy and Technology Consultants to the World
>
> ------------------------------------------------------------------------
>
> From: Matthew MacKenzie [mailto:mattm@adobe.com]
> Sent: Wednesday, December 15, 2004 11:57 AM
> To: Chiusano Joseph; 'ebSOA OASIS TC'
> Subject: RE: [ebsoa] Does SOA Require Registry-Based
> Dynamic Discovery?
>
> My opinion is that a registry is nothing more than a
> very explicit service discovery device.
>
> An SOA does need a method of discovering services, and
> consuming them, but this method may in some cases be
> subtle. For example, my SOA may operate on the premise
> that consumers all are aware of an enumeration of
> service types, and their port numbers (think
> /etc/services in the unix world), and allowable IP
> ranges for finding services. Clients may be configured
> something like:
>
> {
>
> Services imap, http, ssh, daytime, pop3, portmap
>
> IPRange 192.168.0.0/24
>
> }
>
> A client with such a configuration does have a way of
> discovering services that are available to it, and of
> course, a way of binding to them.
>
> Contrast this with a registry driven SOA:
>
> {
>
> ServiceRegistry http://foo/registry
>
> }
>
> The only difference is in the implementation detail
> and verbosity of information available. Conceptually,
> they are the same.
>
> --Matt MacKenzie
>
> ------------------------------------------------------------------------
>
> From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
> Sent: Wednesday, December 15, 2004 11:38 AM
> To: ebSOA OASIS TC
> Subject: [ebsoa] Does SOA Require Registry-Based
> Dynamic Discovery?
>
> What is the TC's opinion on the answer to the question
> of "does SOA require registry-based dynamic
> discovery"? I know that Discovery is a pattern in the
> .047 spec, which leads me to believe that the position
> is that SOA does not *require* registry-based discovery.
>
> For example, suppose that:
>
> - 2 organizations are using Web Services in a
> "SOA-like" manner (meaning shared services represented
> as Web Services, that are invoked by other Web Services).
>
> - There is no registry-based dynamic discovery,
> perhaps because the organizations agree that these
> service locations are completely (or relatively)
> stable, and that if the locations change, there will
> be some out-of-band mechanism for propagating updated
> WSDL documents
>
> Are these 2 organizations therefore *not* using a
> service-oriented architecture? That is, does the
> second point completely negate the first? Or, is it
> all really a matter of business and technical
> requirements?
>
> Kind Regards,
>
> Joseph Chiusano
>
> Booz Allen Hamilton
>
> Strategy and Technology Consultants to the World
>
--
***********
Senior Standards Strategist - Adobe Systems, Inc. - http://www.adobe.com
Vice Chair - UN/CEFACT Bureau Plenary - http://www.unece.org/cefact/
Chair - OASIS eb SOA TC - http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ebsoa
***********
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]