Middleware applications are normally build in a structured way – according to some architecture. However, often this structure can’t be recognized in the implementation. This article describes some simple measures that can be taken to improve on this point. The article does not intend to be complete, but it should inspire to bring structure to middleware environments.
Who benefits
Adding structure to a middleware implementation will be of benefit to practically everyone who is involved. Some examples of tasks that will be easier to do:
- impact analysis for changes
- selection of artefacts for deployments
- analysis of runtime exceptions
- learning curve for newbies
Application Structure
An obvious candidate for ‘Application Structure’ is of course the ‘application architecture’, where the system is described in functional blocks. These blocks should be clearly identifiable in the application implementation.
Other candidates for adding structure are ‘company organization’ and ‘business processes’.
Example
The remainder of this article takes (part of) the AMIS organization as an example:
- Marketing: the marketing department
- Consulting: the consulting teams: UX, SOABPM, Platform and Architecture
- Finance: the financial department
- Secretariat: the secretariat that also covers HR
In this organization, we will implement BPM processes, e.g. ‘EmployeeOnboarding’ – a process that is owned by the Secretariat. This EmployeeOnboarding process uses two services:
- Employee service – owned by the secretariat and that supplies information about employees
- Salary service – owned by the finance department and that supplies financial information about employees
The application name for implementation of the BPM processes and services is ‘AmisProcesses’ – for lack of real inspiration
Let’s assume that we’re building a middleware application for the services/processes of these departments.
Structure – but where?
You application structure should be visible in as many places as possible Think of:
- Software archive (e.g. svn)
- Namespace composition
- Service endpoints
- SOA Suite deployment topology
- MDS structure
- etc
Software archive
The software archive will be structured in the following way:
svn:amis/amisprocesses/consulting/architecture
/platform
/soabpm
/ux
/finance/Salary/branches
/tags/V1.0
V1.1
V2.0
/trunk/soa/Salary/1
/2
/marketing
/secretariat/Employee/branches/
/tags
/trunk/soa/Employee/1
/EmployeeOnboarding/branches
/tags
/trunk//bpm/EmployeeOnboarding/1
Note that the structure reflects the organization structure, and that the branches/tags/trunk split is made at the service level, i.e. the level of the deployable artefact.
Namespaces
Namespaces are structured in a similar manner, including an indication of what the namespace is intended for. Examples below:
- For services:
xmlns:salsvc=”http://nl.amis.service/amisprocesses/amis/finance/salary/2” - For messages:
xmlns:salmsg=”http://nl.amis.message/amisprocesses/amis/finance/salary/2” - For processes:
xmlns:empprc=”http://nl.amis.process/amisprocesses/amis/secretariat/employeeonboarding/1”
Service endpoints
Probably the most common situation is that where a loadbalancer is used in a high available clustered set-up. Also the endpoints that are used for accessing the services can follow the same structure:
http://loadbalancer.amis.nl/amisprocesses/amis/finance
Here, the dns will get the entry for loadbalancer.amis.nl.
However, often loadbalancer routing uses only the first part of the URL path (above: ‘amisprocesses’). In such cases, the below URL is a better alternative:
http://loadbalancer.amis.nl/finance
Application deployment topology
The application deployment topology is about what to deploy where. The only structuring mechanism for BPM/SOA Suite deployments is the ‘partition’. That mechanism is not recursive, i.e. it is not possible to have partitions under a partition. So, in our example we will have the following partitions:
Partition ‘finance’:
- soa composite Salary_1
- soa composite Salary_2
Partition ‘secretariat’:
- soa composite Employee_1
- bpm composite (process) EmployeeOnboarding_1
MDS
The MDS also has – again – the same structure:
oramds:/amisprocesses/consulting/architecture
/platform
/soabpm
/ux
/finance/Salary/1
/2
/marketing
/secretariat/Employee/1
/EmployeeOnboarding/1
By now, this article should have become quite boring. Which is exactly the goal of adding structure: simple = boring = predictable = good.
Java packages
Similar to the middleware artefacts, the structure can be extended to the java artefacts. If an XSL extension function has to be built for the Employee service, the java package name would be
package nl.amis.secretariat.employee
Note that in java programming environments, structuring of sources into meaningful packages is ‘natural habit’ of programmers.
Anti-Patterns
For most of the above items, the anti-patterns are obvious.
Consider e.g. an SVN structure:
svnroot/branches
/tags
/trunk/osb
/soa/simpleservice
/compositeservice
/bpm
… where the artefacts are grouped on their technical aspects.
Consider a namespace like:
http://xmlns.oracle.com/bpmn/bpmnProcess/ComplaintCase
… which doesn’t give much clues as to who owns it and what it is used for.
And perhaps the most annoying one is a production system with all composites deployed in the default partition. Perhaps it would be a good idea to always remove the default partition for a non-development installation?
Structure is everything!
