SOA Service Design Principles by example

First some context

I a project i had to couple a PeopleSoft system with Planon.
PeopleSoft is a HRM system used to store information about employees (in this case) and Planon is a facility management tool so that employees can order facilities.
When a employee is employed within the company, this employee has to added to the HRM system and this employee has to be authorised within the Planon system.
In the past this synchronization was done (as you see often) through a CSV file.
In the new architecture this kind of synchronization has to be done through a ESB (Enterprise Service Bus). In this case the Oracle Service Bus.

Service Naming

I wanted to add a new Service for this, so the first thing you do it to come up with a Service Name.
A couple of mistakes you often see is:
* The name is the same as the project name.
This is of course not done, because in a couple of months this name is forgotten and has nothing to with the functionality of the service at all (most of the time).
So the Discoverablity service design principle is also jeopardized.
* The name is the same as the name of the system (in this case Planon).
This goes against one of the overall goal of Service Oriented Architecture, namely vendor diversity.
In case you happen to change the system, the name of the service is useless but already Service Consumer may use the service.

The name I have chose is FacilityManagementAuthorisation.
The reason is that the functionality of this service is about authorising employees within the facility management system.
So this is the service naming design part, next is the Loose Coupling.

Loose Coupling

We use the Oracle Service Bus to decouple the service interface of the service from the actual implementation.
The OSB has the concepts of ProxyServices and BusinessServices.
If you ever worked with Planon and its webservices you may have noticed that these webservices are exactly that, without considering service oriented principles.
They are generated straight from the database tables and for each entity a webservice is generated.
For example you have a Person entity that contains information about the employees.
Before you can create Person entities you have to use the Session webservice to login.
Then change some Person attributes, Save, logout.
This is not the way you want to expose this as a Service. This is not the correct Abstraction. This way you would create a Service Contract - Implementation coupling.

So what should be done instead. This is where BPEL comes in! This is a technical orchestration language that is used to chain some backend calls to the Planon webservice.
In this case i created the following Service Interface:
* authoriseEmployee( Employee ), This operation authorises an Employee within the facility management system.
* removeEmployee( EmployeeNr ), This operation removes the employee from the facility management system.

I hope this small blog item gives you some insight in the choices you have to make when delivering SOA Services.
Comments and Additions are welcome!