In this post we will identify the key tools or components that work together in an Enterprise Service Oriented Architecture solution.
In Enterprise SOA world there are key components work together to ensure SOA solution work as expected. Let’s identify them and have basic understanding of those components. And In coming posts deep it to those components.
As we can see in the above diagram we can list the key components as follows:
(Apache Tomcat, Oracle WebLogic, GlassFish, JBoss, IBM WebSphere, Jetty)
In developer world it’s a server which we deploy our enterprise applications or services. However if we further look in to it, then It’s a server program which consist of three tiers.
- Client Tier : It can be one or more applications APIs or browsers
- Middle Tier : This is consisted with Web server and a EJB server
- EIS (Enterprise Information System) Tier : Deployed applications, files and database
As mentioned above in the SOA world we deploy our web services, web applications in those servers. Some services may expose through API manager to public and some will use to develop the composite services which will make a proper SOA solution to the enterprise.
Message Broker or Messaging solutions
(RabbitMQ, ActiveMQ, SonicMQ, Kafka)
Message brokers comes in to play when we required reliable messaging communication between applications. The key concepts behind is Queues and Topics.
Queue: Point to Point model so, message will go to only one subscriber
Topic: With Publisher-Subscriber model each message which publish to the topic will be transmitted to all the subscribers who are registered to the topic
In addition some key features of Message Broker:
- Ability to retain (Store) the messages when the receiver is not available / or slow to consume them
- We can route messages one to many destinations
- Being able to decouple the message publisher and receiver
ESB – Enterprise Service Bus
(Oracle Service Bus, WSO2 ESB, Biztalk, Mule ESB, IBM Websphere ESB)
ESB is one of the main component in ESOA solutions. If someone ask you to give a one term to describe usage of ESB in SOA context, then it should be as a “Mediator”. Let’s find out why we call ESB as a mediator.
The core concept of ESB is to integrate different applications (Services) using an ESB as the middle man (mediator) to each of those applications to communicate with each other. This covers one of the core concept in SOA, with lose coupling of services and ability to interact with each other, Increases organizational agility by reducing time to market for new initiatives.
Key features of ESB are follows
- Message routing between services by reading the content of the messages
- Message transformation (ex: SOAP – REST and vise versa)
- Transport protocol negotiation between multiple formats (such as HTTP, JMS, JDBC)
- Allow to configure security and monitoring policies for services
(WSO2 Governance Registry, Oracle Registry)
The registry is an information catalog that is constantly updated with information about the different services in a service-oriented architecture project. It helps to govern the SOA solution by storing, cataloging and indexing metadata related to services, so it can be easily manage / governed using this component.
SOA registry support UDDI specification and it is the main component in SOA governance. However with emergence of API Manager, the Registry component is slowly moving out from the SOA component set.
(WSO2 API Manager, Apigee, Postman, Azure API Management)
In the current SOA component stack, API management component plays a major role. As we discovered in our earlier posts, that now most of all the applications expose services / APIs. API manager is also capable of covering some registry features as well.
If we define API Management: API management is the process of publishing, documenting and overseeing application programming interfaces (APIs) in a secure, scalable environment. The goal of API management is to allow an organization that publishes an API to monitor the interface’s lifecycle and make sure the needs of developers and applications using the API are being met.
- Automate and control connections between an API and the application which use it
- Monitor traffic of each exposed API
- Add security policies for APIs
- One repository to discover APIs in the Enterprise SOA boundary
BPEL Process Manager
(Oracle BPEL Process Manager, Apache ODE, ExpressBPEL, jBPM)
The key concept of SOA is construct services using other reusable services. To achieve that goal, we use BEPL Process Manager Component in SOA solutions. It holds a layer to orchestrate and combine multiple services to generate the task services which covers the business processes of the SOA domain. In BPEL manager we use BPEL (Business Process Execution Language) to define those complex orchestration processes. We would say BPEL Manager is the core component in Enterprise SOA solution.
- It was initially based on XML schema, SOAP and WSDL. However now it support REST and JSON
- Send and receive messages asynchronously from remote services
- Manipulate XML, JSON data using XSTL
- Manage events and exceptions in the process flow
- Ability to design parallel flows
- Compensate – Undo portion of processes when exception occur during the flow
- Version control
BAM – Business Activity Monitoring
(Oracle BAM, WSO2 BAM)
BAM describes the processes and technologies that enhance situation awareness and enable analysis of critical business performance indicators based on real-time data. BAM is used to improve the speed and effectiveness of business operations by keeping track of what is happening and making issues visible quickly.
With all the components working together in Enterprise SOA solution, we can ensure a complete SOA solution running in our enterprise.
- SOA Suite components by Antony Reynolds, Matt Wright