I don't see how my name would contribute to any openness, I guarantee that I am 
not 
anyone you would know, don't worry. I have my own reasons for wishing to remain 
anonymous. In this world full of spiders and spammers I'd just as soon keep my 
name off 
the web.

What I am really looking for is more of a listing of what declarative 
functionality ALL 
services in an SOA require from some common facility (ESB, registry, 
repository, etc.) For 
example, one might say that all services require some form of security support 
and this 
security should reside in some entity external to the services. Or another 
example could 
be that all services need support for logging/auditing, etc. I don't see you 
providing any 
scientific reasons that the lightweight registry is a failure (I'm not 
necessarily disagreeing 
with this but just want to know why). It seemed you were implying the 
lightweight registry 
doesn't offer enough support to services in an SOA.


--- In [email protected], Farrukh Najmi 
<[EMAIL PROTECTED]> wrote:
> daemon9_1313 wrote:
> > "{We're seeing an increasing recognition that a lightweight registry
> > is not practical for the rising complexity of SOA deployments
> > Farrukh Najmi
> > Author and Member, ebXML Registry Specification}"
> >
> > This sounds like a hand-waving argument to me. I'd like to see far
> > more evidence as well as listing of exactly what declarative
> > functionality is required for ALL services.
> >
> Dear daemon9_1313,
> 
> I would be glad to answer any and all questions you may have on this list.
> The quoted statement is based on my experience working with numerous
> organizations and verticals in helpingthem deploy freebXML Registry (open
> source ebXML Registry implementation). A partail list of these companies may
> be found at:
> 
> http://ebxmlrr.sourceforge.net/aboutFAQ/About_freebXML_Registry.html#Deployments
> 
> Note these are only those companies dpeloying one specific implementation.
> The list of companies deploying ebXML Registry is much larger.
> 
> Entire verticals and other standards have adopted ebXML Registry 
> standard and defined vertical specific profiles of using ebXML Registry:
> 
> Open GIS (Geospatial)
> HL7 (Healthcare)
> IHE Cross Document Sharing (XDS) (Healthcre)
> RosettaNet (Supply chain)
> SDMX.org (Statistical Data Management an interchange)
> OASIS WSRP (Remote Portlets) TC
> 
> In my experience, the following are the most common reasons for their 
> choosing ebXML Registry (most important first):
> 
> 1. ebXML Registry is extensibility in almost every dimension as its 
> design center
> This allows it to meet specific needs of diverse and complex  applications.
> This includes support for any type of content, uer defined 
> parameterized, ad hoc
> queries, Content specific validation using user defined policies.
> 
> 2. Supports a standards based repository that is integrated with the 
> registry
> 
> 3. Supports federation features that allow multiple registries to 
> organically federate together to enable seamless yet secure data sharing
> 
> I am not sure what you meant by "declarative functionality is required 
> for ALL services".
> I do not recall saying that and am not sure what to say about it. Please 
> explain.
> 
> Lastly, in the spirit of openess and transparency I would appreciate if 
> you could identify your self by at least signing your message with your 
> Given and Family name.
> Thank you.
> 
> -- 
> Regards,
> Farrukh
> 
> Your are invited to attend the *free* OASIS ebXML Registry worldwide webinar.
> There are two sessions on September 15, 2005.
> Details at:
> 
> http://www.oasis-open.org/events/webinars/webinars.php







------------------------ Yahoo! Groups Sponsor --------------------~--> 
Fair play? Video games influencing politics. Click and talk back!
http://us.click.yahoo.com/T8sf5C/tzNLAA/TtwFAA/NhFolB/TM
--------------------------------------------------------------------~-> 

 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/service-orientated-architecture/

<*> To unsubscribe from this group, send an email to:
    [EMAIL PROTECTED]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 


Reply via email to