| |

Introduction

Ruddi allows developing UDDI applications using an UDDI-specific vocabulary. The name of a Ruddi data structure always corresponds to the name of the UDDI notion it represents. For example, BusinessEntity is the name of the Ruddi class for the businessEntity UDDI notion. As a result, a Ruddi developer can directly refer to the UDDI specification in order to get fine-grained details on a Ruddi class.

Ruddi data structures support for the various UDDI versions

Ruddi supports the UDDI 3.0, 2.0 and 1.0 specifications. Some Ruddi classes are hence of interest only starting from a given version of UDDI, or even specifically to a given version of UDDI. For example, the notion of PublisherAssertion was new to UDDI 2.0, and is hence of no interest to interact with an UDDI 1.0 registry. In order to facilitate the work of the developer, the Ruddi Javadoc documentation always reports the UDDI specification level that introduced the notion a Ruddi class represents. Similarly, for the UDDI notions that have evolved from one version to another, the Ruddi Javadoc documentation mentions the UDDI specification level that applies, method by method. Ruddi classes and methods that don't apply anymore starting from a given version of UDDI are marked "deprecated".

Ruddi data structures initialization

UDDI data structures are rather complex: depending on the UDDI specification level used, some informations are required to the proper initialization while others are optional. Ruddi enforces proper initialization of data structures thanks to an API that really reflects the proper initialization needs of UDDI data structures. To do so, the following conventions apply to all Ruddi data structures:

• UDDI parameters that are required for the proper initialization of UDDI data structures are parameters of the constructors of the corresponding Ruddi data structures.
  For example, a Ruddi DiscoveryURL has a constructor that takes two parameters, the discovery URL itself and its use type. In UDDI 2.0 and 1.0, both informations are indeed required to build a valid discoveryURL . A constructor that doesn't take any use type information is also available since UDDI 3.0 because the use type has become optional starting from that version of the UDDI specification. The Javadoc documentation of Ruddi for this constructor makes it very clear. As we can see, the developer is sure to always build a valid UDDI data structure whatever the constructor used. A constructor that wouldn't have lead to proper DiscoveryURL initialization would have been marked "deprecated", and the Javadoc documentation would also have mentioned starting from which version of UDDI the constructor shouldn't be used anymore.
  
• Setter methods are only available to set optional UDDI parameters.
  Setter methods are only available to set optional UDDI parameters as far as the required parameters are directly passed to the constructor. A developer can't alter the value of the fundamental parameters that make up a Ruddi data structure. The library indeed enforces a new Ruddi data structure instance to be created instead.
  
• Getter methods are available on all UDDI-related parameters.

Ruddi data structures and XML serialization

In most cases, a Ruddi developer can appropriately instantiate the Ruddi classes without having to worry about the targeted UDDI registries. Indeed, the Ruddi runtime automatically serializes the Ruddi objects into the XML format appropriate to a given version of UDDI. During the serialization process, the notions that are not relevant to the targeted UDDI level will simply be ignored. All the Ruddi developer has to ensure is that each Ruddi data structure is initialized with "enough information" whatever the targeted UDDI level. By "enough information", we mean that the value of the information provided still allow answering the requirements of the problem domain, for all the targeted UDDI versions. An easy way to verify what information is actually posted to an UDDI registry is to enable logging. Logging allows monitoring the conversation between the Ruddi application and an UDDI registry.