Light weight registry-only service lacks for SOA:
- Support for SOA Governance. Can't enforce policies on SOA artifacts if they reside external to registry.
- Ability to support artifact specific parameterized discovery queries
- Fine grained custom, role based access control of artifacts
- Extensible metadata and protocols
- Extensible taxonomies with no need for external validation services to validate ussage of taxonomies
- Extensible relationship between artifacts
- Content based event notification using extensible artifact specific queries
- Governance is a pretty broad topic, but it's all about defining policies and implementing procedures that verify adherence to those policies. Any registration process to which you can attach an approval workflow supports SOA governance. There's no requirement that the artifacts must reside in the registry in order to analyze and approve them. Systinet Registry provides a built-in customizable registration approval process--and it can call out to extenal validation services to check for compliance with WS-I Profiles, corporate namespace conventions, appropriate security precautions, management provisioning, etc. For folks using other UDDI-compliant registries, you can use an external governance/approval process such as WebLayers.
- Although a combined registry/repository does give you more flexible search capabilities, UDDI does allow for powerful search. You
can query a UDDI registry based on any information within the artifact
that you choose to capture within the registry. UDDI is extensible, so
you can capture pretty much whatever information you want to during
registration -- but you must first define the information model for
capturing the information, and you must use that model at registration
time.
- Both Systinet and SOA Software support fine-grained custom,
role-based access control of all registration entities. The artifacts
themselves are typically stored in separate asset repositories, which
should provide their own security systems for check-in, check-out,
version control, etc.
- The UDDI tModel is an extensible data entity, and it is designed to support extensible metadata and protocols.
- UDDI supports extensible taxonomies and their associated valid
value sets. Validation may be performed either internally or via an
external validation service. (Why does it matter if it's internal or
external?)
- The UDDI tModel and the categorization system can also be used to define extensible relationship between entities.
- The UDDI Subscription API supports content-based event
notification. You can design your registration process to capture
artifact-specific information and generate appropriate events.
- Federated queries able to search across multiple stores that contain non-overlapping data
I also have to point out that your metadata of record can't be managed and maintained in the ebXML repository. e.g., WSDL files are managed by their hosting platform; BPEL scripts are managed by their BPEL engines; XSLT scripts are managed by their ESBs, etc. The idea that you can have a single SOA repository is a pipe dream.
Anne
On 9/18/05, Farrukh Najmi <[EMAIL PROTECTED]> wrote:
daemon9_1313 wrote:
> 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.
Thanks for the clarification above.
The list is quite long but here are some things that light weight
registry-only service lacks for SOA:
-Support for SOA Governance. Cant enforce policies on SOA artifacts if
they reside external to registry.
-Ability to support artoifact specific parameterized discovery queries
-Fine grained custom, role based access control of artifacts
-Extensible metadata and protocols
-Extensible taxonomies with no need for external validation services to
validate ussage of taxonomies
-Extensible relationship between artifacts
-Content based event notification using extensible artifact specific queries
-Federated queries able to search across multiple stores that contain
non-overlapping data
For more info one may want to see the slides from the recent ebXML
Registry 3.0 Webinar at:
ebXML Registry Webinar Slides:
http://ebxmlrr.sourceforge.net/presentations/ebXML%20Registry%20webinar5.pdf
http://ebxmlrr.sourceforge.net/presentations/ebXML%20Registry%20webinar5.sxi
http://ebxmlrr.sourceforge.net/presentations/ebXML%20Registry%20webinar5.odp
http://ebxmlrr.sourceforge.net/presentations/ebXML%20Registry%20webinar5.ppt
Thank you.
--
Regards,
Farrukh
------------------------ Yahoo! Groups Sponsor --------------------~-->
Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life.
http://us.click.yahoo.com/A77XvD/vlQLAA/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/
SPONSORED LINKS
| Service-oriented architecture | Computer monitoring software | Computer and internet software |
| Free computer monitoring software |
YAHOO! GROUPS LINKS
- Visit your group "service-orientated-architecture" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
