SOA infrastructure

Establishing an SOA infrastructure can be very difficult, time-consuming and cumbersome. If you go for the “all at once” approach, you are very likely to end up with a lot of functionality you will never need and chances are that you will only have a part of the functionality you will need over time.
As in the case of the overall EA model a good approach would be to start with an initial infrastructure that has just enough functionality to support your immediate needs but is also flexible and scalable enough to make extensions easy as the need arises – plan for the future; build for today.

We need an ESB!

That is often the conclusion of an SOA infrastructure analysis. The problem is that the definition of an ESB (Enterprise Service Bus) varies depending on whom you ask.
Based on our experience in developing wall-to-wall SOA’s we have made the following list of functional and non-functional requirements for an ESB that are worth considering from a start. Maybe you do not need all of them to begin with – or maybe you will never need them all.

• Publications (functional)
• Subscriptions (functional)
• Queries (functional)
• Authentication (non functional)
• Authorization (non functional)

Publications / subscriptions

Publications and subscriptions are dependent on each other. It makes no sense to have publications without subscriptions and vice versa.
The publish/subscribe functionality covers the need for an asynchronous message-based way of communication. One very useful – often necessary – application for this is handling of business events.
The concept is just like magazine subscriptions. A service sends a message (publish) and one or more services receive that particular message (subscribe). Somewhere in between a subscribers list exists. That list is used to find out which services need to receive which messages.

Queries

Queries are a name for a classic request/response pattern. A service sends a request and receives a response. Queries can be synchronous or asynchronous on a technical level but also on a conceptual level. Thus what makes a query different from publishing a message is that the sender expects a response when sending a query. The response can arrive immediately or after several minutes, hours and even days.

Authentication

Authentication is a basic requirement in any architecture, unless you want the whole world to be able to see all your data and perform any task.
Authentication is often dealt with on the technical platform level – e.g. Windows logon. For many companies this approach works well most of the time. If you only allow internal access to your services, that may be adequate to fulfil your needs.
As soon as external partners need access to your services, authentication becomes non-trivial. You cannot expect external partners to log on to your internal network each time they need to communicate – and you probably do not want them to. It is therefore a good idea to think about how you want authentication to happen in you new SOA – even if you are not implementing it to begin with.

Authorization

Is everybody at the company allowed to view all data? Is everybody at the company allowed to perform all tasks? If not, you need authorization. Authorization – the ability to restrict access to certain data or certain functionality – sooner or later becomes a vital part in any Service Oriented Architecture... In any Enterprise Architecture actually. 
To begin with it is sometimes enough to use the basic overall authorization mechanism provided by the technical platform (e.g. restricting access to certain windows accounts), but along the way the need for a more flexible mechanism arises. You may want to allow all employees in the company to see details about the other employees – except salary details.
These restrictions can be built into the various applications used throughout the company. That is how it is often done today. Another option is to let the SOA infrastructure handle the authorization. In the example above the SOA infrastructure will allow any employee to request data about her colleagues, but for most employees the salary details will be removed.

On to Project model.