UDDI V2 new features: association relationship and publisher assertion
(This article was originally published by the IBM DeveloperWorks China website, its URL is http://www.ibm.com/developerWorks/cn/)
(This article is the UDDI V2 new features I have published in the developerWorks column: the reduction of the association relationship and the publisher assertion, you need to browse the original text, please visit http://www.ibm.com/developerWorks/cn/)
The needs of enterprises have contributed to the relationship characteristics
With the release of the UDDI 1.0 Registry, many large enterprise groups, and some virtual commercial entities such as trading markets and trade groups believe that the UDDI specification number 1 is not supported for registration of complex business information. At the same time, the feedback information of the implementation of the UDDI specification 1st version indicates that the service and binding information for each independent commercial entity (possibly use of the same service) is very implementable, but it is not optimized. In addition, other feedback indicates that users are required to distinguish between commercial entities, which can only be implemented, which often makes users feel confused (because some companies often have multiple customary names).
In the July 2001, the UDDI specification version 2.0 introduced a "publisher assert" assertion feature based on the core issues in this use. The publisher assertion is the basis of such a mechanism, which can make more registered BusinessEntity elements to link to each other in some way to represent a particular type of associated relationship. This is also the reason why this feature is often the relationship characteristic. The publisher asserts that once a complete creation is created, it is used to establish a public visible association relationship in the registered data, such an asserted performance result will be confirmed by the general query message in the new UDDI V2, Find_ReledBusinesses is The API calls for finding those BusinessSentity have a relationship with a specified businessentity in the UDDI registry.
The design objective surrounding the associated relationship between the commercial entity can describe the relationship between the different components is to meet the needs of the large commercial entity as described in UDDI, so that they can implement multiple components in the UDDI registry. registered. After all, large-scale commercial entities are composed of many small components, while each commercial individual has many different types of Web services needed. Before the UDDI specification version 2.0, the registrant who wants to model the very complex commercial entity cannot complete the required function.
In order to make the association relationships have certain control capabilities for the public visibility of the association relationship, another design objective is to ensure that both parties agree to the hypothesis of the assumption in a potential relationship. This association is visible. This design goal is for the following potential questions: When an entity falsely claiming its registered businessentity data is an integral part of a big company, it will bring losses to large companies that do not agree to the assert. For the reader of the registration data, they may be guided by falsely, and believe that this registered commercial entity is indeed part of the other big company.
Relationship model
In UDDI V2, the basic model of the association relationship is an assertion element using the PublisheraSsersion, and a publisher assertion represents an assertion of a user's association relationship between businessentity. The basic structure of publisherassertion is as follows:
A publisher assertion consists of three sub-elements fromKey, Tokey and KeyedReference, forming a relationship as shown below:
Where fromKey and Tokey are a BusinessKey, pointing to an existing registered BusinessSentity. KeyedReference expressed what relationship between BusiesSentity referred to by Fromkey to Business All, from ToKey.
We see that the KeyedReference element still follows the structure of KeyedReference in UDDI V1, indicating which of why the use of the associated relationship definition is used, where "UUID: TBD" is used as a UDDI built-in relationship representation. KeyValue indicates the code of the associated relationship, and KeyName is a name description of the associated relationship code indicated by KeyValue.
Social management of related relationships
The Publisher API defines several messages to enable UDDI publishers to manage assertions. These messages can be divided into two categories: assistance management functions and maintenance. A message to assist the management category is the assertion associated with the publisher to review the business entity he managed. In particular, get_assertionStatusReport is very useful for the assertion involved in judging all commercial entities managed by the publisher. The message not only makes you find those asserts is that you still need to do it, but also let you find out if other pubrs are trying to create assertions related to your business entity, and this assertion may be you don't know. Or disagree.
Maintenance Function The message can make the publisher to perform single operations for all assertions (such as add_publisherassertions, and delete_publisherassertions) can also operate with all assertions as a set of assertions (such as GET_PUBLISHERASSETISETITIONS, and SET_PUBLISHERASSERASERASSERASSERASSERASSERASSETITIONS). If the publisher wants to add an assertion at some point, don't want to know all the assertions below it before, then the news that uses those assertions is very convenient.
Note: The SET_PUBLISHERASSSERTIONSSSSSERTIONS message can be used to make all assertions no longer valid by deleting all assertions in a call.
