Comments
yourfanat wrote: I am using another tool for Oracle developers - dbForge Studio for Oracle. This IDE has lots of usefull features, among them: oracle designer, code competion and formatter, query builder, debugger, profiler, erxport/import, reports and many others. The latest version supports Oracle 12C. More information here.
Cloud Computing
Conference & Expo
November 2-4, 2009 NYC
Register Today and SAVE !..

2008 West
DIAMOND SPONSOR:
Data Direct
SOA, WOA and Cloud Computing: The New Frontier for Data Services
PLATINUM SPONSORS:
Red Hat
The Opening of Virtualization
GOLD SPONSORS:
Appsense
User Environment Management – The Third Layer of the Desktop
Cordys
Cloud Computing for Business Agility
EMC
CMIS: A Multi-Vendor Proposal for a Service-Based Content Management Interoperability Standard
Freedom OSS
Practical SOA” Max Yankelevich
Intel
Architecting an Enterprise Service Router (ESR) – A Cost-Effective Way to Scale SOA Across the Enterprise
Sensedia
Return on Assests: Bringing Visibility to your SOA Strategy
Symantec
Managing Hybrid Endpoint Environments
VMWare
Game-Changing Technology for Enterprise Clouds and Applications
Click For 2008 West
Event Webcasts

2008 West
PLATINUM SPONSORS:
Appcelerator
Get ‘Rich’ Quick: Rapid Prototyping for RIA with ZERO Server Code
Keynote Systems
Designing for and Managing Performance in the New Frontier of Rich Internet Applications
GOLD SPONSORS:
ICEsoft
How Can AJAX Improve Homeland Security?
Isomorphic
Beyond Widgets: What a RIA Platform Should Offer
Oracle
REAs: Rich Enterprise Applications
Click For 2008 Event Webcasts
In many cases, the end of the year gives you time to step back and take stock of the last 12 months. This is when many of us take a hard look at what worked and what did not, complete performance reviews, and formulate plans for the coming year. For me, it is all of those things plus a time when I u...
SYS-CON.TV
Bringing Order to Enterprise Service Proliferation
Bringing Order to Enterprise Service Proliferation

UDDI has been around for almost three years now. It has gone from an initial proposal by three companies (Ariba, IBM, and Microsoft), to a consortium effort (www.uddi.org) with a community of hundreds, and finally into the hands of the OASIS standards body. Along the way, the original specification has gone through two additional revisions. Perhaps more important, with each new revision the business value of UDDI has shifted from being a registry of public services to a central fixture in private EAI and partner-integration efforts.

The most recent version of UDDI, V3, continues this trend by making UDDI more usable as a common service registry inside an extended enterprise and between partners. Thus this technology, originally designed for publishing and discovering Web services, can today be leveraged by enterprises to provide a complete solution for managing access to Web services including subscription control and endpoint indirection.

Is UDDI Only for the Public Internet?
Along with SOAP and WSDL, UDDI is considered one of the three "pillars" of Web services technologies. Unfortunately, it is probably the least understood, at least initially. At the root of the various misconceptions about UDDI is the schizophrenic nature of the specification. The UDDI idea initially (and to this day) encompasses two very distinct concepts. The first one is the concept of a universal, online business registry, the Universal Business Registry (UBR), maintained and operated by a set of impartial operators along the lines of the DNS infrastructure. It is hoped that this UBR will act as some form of universal, multilayered "phone book" for registering businesses and the services they provide across the world, (for good or bad, this "universality" is baked into the UDDI name). This is the concept most people know about, and the one that is the most discussed, at least by the various UDDI naysayers. It is also perhaps the one least relevant to business, and just one incarnation of the more important concept behind UDDI: that of a generic services registry based on a set of open, standards-based, data structures and a set of SOAP-based APIs to programmatically register, organize, and find services and their descriptions.

Where UDDI is seeing its greatest adoption and showing greatest value is inside the enterprise. There, with some minor enhancements, it can bring security and flexibility to the process of publishing, discovering, and subscribing to internal services. The alternative is a disorganized soup of services that are published by local teams without any central organization, security, or management. With UDDI V3, the necessary functionality now exists for UDDI to take its place as core enterprise integration infrastructure.

UDDI Basics
When UDDI was first released, the concept of registries was by no means new. Corporate IT departments had been using naming and directory services for some time and several vendors had commercial registries on the market. The difference was that UDDI proposed an open collaborative effort to produce a standards-based registry that was not controlled by any vendor. Requirements for a registry are well understood: a data model for the metadata and a set of CRUD operations on these structures. The data model has to enforce ownership and containment requirements; a logical, consistent referencing system for the containment relationships; and a classification taxonomy to simplify searching. The CRUD API has to enforce security or authentication for operations that change data, and provide a query language for searching and retrieving data. The requirements that went into designing UDDI are no different.

UDDI has been described in detail in many articles and books but it would be helpful for us as a baseline to go over its structures and API. The UDDI data model has four main elements: businessEntity, businessService, bindingTemplate, and tModel. Use of the word "business" in two of the elements is unfortunate, but it should not be a deterrent since the pattern of registering and querying entities and the services they provide is useful, regardless of the name of the elements. Actually, with the proper XML transformations, the UDDI data model can be reused for a variety of purposes by changing the names of the elements.

