blog.gov.jeIn the last blog we looked at some of the more technical aspects of systems integration and how the use of a Service Oriented Architecture (SOA) can assist in exposing and reusing data and services owned by government departments. We will continue our look at microservices and also discuss our approach and usage of integration principles and RESTful APIs for sharing information within the States of Jersey. This blog post contains many technical words and is as such written for those with a technical background.
Aren’t microservices just another term for SOA?
Rather than being a competing architecture, microservices build upon the principles of SOA and promote finer grained independent services that require a greater level of organisational and departmental maturity to implement. They promote a DevOps approach to automated service deployment with continuous integration and continuous delivery being realised as significant benefits.
The key advantage for the States of Jersey is being able to react to change at a much faster rate, thereby enabling a faster pace of service deployment whilst reducing costs.
Microservices are not without their technical challenges however. For example, IP addresses are dynamically allocated, and their discovery requires a different approach to traditional on-premise deployments when using the cloud. Typically server-side discovery and protocol translation will be implemented by an API gateway, and the Design Authority is defining a common approach to this.
Our approach
Following many discussions inside and outside of the States of Jersey, the Design Authority is the latest to confirm that a single coherent strategic solution for systems and application integration is required at SoJ. It forms one of the key components of the eGov programme. The requirement for departmental systems to share information both with each other and with the eGov foundational components (including customer portal, people directory and web payments) makes an integration platform an essential asset for the States of Jersey.
The Design Authority has been actively supporting the delivery of the integration platform, defining the functional and non-functional requirements required to procure an industry leading solution that will perform this task in the years to come.
At the core of our work are a set of integration principles and application integration principles which we will be sharing shortly. Examples of these principles include:
- Transport level negotiation e.g. between web protocols and messaging protocols
- Orchestration of services into a composite service
- Availability of services through redundancy and scalability
- Exposing services using standard web service APIs
- The use of well-defined enterprise integration patterns
Usage of integration principles and REST
The people directory is a component of eGov that will provide a single definitive source of common information relating to you that can be referenced by other systems across government departments. The system will provide the capability for you to see and update information about yourself. It will also hold the identifiers used by government (such as your social security number) that can be used to link records between systems.
The enablers to exposing the functionality to use this information are the Service Oriented Architecture and the RESTful APIs provided by the integration platform which the Design Authority is championing.
To this end the Design Authority has produced API guidelines to assist designers and developers in creating APIs including:
- Using web standards such as HTTP and URLs
- Versioning of APIs and avoiding breaking changes
- Defining HTTP response codes
- Formatting of dates and times
- Idempotent service design
Following these guidelines, versioned APIs can be developed to provide resources that can be called using standard HTTP verbs, issue standard response codes and return content that can be consumed in multiple formats including HTML and JSON.
Next Steps
A large part of how we develop this work next will focus on how we secure communications with the integration platform using open standards. This will cover authentication and authorisation, and will explore decisions around SAML vs OpenID Connect and OAuth2 vs JWT.