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