The containment model is very simple: business entities can contain a set of business services; business services have binding templates that provide implementation details for the various implementation flavors of the business service (e.g., Web browser-based or e-mail- based implementation of the same basic service); and finally tModels provide the reference or namespace mechanism used in the description of how to access these services.

The tModel concept is extremely important in understanding UDDI. You can think of it as a set of technical signatures that are assigned to services to facilitate searching and categorization. A set of tModels has already been established to represent some of the more important technical concepts such as HTTP or SOAP. As an example of how they are used, consider a service that is accessible through SOAP over SMTP: it would be labeled, among other tModels, with the SOAP and SMTP tModels. When searching for a particular service to access through SOAP over SMTP, the search can be restricted to entries labeled with those two tModels.

Another important use of the tModel is as a namespace. An industry group, for example, can create their own tModels to designate business processes and services that are provided by their members; in this case, searches can be restricted to services within that namespace by using the appropriate tModel as a qualifier.

The UDDI API has two subsets: an authenticated Publishers' API to save, update, delete, and manage entries with security token management; and an open Inquiry API to find entries and get detailed content from them. In addition to the data model and the API, the UDDI specification allows the use of taxonomies for organizing the entries space and searching through it. Three taxonomies, for businesses, products and services, and geographic location, were originally specified.

UDDI V2: Becoming Enterprise Friendly
The UDDI v2 specification provided some additional flexibility in the UDDI usage model, mainly in providing the capability to add third-party taxonomies to the three that were already part of the specification. This provides enormous flexibility for organizations, whether private companies or consortia, for example, to define their own taxonomies and overlay them over other taxonomies. Another important concept introduced in v2 is that of business relationships through so-called publisher assertions. This allowed businesses (or organizations) to indicate that they are related through a partnership or other affiliation. Along with the additions to the data model, V2 introduced some changes to the API to handle the new data structures and relationships.

UDDI V3: Built for the Enterprise
The original UDDI specification was mainly concerned with enabling a set of central universal registries and some of the constraints reflect these concerns. For example, the original specification required operators to issue unique identifiers for every registry entry. These identifiers took the form of UUIDs, and could only be generated by the operators, in order to avoid clashes and inconsistencies in the identifier namespace. This is a perfectly acceptable restriction in the case of one universal registry, but becomes unworkable when several independent registries need to share information as is common inside the extended enterprise.

An example enterprise scenario facilitated by UDDI V3 but not its predecessors occurs when Web services are being developed internally and published to a test registry. Once these services become operational, they have to be migrated to one or more operational registries, whether internal or external. Once propagated, the integrity of these registry entries needs to be ensured against tampering, since the single UBR, with its trusted operators, is not being used. This scenario touches on several important requirements that were taken into account for V3, namely the ability to share entries between registries, while maintaining the referential integrity of the assigned keys; and the ability to sign and certify registry entries.

The V3 specification provides many new features, but the significant ones are geared towards making UDDI registries into more of an enterprise-class IT infrastructure by addressing some of the issues above. These improvements can be grouped under three main categories:

