[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebsoa] Does SOA Require Registry-Based Dynamic Discovery?
> -----Original Message----- > From: David RR Webber [mailto:david@drrw.info] > Sent: Wednesday, December 15, 2004 12:31 PM > To: Matthew MacKenzie > Cc: Chiusano Joseph; 'ebSOA OASIS TC' > Subject: Re: [ebsoa] Does SOA Require Registry-Based Dynamic > Discovery? > > Matt, > > Good thoughts. Yes - CPAs in registry is to allow the > runtime checking of in-bound transactions from partners to > ensure they really are who they say they are - and doing the > things they are supposed to be doing. But registry is just a > convenient archive at that point. > > CORBA? Arrggh! Although I must confess that the gyrations > of the BPEL team makes me think of "CORBA by XML" as being a > scary outcome we probably don't want to inflict on a long > suffering world!! See OASIS WSRF, and the WS-Transfer specification (some view them this way). Kind Regards, Joseph Chiusano Booz Allen Hamilton Strategy and Technology Consultants to the World > DW > > Matthew MacKenzie wrote: > > >David, > > > >I agree. It should not be lost on anyone that my day job involves > >specific registry technology. My argument really is aimed > at focusing > >the task of defining SOA in abstract terms so that it can be > applied in > >many places where it would be beneficial. The obvious long > term goal > >when this model is utilized are SOAs that function within multiple > >realizations. Imagine if I developed an SOA using the SOA > RM, and now > >can expose my SOA over ebXML, WS, and CORBA. Awesome! > > > >As a side note, why bother putting CPAs in a registry? It's > not like > >anyone can join a negotiated collaboration, all you do in > that case is > >slow the runtime down a little bit. CPP's, well, now there > is a great > >thing to register. Putting CPAs in the registry for any > reason other > >than archiving is probably not sound architecturally. > > > >-Matt > > > >-----Original Message----- > >From: David RR Webber [mailto:david@drrw.info] > >Sent: Wednesday, December 15, 2004 12:17 PM > >To: Matthew MacKenzie > >Cc: 'Chiusano Joseph'; 'ebSOA OASIS TC' > >Subject: Re: [ebsoa] Does SOA Require Registry-Based Dynamic > Discovery? > > > >Matt, > > > >Good technical answer - from the business stance - I would > say an SOA > >has to have some shared resource area where agreed too > business process > >and control mechanisms, rules, state, etc > >can be referenced and shared. Otherwise we are back to > out-of-band EDI > >style non-SOA > >deployment environments. > > > >Now - this could easily be a $3.00 per month common FTP area from an > >ISP > >- as you note > >Matt - so long as its open to all participants. The notion of > >"registry" does not have to imply a full up ebXML registry > deployment. > > > >However - the formal agreements between participants, their roles, > >procedures and mechanisms should be something that is dynamically > >configurable. Whether that is private or public - is then > the choice of > >the partners. > > > >Remember when we first designed ebXML - putting CPAs into > registry was > >a no-no - since they are private agreements. Now we have a security > >model for registry and ability to control access - it makes sense to > >have CPA definitions reachable by machine processes between partners > >(but not between everyone in the collaboration!). > > > >DW > > > >Matthew MacKenzie wrote: > > > > > > > >>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 > >> > >> > >> > >> > >> > > > > > > > > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]