Implementing Siebel for SOA (Part 2)

In last week’s posting, I outlined some of the key considerations for implementing a SOA-based architecture, and explained how support for SOA could in part be achieved by considering the functional granularity of the Web Services exposed through Siebel.

This post moves on from that, covering Service Abstraction and Loose Coupling with the context of Siebel, completing the core considerations to be taken into account when exposing Siebel Web Services in a SOA environment.

Service Abstraction and Loose Coupling #

Internal Siebel Integration Objects, when converted to XML, are reasonably complex and, equally importantly, they are in a proprietary format. They are not intended to be exposed to the outside world through a Web Service definition – doing so would generally make the service contract unnecessarily complicated.

And so we come to the first level of abstraction – the idea of using external Integration Objects to provide the public-facing messages.

Data Structure Abstraction

Using external Integration Objects ensures that, in any WSDL generated from a Siebel Service, a less-proprietary interface can be exposed. At runtime, data mapping routines will then convert data supplied this external definition into an internal definition, and vice versa.

In itself, this is nothing new, but once again a significant amount of the value of using external Integration Objects is realised through the manner in which they are developed.

Let’s consider the addCustomer service that was discussed in the last posting – its service will add an Account, two Address records, a Customer record and an Activity record. There are several ways this could be implemented, but in order to assure transactional integrity it is likely the Siebel Developer will model a single internal Integration Object instance, representing a hierarchy comprising the four separate data entities.

The mistake that is often now made is for that internal Integration Object instance to by copied and defined as the external Integration Object for the service – thus simplifying development effort on the Data Mapping routines, but with the result that the public messages are overly complex and – worse still – potentially request more information than is strictly needed.

If one considers what this service actually requires as an input, it becomes clear that it only requires some basic customer information, the attributes of which have – in the context of this public facing service – a 1:1 relationship with one another.

This instead of middleware needing to build a proprietary hierarchy format in order to call the service, and potentially duplicating data delivered within that hierarchy, a flat structure can instead be sent.

What advantages does this give us?

The first is that consumers of the Web Service now no longer have to interpret the data in a proprietary Siebel format – the message is logically sound but significantly less complex. This cuts down on the effort and time required for third party middleware/application developers to interpret the contract and build an interface to it, as well as reducing the complexity when testing and debugging.

The second advantage is that the volume of XML tags contained within the message format are significantly reduced (the ListOf tags are by default significant), reducing the network and server processing burden. While it may seem such an overhead is miniscule for any individual message, today’s architectures will see millions of Web Service calls per day, and a lack of consideration for message brevity will have a measurable impact.

Data Decoupling

Building on the idea of ensuring public-facing data structures are simplified abstractions of the internal structures, the next step is to limit coupling at the data level. The area which provides most scope for decoupling is static data.

There are two methods that can significantly reduce the coupling here – the first is considering whether a field’s value is a simple choice between two LOV entries, and the second is considering how to derive the value of LOV-bounded fields based upon some other values provided, or on logic that is executed within the implementation of the Web Service.

Abstracting Fields With A Choice of Two Values

Consider the Web Service above, addCustomer. If a "Status" is required for the Account, the external integration object might expose a field called “Status”, which could take values of either “Active” or “Inactive”. There are two problems here. The first is that Siebel’s list of values are not automatically added to generated WSDLs as Enumerations, so any consuming system (i.e. the third party developer) has to be explicitly told about the possible values. The second issue is that if the Siebel development team decided to change the system to use something other than “Active” or “Inactive”, the calling system would need to be told about it.

(Of course, it could be argued that the Siebel Development Team could update the data mappings to convert the old values into the new values when the service is called, thus avoiding the calling system needing to make any changes. However, if after the change another system consumes the service, and then the underlying values are changed once again, there will be mappings from multiple “old” values to the latest values, increasing the complexity of maintenance. Additionally, given the calling systems have gone to the trouble of generating Siebel-proprietary field values, it is surely incorrect to then transform those values again.)

The solution is to abstract the fields of the external Integration Object yet further. In this case, rather than exposing a “Status” field, the ideal choice is an “IsActive” field, which takes a Boolean value as in input. Providing such an interface will ensure that consuming systems find it easier to develop interfaces to the service (especially as Siebel’s generated WSDLs will strongly-type the Boolean field) and Siebel Developers can change the underlying stored values and simply adjust data mappings when necessary. Going forward, Siebel maintenance will be simpler as any new person looking at the interface will be looking at logical, descriptive external structures with clean data mappings to the internal structures.

Deriving Field Values from Service Logic or Other Field Values

In many services, there exists the opportunity to derive the values for some fields simply from other data that is provided, or alternatively from the logic that the service is applying.

An example might be the Status field for the addCustomer service. Does a value need to be supplied from a calling system? If this service is only ever being called to add new customers, and they in turn should be considered “active” customers, then clearly the value for this field can be defaulted within the Data Mapping routines rather than being explicitly supplied.

The business might also wish to store a flag indicating whether the customer is eligible for credit card marketing, which is driven by the person being over eighteen years of age. The value for this flag would be driven from a calculation on the supplied Date of Birth field, rather than asking any calling system to supply the flag explicitly (and thereby duplicate the logic unnecessarily across multiple applications).

Summary #

These two posts have only covered the basics for enabling Siebel for a SOA environment - there is far more that must be considered in order to minimise effort and ensure SOA is appropriately supported. However, by implementing these techniques, an organisation can already take advantage of 1) simpler interfaces and a reduced cost of development; 2) a reduced cost of interface maintenance; and 3) improved architectural flexibility.