Your SlideShare is downloading. ×
Soaregistryrepositorydeployment 090316114404-phpapp02
Soaregistryrepositorydeployment 090316114404-phpapp02
Soaregistryrepositorydeployment 090316114404-phpapp02
Soaregistryrepositorydeployment 090316114404-phpapp02
Soaregistryrepositorydeployment 090316114404-phpapp02
Soaregistryrepositorydeployment 090316114404-phpapp02
Soaregistryrepositorydeployment 090316114404-phpapp02
Soaregistryrepositorydeployment 090316114404-phpapp02
Soaregistryrepositorydeployment 090316114404-phpapp02
Soaregistryrepositorydeployment 090316114404-phpapp02
Soaregistryrepositorydeployment 090316114404-phpapp02
Soaregistryrepositorydeployment 090316114404-phpapp02
Soaregistryrepositorydeployment 090316114404-phpapp02
Soaregistryrepositorydeployment 090316114404-phpapp02
Soaregistryrepositorydeployment 090316114404-phpapp02
Soaregistryrepositorydeployment 090316114404-phpapp02
Soaregistryrepositorydeployment 090316114404-phpapp02
Soaregistryrepositorydeployment 090316114404-phpapp02
Soaregistryrepositorydeployment 090316114404-phpapp02
Soaregistryrepositorydeployment 090316114404-phpapp02
Soaregistryrepositorydeployment 090316114404-phpapp02
Soaregistryrepositorydeployment 090316114404-phpapp02
Soaregistryrepositorydeployment 090316114404-phpapp02
Soaregistryrepositorydeployment 090316114404-phpapp02
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Soaregistryrepositorydeployment 090316114404-phpapp02

701

Published on

