Building a Modern SOA Architecture Using a Service Bus

The assumptions behind SOA architecture (service-oriented architecture) were, and still definitely are, valid and sound. Unfortunately, the issue lies in how they are implemented, which is what causes projects to fail and frustration among managers – especially those responsible for the budget. However, the idea of service architecture can provide a successful foundation for the philosophy behind system and application integration, and a modern service bus – as long as it is a solution that provides agility and flexibility – has proven to be effective many a time.

Introduction – a few words about service architecture

Service Oriented Architecture (SOA) has been found to be both a modern and flexible approach to building application interconnections in enterprises, yet very expensive and time consuming to implement. Unfulfilled expectations from numerous project implementations, aimed at building SOA architecture, caused a lot of frustration and disappointment. Many companies rejected the service bus as an integration solution after such an attempt, or even several attempts.

The solution offered by Unity Group to clients in need of integrating systems is a different way of approaching SOA and service buses. Instead of viewing ESBs as expensive “boxes” bought by an enterprise, it’s worth considering the choice of solution in terms of the principles and patterns of correct integration, especially from the perspective of IT architecture. In other words, when considering the integration of IT systems and the selection of appropriate solutions and partners, it is important to keep SOA in mind, as it is an important milestone in building architecture and implementing integration patterns.

SOA premises are still valid

The key premise of SOA architecture has been to design and build enterprise IT architecture based on services rather than entire applications. The key in such architecture is building components (services), i.e. small, separable portions of software, which perform specific functions and, importantly, are reusable for other applications and systems. In such a service-oriented model, the developer’s role is mainly to create new applications by combining sets of services, rather than building entire applications from scratch. By design and practice, this eliminates duplicated functionalities in the architecture’s applications, thus reducing the time required for implementation. A good example can be a banking application (made in SOA) used in the lending process. It would consist of, among other things, credit status vetting services, services calculating interest and services related to customer data.

According to the theory, SOA should break down the massive “silos” of business logic and data, which are usually collected in separate applications. These sets of logic and data can exist in local software or the cloud, as well as SaaS applications, etc. In its model form, SOA should enable interoperability between all elements of business logic and data sources through integration, which in turn results in faster and easier automation of business processes.

This service-oriented approach to architecture has many advantages: 

• Thanks to the greater flexibility of IT systems and business process software built this way, companies can respond to changes much faster and more efficiently. 
• It becomes easier, to introduce innovations new products to remain competitive and build market advantage. 
• By implementing SOA, enterprises can reduce redundancy and complexity often found in legacy systems, optimize IT costs associated with maintenance and upgrades, and increase the productivity of IT teams by making software design more intuitive. 

It can be confidently said that SOA ideas are not bad. Rather, it is simply that numerous attempts at implementation have failed to deliver on this promise.

A proposed approach to SOA – the service bus

A possible cause behind SOA implementation failures was that they were initiated top-down. They were launched as a single, massive initiative which covered the entire organization. This approach would often be driven by the specific nature of solution providers and manufacturers (big brands) and required expensive, multi-annual, multi-stage implementations. Often, such implementations involved a crowd of expensive consultants. They were extremely labor- and time-consuming, and the Client’s project team often had to learn and use the implemented product to redesign all existing systems and design new applications according to SOA principles. Developers sometimes had to replace their known tools, processes and skills, retraining to accommodate the new reality. This has had a negative impact on the ability to quickly introduce innovations and keep up with the pace of changes.

Another way to approach the problems that SOA addresses is using a lightweight, open source service bus (ESB) such as Mule ESB or WSO2. Such a bus can support the creation and orchestration of services without the need for extensive integration software suites (often with very expensive licensing) or infrastructure components, eliminating the high initial cost of implementing SOA. Rather than having a prolonged period of analysis and implementation, ESB can be implemented and put to use in a very short time. This allows developers to create usable interfaces with API interfaces, gradually building and developing a new architecture based on SOA principles. An example of such an architecture is the API-Led Connectivity model.

Service buses enables enterprises to adopt SOA incrementally, without the need to revolutionize their architecture. As the solutions recommended by Unity Group are built in accordance with open source standards, they offer great flexibility in terms of integrating a broad range of systems, cloud services and applications. Unlike early SOA implementation initiatives, ESBs such as Mule or WSO2 do not introduce vendor lock. Neither do they impose a specific integration pattern (which is often convenient for the vendor) or target architecture. In many ways, a service bus delivers on the premises of SOA.

Benefits of using a service bus

A service bus is perfect for integration projects and can be used for interconnecting systems efficiently and quickly. However, there are many other components creating modern architecture for today’s organizations. For example, companies that want their integrations to be based on API will need to find a way to design, build, manage and secure them. Also, mechanisms are needed to deliver continuous integration/ continuous deployment (CI/CD).

Mule ESB and WSO2 ESB offer not only reliable interconnectivity between systems, but also full API lifecycle management on a single platform. These platforms have been built for the needs of DevOps and agile development, with a view to using popular and established tools for continuous integration and continuous deployment (CI/CD), such as SCM, Maven, Junit and Jenkins. The aspects of monitoring are also critical in maintaining the service bus, thus ensuring business continuity. Here, the tools embedded and provided with the service bus, by the respective manufacturer, often prove helpful. There is, however, an option (often recommended by Unity Group) to use additional third party solutions, such as ELK, as they’re often are already known and used by our clients.

Such a unified integration platform, using SOA principles and service bus functionality, implemented by a trusted and competent partner, allows you to create a service-oriented IT architecture. It ensures the flexibility and reliability to help you remain competitive in today’s environment. 

To learn more about SOA architecture, API-led concept and API lifecycle management tools, please, take a look at our offer and contact us.