I read an interesting article the other day that appeared in a previous share we did on SOA at the data layer and that SOA is not a swear word (I couldn’t agree more). To be honest, I hadn’t come across it until then. But it sparked something I’ve been feeling for a long time: SOA is awesome… when it’s done properly! So I thought I would share a very handy technique you can use in Warewolf to get the most out of your Service Oriented Architecture (SOA).
How do you build SOA for the long term in an agile environment?
One of the fundamentals that we recommend you implement (not just because it’s easy in Warewolf) is what we call the Data Reference Pattern. It sounds fancy, and it is.
Taking a step back, one of the big downfalls of SOA in an agile environment is where to store your working variables or global constants. Without a pattern, the rules of SOA are quickly broken and one ends up with lots of hard coded values throughout your application. In true agile fashion, the results of the current sprint take priority and some long term architecture principles get “broken”. This in turn leads to lots of swearing and SOA takes the fall down the line. Thankfully there is an easy solution.
The Warewolf Data Reference Pattern for SOA based systems.
This pattern allows you to store your working variables centrally across many applications. Enforcing this pattern keeps your services decoupled and gives you a central place to manage application or enterprise information. You can use a project level Data Reference for each project or solution you are working in and another company-wide or global Data Reference for more generic information.
The Data Reference Pattern in Warewolf is implemented as a workflow service that has an assign detailing all the pieces of information that we want central access to. It would look something like this:
All variables are marked as Output in the Variable List window:
This workflow is then called as and when the information is required, typically at an orchestration level.
Avoid common mistakes
Resist the temptation to place this workflow inside your micro services. Doing so breaks the SOA nature of what you are creating and will restrict the service to only act on central data.
Keep your Reference Data as scalars (normal variables) and not recordsets. If you create the data as a recordset, you will need to map the whole recordset out, even if you only need 1 record. However, if your data is in scalar format, you can always map it out into a recordset when implementing it.
Example
Call the workflow service, map out the data you want, and pass it into your service, like this:
In the above example, we are using DevelopmentRefData service to get our central data. We are then only mapping out the data we are interested in – [[GitSite]] – and leaving the rest as we do not need it. This information is being passed into the service Git Pull Repository along with the [[GitRepo]] which is specific to the orchestration service and was passed in at that level.
The ancillary benefit of this is that the service is available to any other application as well.
It’s that simple to keep your SOA a SOA.
Key Benefits Summary
- Services are properly decoupled.
- Services can be used correctly across multiple systems.
- Services remain atomic.
- Global constants are easy to administer.
- Global constants are available to other applications.
- Supports scaling systems.
- Supports multiple levels of constants to match your architecture.
- Simple to implement and use.
Pingback: Creating a Microservice architecture using Warewolf ESB