Implementing Siebel for SOA

Over the last six years we’ve seen more and more companies implementing SOA-based architectures and including Siebel within them. With Siebel’s support for Web Services now more than seven years old – and still evolving – it is considered an application that provides straightforward support for SOA.

Over the last six years we’ve seen more and more companies implementing SOA-based architectures and including Siebel within them. With Siebel’s support for Web Services now more than seven years old – and still evolving – it is considered an application that provides straightforward support for SOA.

However, while Siebel itself has most of the functionality needed to easily support SOA, the ability for it to do so depends upon the development team performing the implementation. Why? Because SOA is not simply the exposure of Web Services – it goes far beyond that. The aim of this post is to cover some of the key areas that developers should consider when implementing Siebel within a wider SOA-based architecture.

Key SOA Concepts #

There are a multitude of publications describing SOA’s core concepts, and it is not the purpose of this post to repeat them here. There are however several concepts which we need to focus on:

Service Granularity #

Absolutely key to the concept of SOA is an appropriate level of granularity of the exposed Services. What does this mean in the real world? At a basic level, the SOA approach dictates that each Service should encapsulate a business function (for example, Pay Bill or Close Account), rather than being based upon a low-level IT concept (e.g. updateAccount).

While the level of granularity achievable is dependent on the application and the ability to bundle its logic into appropriate Services – part of SOA dictates that Services must be reusable – as a rule of thumb the more coarse-grained the Service, the better.

Service Loose Coupling

In principle, the coupling between the Service Consumer and the Service itself should be as loose as possible – the purpose being that the service’s logic and implementation should be allowed to evolve (as much as possible) without it impacting the applications that have already consumed the service contract. For Web Services, this effectively means that a web service’s logic should be allowed to change without there being an impact on the WSDL definition (and hence Service Consumers being required to import the WSDL once again and make corresponding changes).

Service Abstraction

Abstracting a service supports the loose coupling talked about previously. Although it depends upon the logic being implemented, ideally the consumer-facing messages should attempt to provide a simple, logical interface that is independent of the logic or technology working behind the scenes.

Siebel in a SOA Context #

So how can Siebel be best implemented within a SOA environment, bearing the principles above in mind? The first aspect that must be understood is the service granularity aspect.

Course-Grained Siebel Services

Traditionally what you will see on Siebel projects is that Services have not been designed to support a "unit of business functionality" - rather they have instead been designed to fulfil technical needs. Correspondingly, Services are often focussed on performing small units of work (e.g. addActivity), rather than larger pieces of functionality.

To support SOA properly requires a mindset change on the part of the developer. As an example, imagine the following business logic:

Whenever new customers are added to the system, an Account is created and a Contact – representing the Customer – is also added. The Address supplied by the Customer is added to the Account both as a Shipping Address and a Billing Adress, and an Activity is created for an Employee to perform a manual credit check on the customer.

Imagine if the new customers were being created by SOA calls into our Siebel system. Siebel could expose four Services – addAccount, addContact, addAddress and addActivity – that together could be orchestrated by an engine (e.g. Oracle SOA Suite) to perform the necessary logic.

But what happens if the orchestrator of the Services calls addAccount and then fails at addContact, given there is no ability to maintain a transaction across multiple Web Service calls into Siebel? Do we add compensating transactions, such as deleteAccount for the scenario above? Or do we hope that the administrators of the orchestration engine will manage to fix the issue and resume the process from the point of calling addContact? What if there is a Repeating Component Request in the system that takes all Accounts each month and emails the Primary Contact on that Account – will that fail if it runs when an Account exists but there is no Contact?

And what happens when these four services are being called? The calling application will often be sending the same information, or at least subsets of the same information, over the network for each service call. Additionally, each service call must reauthenticate itself, its XML payload must be parsed, and a response generated – which must in turn be handled appropriately by the orchestration engine.

An approach that adheres more to SOA principles would see a single service, addCustomer, created to perform all of the business logic above. Providing such a service that generates the Account, Customer, Addresses and Activity records from a single message means that:

1. The Orchestration Engine needs generate only one message
2. There is no data duplication in the message
3. The message is sent once across the network
4. The service can provide transactional integrity – all data succeeds or completely rolls back
5. A single response indicates whether the service failed or succeeded

Finally the service can be reused easily by any other system in the architecture.

Of course, there may well be a requirement to add new Activities on an ad-hoc basis, so a Service called addActivity may well be exposed too, in order to support other flows. However, Activities added during creation of a Customer would still be done through the add Customer Service rather than explicitly calling addActivity separately - for the compelling reasons above.

Note too that defining an addActivity service doesn’t mean a significant amount of duplication of Siebel Integration Objects needs to occur – this can be limited, as we will see in a later posting.

Abstracting and Loosely-Coupling Siebel Services

So far we’ve started to uncover a little more about the mindset required to enable Siebel for SOA. Next week’s post will continue to build on that, explaining more about the need to abstract and loosely-coupled any Web Services exposed by Siebel.