This week I had to write a Software Architecture Document for a new project that I am assigned to. The document presents the high level architecture that will be used for the solution created in this project. The high level architecture identifies the services that are needed. These will be described in more detail (interface, messages, and implementation) at a later stage in a separate document.

When reading through the functional requirements I noticed the large number of reference tables that were described in the specs. All of this reference data is needed for (at least one of) the services and of course it has to be possible to maintain these reference data. This made me think about the best way to design this reference data within the high level architecture. After a talk with my colleague Gerke, I decided to do it in the following way:

Al reference data that is relevant for only one service will be maintained by the service itself. All reference data that is relevant for more that one service will be logically grouped in one service. For example, in the requirements for this project; country, region and sub-region reference data is described. For this, a ‘geography’ service (it’s only a name) is identified that maintains the country, region and sub-region reference data.

For this kind of reference data services, I identified two different interfaces types, one ‘query’ interface and an ‘update’ interface. Most of the service consumers of a reference data service are only interested in the query interface. The query interface is the one that will be used by a business information service to access the reference data. The ‘update’ interface will implement the so called CRUD service actions. This interface is only relevant for the one responsible for maintaining the reference data and therefore a little less important.

The same applies to reference data that is relevant to only one service (and therefore is maintained as part of the service itself). For this situation also an update interface is defined that implements the CRUD service actions for the reference data part of the service.

When implementing the reference data services, I think it is best to implement the query and the update interface in a separate ‘asmx’ file (when using .NET web services). This gives a nice and clean interface that is easy to consume for the service consumers providing them the service actions that they are interested in only. It also simplifies the authorization part of the two different types of service actions provided by the two interfaces.

During a recent project it became very clear to me that standardization (naming conventions, coding guidelines, etc.) is also a very imported issue within a service oriented environment. Probably because of the service orientation hype, everybody is too busy with all the service oriented related issues within the project that make them forget very basic things (like coding standards and guidelines).

Because of the autonomous nature of a service it is very likely that they are developed by different people (or teams). From what I saw in practise, communication between the several build teams of the different services within a solution is very limited, simply because of the fact that the interfaces are well defined (if the designer understands it’s job).  In case there is communication between the different service teams, it is mostly about the service interface and messages definition, rather than internal implementation (coding) issues. In case of a lack of standards, guidelines, etc., the end result of this is a solution (application) that exists out several services all implemented in a very different way, using different naming conventions, exceptions handling strategies, etc.

Of course missing standards and guidelines can cause the same issues (poor quality of code) in an “old fashioned” n-tier application but, because of the more tightly integration between the different parts or components in the application, developers tend to communicate more and they are more often (forced to) have a look at each other code. This will result in at least the same “standards and coding techniques” used within the whole application.