In a recent discussion about Governance with some customers this week, an interesting subject came up. They are well on their way with a SOA implementation and are beginning that the time to govern it is now. This is not at all unlike *many* folks that I talk to.
SOA is becoming more and more an important part of EA; in fact the SOA aspect of TOGAF is apparently getting majorly beefed up in the next implementation. It is key because SOA is *not* a technology, but an architectural solution approach that is unique in its tie to providing business value.
Anyway, back to the customer, they want to use dynamic service endpoints exclusively and eschew hard-coded endpoints entirely. One of the chief benefits of Oracle’s OER/OSR (Repository/Registry) is the ability to harvest and manage service lifecycles to include publishing endpoints to the UDDI Registry and generating unique Service Key’s. Once you have the Key, you can access the service by dynamically looking up the end point without having it baked into your code. This provides a great deal of flexibility.
I found a blog from Edwin Biemond that shows you how to use this Service Key as an indirection to the actual service from within SOA Suite.
“Look Ma’, no hard coded endpoints..” – from the blog it shows how the UDDI Inquiry API is used instead of a specific service location. This spells flexibility.
1. <reference name="HelloService" ui:wsdlLocation="BPELProcess1.wsdl">
2. <interface.wsdl interface="http://xmlns.oracle.com/HelloWorld/Helloworld/BPELProcess1#wsdl.interface(BPELProcess1)"/>
3. <binding.ws port="http://xmlns.oracle.com/HelloWorld/Helloworld/BPELProcess1#wsdl.endpoint(bpelprocess1_client_ep/BPELProcess1_pt)"
5. <property name="oracle.soa.uddi.serviceKey" type="xs:string" many="false">uddi:d798e4c0-f4ab-11de-8e46-d0e4b9a18e45</property>