Published in: Education, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
701
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. SOA Registry RepositoryDeploymentJanuary 2007 SOA Chief Proprietary Information ©2007 SOA Chief All Rights Reserved PAGE 1
  • 2. DisclaimerAll advice given and statements and recommendations made in thispublication are: provided in good faith on the basis of informationprovided by third parties and/or otherwise generally available orknown by the SOA Chief at the time of writing; and made strictly onthe basis that in no circumstances shall this publication constitute orbe deemed to constitute a warranty by the SOA Chief as to theaccuracy or completeness of the contents of this publication. The SOAChief shall not be liable for any loss, expense, damage or claim arisingout of, or in conjunction with the contents of this publication nor forany omission from it. SOA Chief Proprietary Information ©2007 SOA Chief All Rights Reserved PAGE 2
  • 3. ContentsTHE SOA REGISTRY REPOSITORY IMPERATIVE .............................................4 COMPLEX SERVICE INFORMATION ...............................................................................................................4 THE CASE FOR GOVERNANCE......................................................................................................................5 THE CASE FOR AN SOA REGISTRY REPOSITORY .........................................................................................5 BUSINESS PROCESS DRIVEN .........................................................................................................................7KEY SOA REGISTRY REPOSITORY ASSOCIATED CAPABILITIES .....................9 STANDARDS BASED SOA REGISTRY REPOSITORY ........................................................................................9 INFORMATION MANAGEMENT......................................................................................................................9 POLICY MANAGEMENT ..............................................................................................................................10 IDENTITY MANAGEMENT ..........................................................................................................................10 DISCOVERY AND REUSE ............................................................................................................................11 ENTERPRISE CATALOG...............................................................................................................................12 DEPENDENCY MANAGEMENT ....................................................................................................................12 SERVICE VERSIONING ................................................................................................................................13 SERVICE CHANGE NOTIFICATIONS .............................................................................................................13 GETTING STARTED WITH A SOA REGISTRY REPOSITORY ........................................................................14 REGISTRY REPOSITORY SDKS ...................................................................................................................14 PRODUCT SELECTION.................................................................................................................................14 LEADING SOA REGISTRY REPOSITORY PRODUCTS ...................................................................................15 CONCLUSIONS............................................................................................................................................16REFERENCES ...............................................................................................17APPENDIX: STANDARDS COMPARISON....................................................... 18 SOA Chief Proprietary Information ©2007 SOA Chief All Rights Reserved PAGE 3
  • 4. The SOA Registry Repository Imperative Service Oriented Architecture (SOA) is being adopted by manyInformation Technology (IT) organizations as an architectural stylebecause of its promises to make them more agile and efficient. Theloosely coupled nature of SOA makes this possible due in large part byproviding the ability to enable service components to evolve withoutrequiring costly rework of existing applications. This agility andefficient is also made possible by the increased leverage and reuse ofexisting service components for developing new service components. SOA deployments have been performed by early adopters andhave been comprised of pilot projects with small numbers of simpleservices. The information regarding these services was also simpleand was managed, shared, and tracked informally using Web sites,databases, and e-mails. The complexity and scale of these deployments are growingsteadily, as SOA deployments become more common. It is unrealisticto employ informal mechanisms such as Web sites and emails tomanage, share, and track service-related information artifacts. An SOA registry repository is becoming an increasinglyimportant component of an average SOA ecosystem. An SOA registryrepository assists in managing this rising information complexity andmeeting new requirements. This whitepaper explores some of themore common challenges encountered with large-SOA deployments,and offers advice on how an SOA registry repository may be utilized tomanage these challenges.Complex Service Information With the rising complexity of service components, it is no longerrealistic to assume that all information describing a service componentwill be captured in a single artifact, such as a Web Service DescriptionLanguage (WSDL) file. There are various information artifacts that describe a servicecomponent or relate it to other service components and informationartifices. Some examples are: o Multiple WSDL files may describe the various interfaces and protocol bindings of these interfaces for the service component. SOA Chief Proprietary Information ©2007 SOA Chief All Rights Reserved PAGE 4
  • 5. o Extensible Markup Language (XML) schema files may describe the documents exchanged by messages in the service protocol. o Business process orchestration for the service component may be described by artifacts such as Business Process Execution Language (BPEL) descriptions, and Electronic Business Extensible Markup Language (ebXML) business process specification schemas. o Metadata may describe the assembly structure and subcomponents of a composite service, mashup. o Extensible Stylesheet Language Transformations (XSLT) stylesheets may be used as adapters between service components to handle mediation o Web Services for Remote Portlets (WSRP) descriptions may describe how service components are utilized within portals o Business tenets and rules, organizational policies, and procedures may define how service components and service artifacts may be defined and reused.The Case for Governance Governance is defined as the art and science of managingoutcomes, goals, consistent with measurable preconditions andexpectations through processes, policies, and structured relationshipswhich are applied to organization and utilization of distributedenterprise capabilities that may be under the control of differentownership domains Organizational policies that insist on how service componentsand service artifacts may be defined and reused are simply insufficient.There must be a centralized point of control, logically speaking ofcourse, that provides full lifecycle governance for service componentsand artifacts which enforces the organizational policies that governthem. This will ensure that the organizational policies are applied in aconsistent and predictable manner throughout the SOA deployment, aswell as across all SOA deployments, and results in improved qualityand integrity of managed outcomes.The Case for an SOA Registry Repository An SOA registry repository fulfills the role as the central point ofcontrol, System-of-Record (SOR), for managing service artifactsthroughout the SOA lifecycle and enforcing organizational policies with SOA Chief Proprietary Information ©2007 SOA Chief All Rights Reserved PAGE 5
  • 6. the SOA ecosystem. The following is an example that describes a registry repositoryusing a simple analogy: o A registry repository is similar to a pubic library o It has a repository that contains all types of electronic assets, similar to how the library bookshelves contain all types of published content (books, magazines, videos, and so forth) o It has a registry that contains metadata, data about data, which describes the electronic artifacts, similar to how the library’s card catalog contains information describing the published content on the book shelves o In some cases the registry and repository are administered jointly, an integrated registry repository, similarly the card catalog and book shelves are administered jointly o Multiple registry repositories should be able to work together to offer a unified service, federated registry repositories, much like how multiple libraries participate in a collaborative network in order to offer a unified service. This is a wish more than it is a reality. Current registry repository products have a limited, if one at all, sense of federation. The early SOA deployments recognized the imperative for moreformal mechanisms, other than simple Web sites, for managing,sharing, and tracking the ever increasing complexity and diversity ofservice artifacts. This led to the use of a registry such as a UniversalDescription, Discovery, and Integration (UDDI) registry to manage,share, and track service artifacts. Even though utilizing a UDDIregistry is an improvement over less formal approaches, it has acritical limitation: a registry can simply store links or pointers toservice artifacts. The actual artifacts must reside externally to theregistry, utilizing informal and inconsistent mechanisms such as Websites. This causes the actual artifacts to be ungovernable by theregistry. The missing piece is a repository that stores the artifacts. Ifwe revisit the library, what is a library only contained a card catalogand the books were contained in some external location. While a repository can contain the actual artifacts, a bestpractice is to only have the repository contain certain artifacts such as SOA Chief Proprietary Information ©2007 SOA Chief All Rights Reserved PAGE 6
  • 7. the WSDL, or other interface, files, and policies and the link to otherservice artifacts such as example code, and supporting documentation. An SOA registry repository should provide full lifecyclegovernance capabilities that allow organizations to define and enforceorganizational policies to govern the publication, invocation, execution,and mediation of service information. Organizational policies are asunique as organizations themselves thus the SOA registry repositoryshould provide a framework that allows organizations to developcustom policies, policy assertions, and policy templates for governingany service artifact, including metadata. The SOA registry repositoryshould also provide a framework that allows organizations to definecustom lifecycles and lifecycle events which trigger lifecycle statechanges. The SOA registry repository should enforce design-timeconformance, such as Web Service- Interoperability (WS-I) compliancewhen a service is published, and change-time conformance such asrequiring approvals for all service artifact modifications. In addition todesign-time and change-time conformance, an SOA registry repositorycould also provide a mechanism to develop run-time policies, such asservice-level-agreements (SLAs), and distribute them to policy-enforcement-points (PEPs) for runtime enforcement.Business process Driven Organizational and domain-specific business rules must beenforced to ensure that valid service artifacts are being published tothe SOA registry repository. Simple syntax validation is not enough,but rather semantic validation must be performed on each artifact. Anexample would enforce a business rule that states “All WSDL artifactsMUST contain only Simple Object Access Protocol (SOAP) bindings anduse Document style communication”. A registry repository should be business rules engine driven suchthat business rules can be enforced at any stage of a defined lifecycle.It should also allow business rules to be defined by organizations andspecific to the various types of artifacts. If a governance policy failsduring any stage of the lifecycle part of the business rule should be tonotify the appropriate parties. The real value and power of an SOA is the ability to compose,orchestrate, and choreograph atomic, fine grained, services into higherorder, more coarse grained, services and capabilities. The ability tomash together data resources and functionality from multiple services,applications, and legacy systems leads to a higher level organizational SOA Chief Proprietary Information ©2007 SOA Chief All Rights Reserved PAGE 7
  • 8. agility. The composition, orchestration, and choreography of servicesand business processes ,which commonly cross domains of ownership,is a factor in the adoption of SOA within the organization due to thereuse nature of services. In order for organizations to succeed, they must enter into aparadigm shift that diverts the control of the organization’s future fromthe IT population over to the business population. In the SOAparadigm IT becomes more of an enabler to the business rather than adriving force. A registry repository should provide the ability to composehigher grain services, which could also be incorporated as tasks in theorchestration of a business process services or extended to the supplychain in service choreography.In a similar manner to business rules associated with servicepublication, there must be enforcement of business rules andorganizational policies around the composition, orchestration, andchoreography of services. SOA Chief Proprietary Information ©2007 SOA Chief All Rights Reserved PAGE 8
  • 9. Key SOA Registry Repository AssociatedCapabilitiesStandards based SOA registry repository Some SOA registry-only product vendors have released versionsof their products with product-specific (proprietary) extensions in orderto add repository capabilities. These were normally added throughloose integration mechanisms where the registry and repository aretwo separate modules but have touch points between them. Theseproducts meet, either partially or fully, the governance requirementsexpected of an integrated registry-repository. This maybe anacceptable solution for some architects, however this type of solutionis only practical when the SOA deployment is controlled by a singleorganization which can ensure either the utilization of a single registryrepository, or if multiple instances are required that they are the samevendor product and interoperate. In reality, SOA deployments tend to span organizational andgovernance boundaries. Organizations, regardless of size, prefer tohave local autonomy over their SOA deployments, but also need toseamlessly integrate their services with the SOA deployments of otherorganizations. SOA deployments must be federated using openstandards, in order to have local autonomy but also provide seamlessglobal integration and interoperability. The trend of vendor-specific, integrated registry repositories hasbeen overshadowed by the growing trend towards integrated registryrepository products that are based on standards facilitating federationand general interoperability.Information Management An integrated registry-repository, open standards-based, allowsorganizations to share and link information with other organizations ina secure fashion. A federated information management allowsdistributed registry repositories to appear as a single, virtual registryrepository, but also allows organization to retail localized control owntheir registry-repositories. For instance, an enterprise may deploy afederated registry-repository consisting of a series of registry-repositories in different ownership, organizational, domains. Thisfederated environment would allow individuals to discover information SOA Chief Proprietary Information ©2007 SOA Chief All Rights Reserved PAGE 9
  • 10. seamlessly across the enterprise within any organizational domain.For example, they could search for available services for purchaseordering. The United Nations Centre for the Facilitation of theAdministration, Commerce, and Transport (CEFACT) organizationconsidered a federated information management requirement as a keyrequirement in selecting an open standards-based, integrated registry-repository.Policy Management The enforcement of organizational policies that are described in amachine-processable syntax is a requirement of governance. Thisformat is typical Extensible Markup Language (XML). These policy filesmust be published, managed, discovered, and governed the same asother service artifacts, in an SOA deployment. Policies need to belinked and composed across enterprise boundaries in a federated SOAdeployment. Current policy management is performed within proprietarypolicy stores using product centric mechanisms. While there has beenmaturity in the standards associated with policy expression andgovernance over the past several years, they still remain immature.In any case, policies are managed and governed in the same manneras other service artifacts in an SOA registry repository. TheOrganization for the Advancement of Structured Information Standards(OASIS) Extensible Access Control Markup Language (XACML)standard is used by the ebXML Registry standard to express federatedpolicy management of access control policies.Identity Management Simply deploying an open standards-based, integrated registryrepository is not sufficient for SOA deployments across an enterprise.A mechanism is required for securely managing the identities ofconsumers, and authenticating then when accessing servicecomponents and artifacts. The threat is exposing an enterprise’sservices and artifacts to external consumers from other organizationswithin the enterprise or outside the enterprise in an insecure orunauthorized manner. This threat is addressed with federated identity management byinstituting a circle of trust across all services with the federated SOA Chief Proprietary Information ©2007 SOA Chief All Rights Reserved PAGE 10
  • 11. environment. This allows for single sign-on (SSO) such that aconsumer is authenticated once and then uses the authenticatedsession to access services throughout the environment without havingto be reauthenticated. Authorization credentials can also be mappedacross systems in the federated environment. Federated identity management mechanism should be supportedby an SOA registry including single sign-on. The SOA registryrepository should also integrate with identity management and accessservices using open standards such as Security Assertions MarkupLanguage (SAML).Discovery and Reuse The ability to construct complex service components fromatomic, task-specific service components is one of the lures of the SOAparadigm. This is similar to constructing houses from legos. Servicecomponents may be reused virtually endless times in other services. Acredit rating service is an example of an atomic service componentthat can be utilized by any number of more complex services such asmortgages, car loans, financial aid applications, or credit cards. All of the service-related artifacts available within an SOAdeployment are managed from the registry repository. Developersshould have access to this information during design-time, in order todiscover and leverage existing service components in new thedevelopment of new service components. Discovery of serviceartifacts should be possible to be performed utilizing any organizationalsearch criteria. A discover capability should be one of the foundationalcapabilities provided by a registry repository. This capability should beextensible and be able to accommodate a wide variety of discoveryqueries, from the most simple to complex domain-specific queries. Aset of predefined discovery queries should be provided by the registryrepository; however it should also allow organizations to constructcustom ad-hoc queries by providing a query syntax that supportscomplex expressions using Boolean logic. Some examples of discoveryqueries would include the following: o Find all WSDL documents that use a specified namespace pattern o Find all Service Bindings or Services that have a certain SOA Chief Proprietary Information ©2007 SOA Chief All Rights Reserved PAGE 11
  • 12. text pattern in their documentation o Find all Service Bindings that are SOAP bindings AND use DOC Literal style AND do not use HTTP as transport o Find all WSDLs with Service implementations that use specified implementation platform (for example, Java™ 2 Platform, Enterprise Edition or J2EE™, .Net, and so on) o Find all WSDLs with Service implementations that use specified platform resources (such as database, Java Message Service or JMS, Java API for XML Registries or JAXR, and so on) If not managed and governed, the flexibility and expressivepower of ad hoc query syntax could lead to usability and performanceissues. An example of this might be the query syntax may be tocomplex to be utilized by a typical user. It could also result ininefficient queries which could place excessive work loads on theregistry repository. This could be rectified if the ability to store queriessimilar to stored procedures in a relational database. A registry repository should provide organizations the ability todefine parameterized, ad hoc queries as stored queries which in turncould be invoked by consumer applications with the parameters beingsupplied as invocation parameters. This capability allows organizationsto define approved, domain-specific discovery queries within theregistry repository, and these discovery queries then could be utilizedby their user communities. The queries could be exposed to users assimple web applications hiding the complexity of the registryrepository.Enterprise Catalog By establishing an enterprise catalog of service artifactsimproves their discoverability and artifact specific queries, like those inthe discovery discussion. The indexing of database tables is similar to cataloging serviceartifacts. Information is automatically converted to metadata duringpublication, and the metadata is then used to facilitate efficientdiscovery of the published information. For example, an organizationcould define cataloging policies for WSDL artifacts such that whenWSDLs are published, they are cataloged in a WSDL-specific manner togenerate metadata that includes information on: SOA Chief Proprietary Information ©2007 SOA Chief All Rights Reserved PAGE 12
  • 13. o The documents referenced by the WSDL (other WSDLs and XML schemas) o The name spaces referenced by the WSDL and related documents o The name and description of the bindings, interfaces, and types used by the WSDLThese types of metadata can be utilized in WSDL-specific types ofdiscovery queries, as those mentioned in the discovery discussion.Dependency Management Keeping track of the numerous dependencies among servicecomponents is a significant challenge in an SOA environment,especially when service reuse is in full force. An SOA registryrepository which provides dependency management can assist withthis issue by managing the complex relationships of service artifacts.Examples of these relationships are Contains, Depends On, Extends,Implements, Uses, and Supersedes. SOA deployments are not cookie-cutter and as such a fixed set of relationships may not be suitable forall deployments. A standard set of relationships should be provided by an SOAregistry repository, but should also allow organizations to developcustom relationships based upon its specific requirements.Service Versioning New requirements, among other reasons, influence the evolutionof services over time. A service’s evolution involves modifications toits implementation and/or public interface. The ability to have manyconsumers of a single service, some could be unknown, increases themanagement issues of the service interface and its modificationimpacts. In many cases, these types of changes usually requiredeploying a new version of the service, while maintaining the olderversion until its consumers have had time to migrate to the newversion. New versions of supporting service information artifactstypically accompany the publication of the versions of a service orservice component. A versioning capability that automates version on control of anytype of service artifact should be provided by a registry repository.This capability should allow providers and organizational policies to SOA Chief Proprietary Information ©2007 SOA Chief All Rights Reserved PAGE 13
  • 14. determine when to treat modifications to an existing service artifact asupdates to the artifact or a new version artifact.Service Change Notifications As a service matures and evolves it is important that theconsumers of that service be notified of the changes. For instance, itis important to notify consumers of a service when a new version ofthat service is available, so they can begin planning any migrations tothe new version. A notification capability should be supported by the registryrepository such that interested parties can create subscriptions toevents that may be of interest to them. Subscription should be flexibleenough that interested parties can express precisely the types ofevents that are of interest to them. Change notification should invokeservices that automate the governance workflow process. SOA Chief Proprietary Information ©2007 SOA Chief All Rights Reserved PAGE 14
  • 15. Getting Started With A SOA Registry RepositoryRegistry Repository SDKs A registry repository is not simply a design-time service forpublishing, managing, discovering, and governing service artifacts.While this is an important aspect, it also should support the utilizationby deployed services as a source for operational and configuration dataat runtime. A registry repository should provide a softwaredevelopment kit (SDK) to develop custom registry client applicationsand services. Many of the registry repository product vendors offer aSDK for the Java platform and support the Java for XML Registries(JAXR) standard, which is the standard Java application programminginterface (API) for registries and repositories.Product Selection When organizations begin evaluating which registry repository todeploy within their SOA ecosystem, the registry repository choicesseem to be categorized as follows: 1. Proprietary registry-repository 2. UDDI registry without a repository 3. UDDI registry with a proprietary repository 4. ebXML registry-repository 5. Combination of UDDI registry and ebXML registry- repository Since federated SOA deployments require a standards-basedregistry repository, it suggests eliminating options 1 and 3 in theabove list. The remaining choices, all standards-based, involve twostandards, UDDI and ebXML Registry. A UDDI registry offers a subset of capabilities offered by anebXML Registry. See Table 2: Registry Standards Comparison Matrix inthe Appendix for details. Specifically, it provides only a registry and norepository. Pointers to service artifacts, such as WSDL, get publishedin a UDDI registry. Both pointers and the actual service artifact getpublished to the ebXML Registry. Thus, an ebXML registry-repositorycan be used for governance of any type of service artifacts throughouttheir life cycles. An ebXML registry-repository is highly extensible. Thisextensibility has been a double-edged sword for the ebXML Registry SOA Chief Proprietary Information ©2007 SOA Chief All Rights Reserved PAGE 15
  • 16. standard. On the positive side, it enables organizations to enforcecustom governance policies for managing their service artifacts. On thenegative side, it also makes the standard harder to understand anddeploy because of its generic and extensible nature. This problem isbeing addressed by the emergence of vertical or use case-specificprofiles of ebXML Registry that define precisely how to make use of itsgeneric and extensible features in a standard, interoperable mannerwithin a particular domain. For example, in the Web services area ofgreatest interest to those doing SOA deployments, a Web ServicesProfile is being defined by the OASIS ebXML Registry TechnicalCommittee (TC). A UDDI registry may be adequate for simpler SOA deployments.However, experience has shown that as SOA deployments increase incomplexity and scale — which they inevitably do — an ebXML registryis a much better fit. It is sometimes the case that a SOA deploymentstarting with a UDDI-based implementation will later migrate to anebXML Registry-based one, as needs grow. It is not necessary to choose between the two standards. Newerproducts are appearing that support both standards in a single engine.An example of this new class of registry-repository products is Sun’sService Registry. When deploying such a registry, be aware that thefunctionality offered by each interface is quite different. As discussed,the ebXML Registry interface provides the fuller set of capabilities. Thismeans that a dual-interface registry like the ebXML Registry interfaceis employed more pervasively, while the UDDI interface is used morespecifically to interoperate with clients restricted to the UDDI protocol.Leading SOA Registry Repository Products In this past year, 2006, there was a tremendous amount ofconsolidation in the SOA registry repository marketplace. BEASystems acquired the Flashline registry product, webMethods acquiredInfravio and its X-Registry Platform, and Systinet was acquired byMercury Interactive, which was later acquired by Hewlett Packard (HP).After all the consolidation and product announcements by IBM and SunMicrosystems, there are four mainstream SOA registry repositoryproducts that support the two registry repository standards. Theregistry repository matrix, in Table 1, provides a list of the leadingregistry repository vendors, products, and the technology supported. SOA Chief Proprietary Information ©2007 SOA Chief All Rights Reserved PAGE 16
  • 17. Vendor Product(s) UDDI ebXMLBEA Aqua Logic 3.0 EnterprisewebMethods X-Registry Platform 2.0,3.0 XIBM WebSphere RegistrySun 3.0 XTable 1 Registry Repository MatrixConclusions In the past, enterprise integration was achieved via dataintegration using a common enterprise database as the integrationpoint. SOA represents the latest approach to enterprise integration vialoosely coupled service integration based on a component anddocument-centric architecture. The next logical step is a federated SOAdeployment that achieves enterprise integration within and acrossenterprise boundaries via service integration enhanced with secure,federated information management.Today’s SOA deployments are becoming increasingly complex andrequire strong governance capabilities. A standards based registry-repository is emerging as an important SOA infrastructure component.First-generation Web services registries based solely on UDDI lackmany important capabilities, including repository functions, which arenecessary for governing and managing complex SOA deployments. AnebXML registry-repository provides a much richer set of capabilities tomeet the advanced governance and federated informationmanagement requirements of complex SOA deployments. A new classof registry-repository will support both UDDI and ebXML Registrystandards in a single solution. SOA Chief Proprietary Information ©2007 SOA Chief All Rights Reserved PAGE 17
  • 18. References[SOA] Service-Oriented Architecturehttp://www.oasis-open.org/committees/download.php/19679/soa-rm-cs.pdf[UDDI] UDDIwww.oasis-open.org/committees/tc_home.php?wg_abbrev=uddi-spec[EbRR] ebXML Registry Meta Linkshttp://ebxmlrr.sourceforge.net/tmp/ebXMLRegistryLinks.html[BEA ALER] Sun’s Service Registryhttp://www.bea.com/framework.jsp?CNT=index.htm&FP=/content/products/aqualogic/service_registry/[IBM WSRR] WebSphere Registry and Repositoryhttp://www-128.ibm.com/developerworks/websphere/library/techarticles/0609_mckee/0609_mckee.html[X-Reg] webMethods Infravio X-Registry Platformhttp://www.webmethods.com/Products/Fabric/SOA/Registry[SUNR] Sun’s Service Registrywww.sun.com/products/soa/registry/[S2] Systinet 2http://www.systinet.com/products/systinet_2 SOA Chief Proprietary Information ©2007 SOA Chief All Rights Reserved PAGE 18
  • 19. Appendix: Standards Comparison The following table is a comparison of the most commonstandards, UDDI and ebXML Registry 3.0, utilized in registry-repositories.Table 2 Standards Comparison UDDI 3.0 ebXML Registry 3.0Category/FeatureStandardsService Description WSDL 1.1 WSDL 1.1Messaging SOAP 1.1 SOAP 1.1 with AttachmentsMessage Security OASIS Web Service SecurityAccess Control XACML 1.0Identity SAML 2.0ManagementArchitectureObject-Oriented API No Yes API offers API offers a few task- type-oriented oriented calls that may be calls that used by any type of keep growing metadata object as new types Consistent and uniform are actions added in each supported via few API calls release of across UDDI entire information modelObject-Oriented No Yes SOA Chief Proprietary Information ©2007 SOA Chief All Rights Reserved PAGE 19
  • 20. Extensible API No Yes New API calls may be defined using standards-based API extensibilityExtensible No YesInformation Model New information model types may be defined using standards- based SOA Chief Proprietary Information ©2007 SOA Chief All Rights Reserved PAGE 20
  • 21. Category/Feature UDDI 3.0 ebXML RegistryCore FeaturesRegistry Yes YesRepository No (added Yes by tool Integrated vendors) registry- repository Any type ofDiscoveryPredefined queries Yes YesUser-defined queries No YesAd hoc queries No YesSQL query syntax No Yes Ad hoc syntax supportsXML query syntax Yes Yes Fixed Ad hoc syntax syntax supportsStored parameterized queries No Yes SOA Chief Proprietary Information ©2007 SOA Chief All Rights Reserved PAGE 21
  • 22. Category/Feature UDDI 3.0 ebXML RegistryPublishCan publish metadata describing any Yes Yestype of information artifact Rich set of ~25 Inadequate standard metadataCan publish any type of information No Yesartifact Actual InformationRelationshipsPredefined relationship types Yes - Very Yes - ExtensiveUser-defined relationship types No YesAbility to relate any two objects in No Yesregistry using any relationship typePackaging/Grouping SupportUser-defined packages No YesGroup any number of objects in same No YesGroup an object in multiple packages No YesSecurity FeaturesDigital signature based authentication Yes - Yes - RequiredBasic access control based on Yes – YesUser-defined, fined-grained access No YesFederated identity management and No YesAudit trail Yes YesCategory/Feature UDDI 3.0 ebXML RegistryProtocol Bindings SOA Chief Proprietary Information ©2007 SOA Chief All Rights Reserved PAGE 22
  • 23. HTTP binding (REST) No Yes Allows any metadata orSOAP API binding Yes YesTaxonomy SupportPredefined taxonomies Yes YesUser-defined taxonomies No YesTaxonomy browsing and validation No YesClassification of artifacts Yes YesClassification of any metadata object No YesLife Cycle ManagementApproval No YesUpdate Yes YesAutomatic Version Control No YesDeprecation No YesUndeprecation No YesDeletion Yes YesCategory/Feature UDDI 3.0 ebXML RegistryFederationFederated Queries No YesObject references between any object No Yes SOA Chief Proprietary Information ©2007 SOA Chief All Rights Reserved PAGE 23
  • 24. Object replication from any registry Yes YesInformation ManagementMetadata Validation No YesArtifact Validation No Yes Unrestricted, may be used toEvent Subscription and NotificationAbility to select events using custom No YesContent-based event notification No YesCategory/Feature UDDI 3.0 ebXML RegistryClient SDK SupportJAXR API Yes YesOther FeaturesWeb Services Support Yes YesDomain-Specific Profile Support No Yes Extensibility features allow standard SOA Chief Proprietary Information ©2007 SOA Chief All Rights Reserved PAGE 24

×