Maintaining the Core – Service Repository - Applied SOA Patterns on the Oracle Platform - page 328

have a different syntax for the binding.ws element, describing the Endpoint's binding
location.

Endpoint
type

Binding realization

<binding.ws port="http://ctu.com/wsdl/dev/uddi/services/
#wsdl.endpoint(OrderStatusService/OrderStatusService)"
location="http://localhost:7201/registry/uddi/doc/dev/
OrderStatusService.wsdl"
soapVersion="1.1">
<property name="oracle.soa.uddi. serviceKey " type="xs:string" many="false">
uddi: 9AF82521-F6A9-1ba3-C094-2C7FE45CD859

SOA End-
point

</property>
</binding.ws>

<binding.ws port="http://ctu.com/fulfillment/
order#wsdl.endpoint(OrderStatusService/OrderStatusService)"
location="orauddi:/uddi: 9AF82521-F6A9-1ba3-C094-2C7FE45CD859"
soapVersion="1.1">
</binding.ws>

WSDL

Now you can use any service with the dynamic address resolution in any service composi-
tion. This basic yellow topic functionality is perfectly fine, but we need more search cap-
abilities with adequate granularity for search criteria, which is suitable for our agnostic
controller. Here, we face the second type of limitation (apart from the lack of taxonomy
guidance, which is mostly based on the WSDL binding)—limited search capability. In
general, the classic UDDI provides us with search restricted to the WS name and its clas-
sification. Because of the name-value pair approach of the tModels, there is no uniform
way to query services and their attributes. Some attempts were undertaken in the UDDI
V.3 specs (see sections 4 and 5.1.8 of the Inquiry API functions, http://uddi.org/pubs/uddi-
v3.0.2-20041019.htm#_Toc85908076 ). You will find 10 generic functions to find core
UDDI entities (Business, Service, and Bindings) and get details about them, including
tModels.

Oracle offers a solution for these limitations by providing the UDDI API, which covers
both Ds—Description (Publishing API) and Discovery (Inquiry API). In the scope of dy-
namic composition controller functionalities, the latter is of higher interest to us. Technic-
ally, we have two Inquiry APIs: ClientSide and UI. The last one has only one operation,
get_entityDetail , which will return the list of UDDI data structures. Using the Cli-
entSide API, you can call any standard UDDI V2 inquiry function. The most commonly
used parameters are Name ( find_<searchingEntity>.setName(new
Name(Name))) , serviceKey