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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebsoa message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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!!

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]