Hello again Farrukh. Comments below. Paul
At 09:07 AM 2005-09-20, Farrukh Najmi wrote: >First, I want to make clear that I think UDDI is a fine standard for the >kinds of simplere problem that it was designed to address (Yellow /White >/ Green pages). >Where I think UDDI is inappropriate a fit is in complex probolems such >as SOA Governance for which UDDI was not deigned for. Perhaps an analogy to buying a hifi audio system for the home is applicable. You can buy a package that includes speakers, amp, tuner, cd, (in older times, phono and tape). Each component may not be the best available, but the package is integrated; one stop shopping. Or you can buy individual components and integrate them yourself. UDDI was kept simple (relatively) by design. It was designed to do its registry function: 5.1 Inquiry, 5.2 Publication, 5.3 security policy, 5.4 Custody and Ownership 5.5 Subscription 5.6 Value Set Keeping it relatively simple makes it easier to implement and faster to market, but you then need to figure out how to fit it into the larger SOA environment. The repository function was intentionally not included in UDDI. Other repository functions are available. There are numerous content management systems (CMS) that can serve as a repository. Also, the number and types of information needed to thoroughly describe the things registered in UDDI are likely to be scattered. Even if you could put some things into a central repository (WSDL, XSD, XSL, ...), there will be other things that the owners of them choose not to place in that central repository. So the registry will almost always need to link to artifacts stored in a variety of places on the network. Many of these SOA artifacts will not be needed at runtime (i.e., immediately prior to when the services are invoked). ></snip> > >I believe standards based functionality is important because ... We need to be clear. The standards only go so far. Then there is the way you choose to apply the standard. ebReg calls them "Profiles". UDDI calls them "technical notes" (TN) and "best practices" (BP). ><?snip> >See point about "anything is possible in software" above. With ebXML >Registry the processes for publish, approval, validation, cataloging, >versioning, deprecation, undeprecation, deletion etc. are defined by a >standard. Stop. "Approval" and "validation" will be based on policies established by the organization. The standard can go only so far before you need profiles/TN/BP to describe the specific approval process for a given registry(repository). Approval may apply to things (metadata) published to the registry, or to the use of things (data) whose metadata is published to the registry (e.g., approval to use a service). Validation can apply to the repository, e.g., to validate an XML document against an XSD. Validation can also apply to the categorization of a registry object. Validation may be as simple as determining whether a category is valid for a particular taxonomy or classification scheme (controlled vocabulary). Or validity can be more complex, such as, whether the category should apply to that particular entry and if the publisher is permitted or trusted to assign that category. I may have a category "approved to operate", but its not the service providers call to determine that. Thus the registry needs hooks, or extensibility points, where more complex approval and validation processes can be invoked. I think UDDI and ebReg both have such extensibility points. Then we have cataloging, which I understand is the extraction of metadata from data or content. Ideally, this can be automated, and the metadata stored in the registry. Since UDDI does not have a repository function, it cannot define APIs and extensibility points for cataloging. However, UDDI TNs and BPs can be used to describe what should go in the registry for particular types of content, which would be stored outside UDDI. The example here is WSDL. UDDI defines a BP for WSDL that has been around since UDDI v2, and an updated TN for UDDI v3. I hear that ebReg has a catalog profile(?) defined for WSDL, such that, a WSDL published to the ebReg repository can automatically add ebReg registry entries (metadata). For example, you could look at the WSDL and pull out the namespace URIs and add them to registry entries. This allows you to search the registry for WSDL that use a particular namespace URI. I have not found where the WSDL cataloging is specified. Is it within an OASIS spec, profile, or is it product-specific? >There is no vendor specific extensions needed. Each of these >can even be customized for specific verticals using vertical defined >extension profiles. > > > > 1. 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. > > >As you know UDDI has 4 or so pre-defined queries (findBusiness, >findService, findTmodel etc...). >Even these 4 queries do not support arbitrary disjunction and >conjunction of predicates. It is fairly >limited in practical terms. I can agree to a point. I see no practical difference between one generic "query" operation that takes four different query expressions (business, service, binding, tModel) and four artifact-specific queries (find_business, find_service, find_binding, find_tModel). Would wrapping find_business with a generic <query> tag be much different; e.g., <query><find_business>...</find_business></query>? I think not. I agree the arbitrary disjunction and conjunction is not supported in UDDI, but I think the restrictions in UDDI were intentional to keep it simpler to implement, yet still very useful. The complexity of the query in most cases will be hidden from the general user by a GUI, or embedded in an application by an engineer who can grok the UDDI limitations and ebXML complexity (if such arbitrary queries are needed). ></snip> ... > > 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. >Just to be clear, I dream about federated repositories that span the >universe :-) > >Picture a birth/death federated repository that spans an entire country >(that vision is actually in the works). > > > > > > 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. As I mentioned above, there will almost always be things (SOA artifacts) outside of the central repository. Policy enforcement in many cases will not belong in the registry. The policy enforcement point (PEP) may be in a fabric or ESB. You may be able to find the policy documents by searching in the registry. You may want to limit access to the policy documents such that only the PEP(s) can access them. It is a policy decision whether to synchronize access control lists (ACLs); i.e., the ACL for the service endpoint being the same as the ACL for the registry entry for the service. It can get difficult to keep these ACLs in sync. In many cases, you will allow broader access to the registry entry than to the service endpoint (or other SOA artifact). Just because you can see the registry entry for a service does not mean you can access the service. > > > > -Ability to support artoifact specific parameterized discovery > > queries In many cases a web GUI will be placed in front of the SOAP APIs to a registry/repository. Registry vendors typically provide such a GUI, but they tend to be somewhat generic. The GUI is often tailored for a particular environment. For example, an organization may use a particular taxonomy to categorize their entries. The generic GUI would require them to find their taxonomy, then drill down. Depending on the registry contents, there may be many taxonomies that confuse people who only want to find a subset of registry entries. So a tailored GUI would be developed that is easier for people from a particular organization to navigate and limited to a specific taxonomy. Parameterized queries would be built when the tailored-GUI is developed. > > > > -Fine grained custom, role based access control of artifacts Again, limited to those artifacts whose owners agree to store them in the central repsoitory. > > > > -Extensible metadata and protocols > > > > -Extensible taxonomies with no need for external validation > > services to > > validate ussage of taxonomies As I mentioned above, validation can be simple or complex. The more complex the validation, the more likely that you will want it to be external to the registry; e.g., a BPEL process or workflow involving a business rules engine (BRE). I am still learning about ebReg, so I do not fully understand the dimensions of extensibility. For example, I'm not sure what you mean by an extensible taxonomy. If you mean that additional taxonomies can be added to a registry, then UDDI supports that: just create a tModel to uniquely identify the new taxonomy. I understand that ebRIM allows you to define the taxonomy categories (taxons), whereas, UDDI does not specify this in much detail. UDDI's value set API defines a way to transfer a set of valid values, but it does not preserve any hierarchy or relationships among the categories. > > > > -Extensible relationship between artifacts ebRIM is more flexible than UDDI in this regard. UDDI defines some relationships between business entities (e.g., parent-child), but there is no clear way to define relationships, for example, between service entries. You can probably dream up a way to use categoryBags and keyedReferenceGroups, but it would require a TN/BP to be applied consistently. I imagine an ebReg profile would also be needed to describe some relationships. > > > > -Content based event notification using extensible artifact > > specific queries Given that ebReg is a repository, this becomes more important than in UDDI. I expect many CMS's will also support content-based event notification. Standards for event notification are still developing, i.e., WS-Notification. > > > > -Federated queries able to search across multiple stores that contain > > non-overlapping data This can be an important distinction between ebReg and UDDI. I am anxious to see this in action. Non-overlapping is an interesting caveat. My customer/sponsor (US DoD) has a complex environment. If the Air Force fields a web service, call it [S1], it may be registered in an Air Force registry [R1]. If the Navy finds the Air Force service useful, the Navy may register [S1] in a Navy registry [R2]. If [S1] is registered in both [R1] and [R2], then there is overlap. I guess you can argue that the Navy should not do that and just let the Navy registry talk to the Air Force registry, but then we get into response time issues and concerns about intermittent connectivity. The Navy may also want to annotate or say something more about [S1], which may be harder to do if [S1] is only registered in the Air Force registry. ------------------------ 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/