General extensions:

  • Publisher-assigned keys: In versions 1 and 2, the role of assigning unique keys for every entry in UDDI fell to the registry operators. While essential for the integrity of the registry, this constraint made copying entire entities from one registry to another, while maintaining the unique key, impossible. V3 does away with that constraint, in order to support multi-registry environments. Using the Publishers' API, publishers can propose their own keys while publishing entries to new registries. This is called entity promotion from one local UDDI registry to another, and depending on its policies, a registry might not accept the suggested keys. Of course this creates its own complexities in terms of referential integrity of the keys. That's why three new and important concepts were introduced: support for root and affiliate registries; support for human-friendly URI-based keys; and support for digitally signed entries.

  • Federation of registries: In order to support inter-registry data sharing while avoiding key collision, V3 now supports the concept of federated UDDI nodes, with a root registry and a set of affiliate registries. Publisher assigned keys are now scoped only within a hierarchy of UDDI nodes. Data from within the hierarchy can be freely moved around while conserving the uniqueness quality of the keys.

  • Human-friendly, URI-based keys: in order to facilitate inter-registry data copying, the restriction for generating unique identifiers (UUIDs) for entries was relaxed, and a new format of identifiers was introduced, similar to the DNS format.

  • Support for digital signatures: Although the Publishers' API (allowing the creation, deletion, and editing of entries) has been authenticated since V1, entries can be misrepresented by third parties, or errors introduced by copying them to other registries now that entries can be moved about within a set of federated registries. V3 allows entries to be signed digitally, for an enhanced level of security and integrity. Digitally signing an entry allows users who receive the entry to be certain of its origin, and that it hasn't been tampered with.

  • Support for policies: V3 registries now support policies that outline authorization models, audit policies, and confidentiality policies, among others.

    Information model extensions

  • Improved WSDL support: Until V3, a WSDL document had no special status in describing a service. Through the introduction of the useType attribute to the accessPoint element, WSDL documents can now be queried and retrieved directly.

  • Added categorization capability for the bindingTemplate element: Implementation details can now be searched using the same taxonomies used for businesses and services.

    Extended discovery

  • Support for complex queries to be consolidated into single queries through the use of nested queries
  • New and extensible find_qualifiers with extended wildcard support
  • Management of large results sets

    So What's Still Missing?
    Taking all these improvements into consideration, the UDDI V3 specification provides an infrastructure that, in keeping with the spirit of UDDI, provides a flexible and extensible framework for Web services without actually specifying the detailed scenarios. However, two important issues have not been addressed by the specification. Consider the scenario where an organization is using a private UDDI registry to provide internal services for its IT department, and to provide a registry of interfaces for trusted business partners for the purposes of integration. This is probably the most common use of UDDI today and for the foreseeable future. For security and functionality, such usage would have to be through a proxied UDDI registry and would impose two additional requirements on any UDDI implementation.

  • Access control on the Inquiry API: In keeping with the original intent of a "universal" registry, the current Inquiry API is completely open, and only the Publishers' API is authenticated. In the scenario above, the organization will require an authenticated Inquiry API to control access to its registry, whether the requests are coming from inside or outside the firewall. This is a relatively simple requirement that can be added to the existing specification by adding an access control layer to the implementation.

  • Customization of the query returns to the requester: Even an access controlled UDDI registry is not completely functional in the scenario above. Typically, different departments will have access to different services. And even when they have access to the same services, they might have different endpoints or they might expose different interfaces. This is even truer in the case of external partners. In these cases, providing some access control to the UDDI registry is only the first, and simplest, step in proxying it in terms of security. What is required is a mechanism to present different results to the same query based on the requester. For example, as a result of the same binding detail query, platinum-level partners will get a WSDL that exposes a richer interface on a particular service than gold level partners, and might even expose a different endpoint.

    While these capabilities may seem minor they represent the bedrock of creating a secure and flexible Web services infrastructure. Without these capabilities there is no way of controlling and personalizing access to the various services published on the UDDI v3 registry, an important aspect of current and future Web services usage. The good news, however, is that when combined with a Web services security and personalization technology capable of proxying both WSDL and UDDI, UDDI v3 can be employed by enterprises to manage the entire service publishing and subscription lifecycle at the center of service oriented integration.

    About Toufic Boubez
    Toufic Boubez is the co-founder and CTO of Layer 7 Technologies. Prior to co-founding Layer 7 Technologies, he was the chief Web services architect for IBM's Software Group and drove their early XML and Web services strategies. Toufic co-authored the original UDDI API specification. He’s the co-editor of the W3C WS-Policy specification, and is a co-author of the WS-Trust, WS-SecureConversation, and WS-Federation specifications. Toufic is a sought-after presenter and has chaired XML and Web services conferences. In 2002, InfoWorld named Toufic to its “Ones to Watch” list. An author of many publications, one of his most recent books is "Building Web Services with Java: Making Sense of XML, SOAP, WSDL, and UDDI."

  • In order to post a comment you need to be registered and logged in.

    Register | Sign-in

    Reader Feedback: Page 1 of 1

    SOA World Latest Stories
    21st International Cloud Expo, taking place October 31 - November 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA, will feature technical sessions from a rock star conference faculty and the leading industry players in the world. Cloud computing is now being embraced b...
    With the rise of DevOps, containers are at the brink of becoming a pervasive technology in Enterprise IT to accelerate application delivery for the business. When it comes to adopting containers in the enterprise, security is the highest adoption barrier. Is your organization ready to ...
    Agile has finally jumped the technology shark, expanding outside the software world. Enterprises are now increasingly adopting Agile practices across their organizations in order to successfully navigate the disruptive waters that threaten to drown them. In our quest for establishing c...
    There is a huge demand for responsive, real-time mobile and web experiences, but current architectural patterns do not easily accommodate applications that respond to events in real time. Common solutions using message queues or HTTP long-polling quickly lead to resiliency, scalability...
    Enterprises are moving to the cloud faster than most of us in security expected. CIOs are going from 0 to 100 in cloud adoption and leaving security teams in the dust. Once cloud is part of an enterprise stack, it’s unclear who has responsibility for the protection of applications, ser...
    Many organizations adopt DevOps to reduce cycle times and deliver software faster; some take on DevOps to drive higher quality and better end-user experience; others look to DevOps for a clearer line-of-sight to customers to drive better business impacts. In truth, these three foundati...
    Subscribe to the World's Most Powerful Newsletters
    Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
    Click to Add our RSS Feeds to the Service of Your Choice:
    Google Reader or Homepage Add to My Yahoo! Subscribe with Bloglines Subscribe in NewsGator Online
    myFeedster Add to My AOL Subscribe in Rojo Add 'Hugg' to Newsburst from CNET News.com Kinja Digest View Additional SYS-CON Feeds
    Publish Your Article! Please send it to editorial(at)sys-con.com!

    Advertise on this site! Contact advertising(at)sys-con.com! 201 802-3021


    SYS-CON Featured Whitepapers
    ADS BY GOOGLE