Databases Reference
In-Depth Information
Note that we use XPath string functions to set the username and password fields.
It would be better to set these from the properties or an external file, as we would
usually want to use them in a number of calls to the physical service. XPath functions
are capable of allowing access to composite properties. We actually only need to set
five fields in the request, namely, a country, postcode, username, password, and the
maximum number of results to return. All the other fields are not necessary for the
service we are using and so are hidden from end users because they do not appear in
the canonical form of the service.
Applying canonical form in the Service Bus
When we think about the canonical form and routing, we have several different
operations that may need to be performed.
•
Conversion to/from the native business service form from/to the canonical
proxy form
Conversion to/from the native client form from/to the canonical proxy form
Routing between multiple native services, each potentially with its own
message format
•
•
The following diagram represents these different potential interactions as distinct
proxy implementations in the service. To reduce coupling and make maintenance
easier, each native service has a corresponding canonical proxy service. This isolates
the rest of the system from the actual native formats. This is shown below in the
Local-Harte-Hanks-Proxy
and
Local-LocalAddress-Proxy
services that transform
the native service to/from the canonical form. This approach allows us to change the
native address lookup implementations without impacting anything other than the
Local-*-Proxy service.
The
Canonical-Address-Proxy
has the job of hiding the fact that the address lookup
service is actually provided by a number of different service providers, each with
their own message formats. By providing this service, we can easily add additional
address providers without impacting the clients of the address lookup service.
