Microservices Architecture Implementation: Tech / Tool Stack Map

There are different tool stacks like nodeJs, Spring cloud which we can use to build microservice solutions. Since I’m having a Java background, in this post we will look how the spring cloud solution will help us to develop comprehensive microservices solution. This tool set is applied in my working environment and it’s running smoothly in Production setup.

Due to excellent tool support and easy integration capabilities Spring cloud with spring boot framework makes developer life stress-free.

Below diagram illustrates the full component stack. Will give you a very high level usage of each component in this post. Later we can dig deep in to each component.

Microservices architecture solutions implementation using Java framework: Spring Boot / Spring Cloud Components

  • RAML / Swagger / Thrift : Used to design Contract-First microservices
  • Zuul : Edge Server, Reverse proxy server. API gateway or gate keeper for external parties
  • Eureka : Act as Service registry & discovery component
  • Ribbon : Load balancer
  • Spring Cloud Config : Centralized configuration server for the MSA solution
  • OAuth2 / JWT : Security mechanisms which can be integrated with microservices
  • Hystrix : Monitoring dashboard for the services and fault tolerance configuration component
  • Redis / memchached : Distributed caching mechanisms
  • AMQP / MQTT / STOMP : Messaging protocols for asynchronous communication
  • REST / Thrift : Messaging mechanisms for synchronous communications
  • Docker / OpenStack : Deployment architectures for our microservices
  • Tomcat / Jetty : In-build servlet containers in Spring boot

 

With all the above tools and components we can build a production ready microservice solution in rapid speed. In the coming posts let’s try to grab more knowledge in those areas.

 

References

Read More

Introduction to Enterprise messaging (Basics) with Message Broker

With some industrial experience on Message broker related SOA integrations, thought of discussing about Enterprise messaging. Let’s start with the basics and later in the coming post let’s discuss how we can have a high available messaging architecture.

Messaging

One mechanism which distributed applications can communicate is via message passing. Before we move ahead let’s check what “message” means.  A message is a structured piece of information sent from one agent to another over a communication channel. Message will have an identifier within it and it will tell the receiver the purpose or type of the message.  We can use different protocols and network standards such as HTTP, SSL, TCP/IP to do message parsing between applications.  However when we talked about enterprise messaging with message brokers, we talk about transmission control protocol. Another important fundamental concept we should know in messaging is the message handling methods. Namely Asynchronous and Synchronous. So let’s discuss it.

 

Asynchronous vs. Synchronous message handling

One critical thing we need to consider when planning message parsing or processing is to know whether it needs to be Asynchronous or not. First let’s see the difference between the two types.

  • Synchronous Messages:

    Synchronous messaging involves a client that waits for the server to respond to a message. Messages are able to flow in both directions, to and from. Essentially it means that synchronous messaging is a two way communication. i.e. Sender sends a message to receiver and receiver receives this message and gives reply to the sender. Sender will not send another message until it gets a reply from receiver.

 

  • Asynchronous Messages: Asynchronous messaging involves a client that does not wait for a message from the server. An event is used to trigger a message from a server. So even if the client is down, the messaging will complete successfully. Asynchronous Messaging means that, it is a one way communication and the flow of communication is one way only.

Depending on your business process need you can choose one of the above methods in your communication channel. Now let’s discuss about the message broker which handles all these message flows between different applications.

 

Message Broker

A message broker is a middleware program that translates messages from the formal messaging protocol of the publisher to the formal messaging protocol of the receiver. Message broker decouples the publisher and consumer systems. The beauty of the message broker is that it can receive messages from a publisher and it can transmit it to multiple subscribers. In addition there are key advantages on using a message broker in the middle of a message communication. They are as follows:

  • Ability to store messages when the consumer is not available to consume the messages
  • Guarantee message delivery between two parties
  • Act as a load controller in the middle of an application to ensure the consumer is not overloaded with requests. All the requests will come to the message broker and it will store them until consumer, reads them one by one with the highest rate it can consume.

Now we know what is the message broker and the importance of it. Next we will look in to the two main subscription models in messaging.

 

Queues and Topics

As the message handling model, message subscription model also need to be selected based on the business process requirement.  Let’s see what we need to consider when selecting the model.

Queue Topic
Point-to-point model. Publish/subscribe model.
Only one consumer gets the message. Multiple clients subscribe to the message.
Messages have to be delivered in the order sent. There is no guarantee messages have to be delivered in the order sent.
A JMS queue only guarantees that each message is processed only once. There is no guarantees that each message is processed only once. As this can be sensed from the model.
The Queue knows who the consumer or the JMS client is. The destination is known. The Topic, have multiple subscribers and there is a chance that the topic does not know all the subscribers. The destination is unknown.
The JMS client (the consumer) does not have to be active or connected to the queue all the time to receive or read the message. The subscriber / JMS client needs to the active when the messages are produced by the producer, unless the subscription was a durable subscription.
Every message successfully processed is acknowledged by the consumer. Every message successfully processed is not acknowledged by the consumer/subscriber.

 

Next let’s investigate on how message broker can exist in enterprise SOA.

 

Messaging Topologies

  • Internal Broker:

    J2EE application server contain message broker (embedded with JMS enabled application server webshere / weblogic / jboss ) and external applications call the message broker. Reliability and performance concern since its inbuild in the application server additional overhead to server resources. Messaging required threads and CPU for processing. Application server down then message broker is also down. Worthy when our queues not exposed to external applications.

 

  • External Broker:

    Fully fledge message broker solution. Message broker is an external server. Activemq, Sonicmq, Mulemq are some examples for those external brokers. From those we can achieve clustering, fault tolerance, scalability

 

  • Embedded Broker:

    application with message broker solution in build with it. Source code of your application start the message broker. Message broker part of the applications. It will be a truly localized message broker for an application.

 

Now we have discussed all the aspects related to message broker and enterprise messaging. In the next post we will discuss on how we can setup an External Broker Architecture with high availability and fault tolerance.

 

References

  • http://peoplesofttutorial.com/difference-between-synchronous-and-asynchronous-messaging/
  • Java Distributed Computing by Jim Farley
  • ENTERPRISE MESSAGING WITH JMS by Mark Richards
  • http://www.ebizq.net/topics/eai/features/1590.html
  • JD Edwards EnterpriseOne Transaction Server Reference Guide

Read More

How Microservices fitting in Enterprise SOA Solutions

In previous posts we discussed on different topics of Service Oriented Architecture and Microservices. In this post we will discuss how Microservices moving in to the traditional SOA solutions.

In software engineering, SDLC (System Development Life Cycle) is a well know process. Similarly when we want to develop SOA solutions, there is similar process which is illustrated in the below diagram.

In the Service Oriented Analysis and Design stages, microservices comes in to the picture.  Before we proceed let’s get a quick introduction to microservices. In SOA world microservice represent a specific performance / reliability requirement (business process) in a SOA solution. Its holds a distinct implementation environment optimized to support special processing demands that required for performance and reliability needs. Microservice is an independent service, however when a microservice needs to access other resources (services), those resources can either be replicated or redundantly implemented so that they remain part of the microservice’s local processing scope. Therefore, when it is decided that a microservice needs to compose another service, the composed service may be redundantly implemented and deployed together with the microservice.

 

Service Analysis and Modeling Process

Now let’s check how microservices are produced in a SOA solution on a given Business Process.

 

Step 1 | Analysis of the Business Process:

Main goal of this step is to decompose the business process to smaller processors. To achieve this we can follow the below steps

  • Identify main processors in the business process
  • Breakdown each main process in to small processes
  • Draw the detail business process flow diagram
  • Identify small processes which cannot be automated or should not be automated. Those processes should only handle through a manual process. So remove them from the list of process which are candidates for service implementation

 

Step 2 | Define Entity Services:

From the list of processes which are candidates’ service implementation, find out reusable agnostic services candidates and its capabilities.  Those services can be categorized as entity services.

 

Step 3 | Define Task Services:

These are the services which has process specific logic (non-agnostic). After identifying the entity services, the remaining can be categorized under task service. Normally we can find business rules, conditional logic which is specific to a process in this kind of services.

 

Step 4 | Apply Service Orientation:

Revisit the services which we have categorized and try to apply service orientation principles on them. Service loose coupling, Service abstraction and Service autonomy to those services.

 

Step 5 | Identify Service Composition Candidates:

In this step, we will look at the entity and task services that we captured during earlier stages and check whether those are candidates for service compositions.

 

Step 6 | Analyze the processing requirements:

For each process / sub process we need to follow the following steps to identify special requirements

  • What are the processing logic required in each service
  • Did we identified them earlier or do we need to redevelop them
  • What are the external resources we need to access via our services (DB, Message Brokers, Legacy systems)
  • Any logic critical for performance and reliability
    • This is the point where need of microservices comes in to picture in SOA solution
    • By producing performance and reliability critical services as microservices, we can ensure other services won’t have any impact from those performance critical services. Since those are run independently

 

Step 7 | Define Utility Services:

From the agnostic processing logic which we identified earlier, check if there are any reusable utility services. For example logging services and notification services.

 

Step 8 | Define microservices candidates:

Revisit the non-agnostic process logic which we identified earlier and determine any of the logic can be represent as microservices. Ideal candidate for a microservice would be

  • Volatile requirement
  • Performance requirement
  • Runtime reliability and failover requirement
  • Service visioning and deployment requirement

 

Step 9 | Apply service orientation:

As we did in the step four, repeat the same process to utility and microservices which we identified earlier

 

Step 10 | Revisit the service composition candidates:

Check whether we can use the microservices and utility services for other service requirements

 

That’s pretty much it, on the process of analysis and design stage of services in a SOA solution. So we can clearly see where the microservices coming in to play in the SOA solution development process.

 

References

Read More

Developing SOAP web service with Spring Boot and Spring-WS

In the current developer world, we speak very less about SOAP web services. This is due to the REST web services dominance in SOA world. However the need for SOAP services will never be zero.

In this document we will focus on how we can develop SOAP web services using popular Spring Boot framework and Spring-WS. When I searched the internet for tutorials I found this useful tutorial, which explain on how to develop SOAP services. There were some missing items in the tutorial and thought of adding them to have a complete steps tutorial.

Spring-WS mainly focus on document driven web services. Hence Spring-WS facilitate the contract-first SOAP web services development. Let’s see how we can develop a simple contract first web service using the following tool set.

  • Spring Boot 1.5
  • Spring-WS 2.4
  • Maven 3
  • Tomcat application server 7
  • Eclipse IDE

Final out put product would be a deployable war file which exposes a SOAP web service to its clients.

Let’s start the development

Initial Project Setup

  1. Create a maven project in eclipse

File –> New –> Other –> Maven Project –> Select “maven-archetype-webapp” –> Provide the Group Id and Artifact Id and save

  1. Create Build Path

Right click on the project –> Build Path –> Configure Build Path –> Under the “Source” tab remove the unsolved items and add the following folder to build path

  • src/main/java
  • src/test/java
  • src/test/resources

 

Creating the POM

  1. By default we have a POM file under the project structure to insert the dependencies.
  • We are using Spring Boot in our project and for testing we are using the embedded Apache Tomcat server
  • Parent POM of spring boot is used to facilitate the spring dependencies.
<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>1.5.1.RELEASE</version>
</parent>
  • To facilitate the Spring-WS dependencies following dependency element included in the POM
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web-services</artifactId>
</dependency>
  • To include the testing support on Spring Boot application following dependency for included in the POM
<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-test</artifactId>
  <scope>test</scope>
</dependency>
  • To create a runnable jar, which can be run on the built it Tomcat: we will add the following plugin in the build tag
<build>
        <plugins>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
            </plugin>
            <plugin>
                <groupId>org.jvnet.jaxb2.maven2</groupId>
                <artifactId>maven-jaxb2-plugin</artifactId>
                <version>${maven-jaxb2-plugin.version}</version>
                <executions>
                    <execution>
                        <goals>
                            <goal>generate</goal>
                        </goals>
                    </execution>
                </executions>
                <configuration>
                    <schemaDirectory>                      ${project.basedir}/src/main/resources/wsdl</schemaDirectory>
                    <schemaIncludes>
                        <include>*.wsdl</include>
                    </schemaIncludes>
                </configuration>
            </plugin>
        </plugins>
</build>

 

  • Full POM files as follows
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>com.codenotfound</groupId>
    <artifactId>spring-ws-helloworld-example</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <packaging>jar</packaging>

    <name>spring-ws-helloworld-example</name>
    <description>Spring WS - SOAP Web Service Consumer &amp; Provider WSDL Example</description>
    <url>https://www.codenotfound.com/2016/10/spring-ws-soap-web-service-consumer-provider-wsdl-example.html</url>

    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>1.5.1.RELEASE</version>
    </parent>

    <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
        <java.version>1.8</java.version>

        <maven-jaxb2-plugin.version>0.13.1</maven-jaxb2-plugin.version>
    </properties>

    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web-services</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
            </plugin>
            <plugin>
                <groupId>org.jvnet.jaxb2.maven2</groupId>
                <artifactId>maven-jaxb2-plugin</artifactId>
                <version>${maven-jaxb2-plugin.version}</version>
                <executions>
                    <execution>
                        <goals>
                            <goal>generate</goal>
                        </goals>
                    </execution>
                </executions>
                <configuration>
                    <schemaDirectory>${project.basedir}/src/main/resources/wsdl</schemaDirectory>
                    <schemaIncludes>
                        <include>*.wsdl</include>
                    </schemaIncludes>
                </configuration>
            </plugin>
        </plugins>
    </build>

</project>
  • Now to ensure all works accordingly, let’s build the application. Locate the directory location where your POM file reside and run the below command
mvn install

 

Creating the Contract (WSDL)

  1. Spring web services supports contract first approach only in web services development. So let’s start the with the WSDL (contract)
  • In a WSDL there are key elements
    • <types>
    • <message>
    • <portType>
    • <binding>
  • In our contract we have the following
    • XSD Schema which has two elements
      • “Person” : Request Object
      • “Greeting” : Response Object
    • Message elements
      • “SayHelloInput” : mapping of the XSD object to the message element
      • “SayHelloOutput” : mapping of the XSD object to the message element
    • PortType element
      • Binding the input/output messages to SOAP function “sayHello”
    • Binding element
      • Define the SOAP action and configuring the SOAP body for input/output
    • Service element
      • Defines the SOAP function and the message formats for the service which we are exposing
    • Detail WSDL as follows
<?xml version="1.0"?>
<wsdl:definitions name="HelloWorld"
    targetNamespace="http://codenotfound.com/services/helloworld"
    xmlns:tns="http://codenotfound.com/services/helloworld" xmlns:types="http://codenotfound.com/types/helloworld"
    xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">

    <wsdl:types>
        <xsd:schema targetNamespace="http://codenotfound.com/types/helloworld"
            xmlns:xsd="http://www.w3.org/2001/XMLSchema"
            elementFormDefault="qualified" attributeFormDefault="unqualified"
            version="1.0">

            <xsd:element name="person">
                <xsd:complexType>
                    <xsd:sequence>
                        <xsd:element name="firstName" type="xsd:string" />
                        <xsd:element name="lastName" type="xsd:string" />
                    </xsd:sequence>
                </xsd:complexType>
            </xsd:element>

            <xsd:element name="greeting">
                <xsd:complexType>
                    <xsd:sequence>
                        <xsd:element name="greeting" type="xsd:string" />
                    </xsd:sequence>
                </xsd:complexType>
            </xsd:element>
        </xsd:schema>
    </wsdl:types>

    <wsdl:message name="SayHelloInput">
        <wsdl:part name="person" element="types:person" />
    </wsdl:message>

    <wsdl:message name="SayHelloOutput">
        <wsdl:part name="greeting" element="types:greeting" />
    </wsdl:message>

    <wsdl:portType name="HelloWorld_PortType">
        <wsdl:operation name="sayHello">
            <wsdl:input message="tns:SayHelloInput" />
            <wsdl:output message="tns:SayHelloOutput" />
        </wsdl:operation>
    </wsdl:portType>

    <wsdl:binding name="HelloWorld_SoapBinding" type="tns:HelloWorld_PortType">
        <soap:binding style="document"
            transport="http://schemas.xmlsoap.org/soap/http" />
        <wsdl:operation name="sayHello">
            <soap:operation
                soapAction="http://codenotfound.com/services/helloworld/sayHello" />
            <wsdl:input>
                <soap:body use="literal" />
            </wsdl:input>
            <wsdl:output>
                <soap:body use="literal" />
            </wsdl:output>
        </wsdl:operation>
    </wsdl:binding>

    <wsdl:service name="HelloWorld_Service">
        <wsdl:documentation>Hello World service</wsdl:documentation>
        <wsdl:port name="HelloWorld_Port" binding="tns:HelloWorld_SoapBinding">
            <soap:address
                location="http://localhost:9090/codenotfound/ws/helloworld" />
        </wsdl:port>
    </wsdl:service>

</wsdl:definitions>

 

Java Code Implementation

  1. Now our contract is ready. And we have some element defined which we use in SOAP request / response objects. Using JAXB we can easily generate the Java classes associated with those elements
  • Create a folder under “/src/main/resources/” called “wsdl” and copy the created wsdl file to the new directory created
  • In the POM under <plugins> element we have configured a “maven-jaxb2-plugin” to facilitate this class creation
  • The generated java classes will be located in the “target” directory
  • To generate the those classes run the following command
mvn generate-sources

 

  1. The generated java classes will be in the “target” folder and we need add the folder to build path
  • Locate the following directory “/target/generated-sources/xjc”
  • Right Click on the folder –> Build Path –> Use as Source Folder

 

Now the initial setup is completed for the project. Let’s create the necessary packages and start implementing the code. As I mentioned earlier will continue on the post which was publish in www.codenotfound.com.  You can start with the Java code implementation of the link, which is creating the “SpringWsApplication ” class. Also in the tutorial you can download source code.

 

Generate a “WAR” file to deploy in Tomcat

If you want to generate a “WAR” file which can deploy in tomcat, please follow the below steps:

Change in the SpringBootApplication Class

package com.codenotfound;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.boot.builder.SpringApplicationBuilder;
import org.springframework.boot.web.support.SpringBootServletInitializer;

@SpringBootApplication
public class SpringWsApplication extends SpringBootServletInitializer {

  @Override
  protected SpringApplicationBuilder configure(
      SpringApplicationBuilder application) {
    return application.sources(SpringWsApplication.class);
  }

  public static void main(String[] args) throws Exception {
    SpringApplication.run(SpringWsApplication.class, args);
  }
}

 

Changes in the POM.xml

  • Add the below dependencies
<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-thymeleaf</artifactId>
</dependency>

<!-- marked the embedded servlet container as provided -->
<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-tomcat</artifactId>
  <scope>provided</scope>
</dependency>

 

  • Update the <packaging> element from jar to war
<packaging>war</packaging>

 

  • Rerun the mvn command
mvn clean install

 

Read More

What makes an Enterprise SOA?

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:

Application Server

(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

 

Registry

(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.

 

API Manager

(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.

Key Features:

  • 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.

Key Features:

  • 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.

References

Read More

Is Microservices Architecture a sub set of SOA? (Understanding Microservices Architecture by wearing the Developers Thinking Hat)

In the previous posts we looked in to the basic concepts of SOA. Thought of moving to a new term in the technology world called Microservices Architecture. Actually the term is the only thing which is new to SOA world. The concepts behind the microservices architecture came with SOA. However if you’re not familiar with SOA and compare the microservices architecture with Monolithic applications development then this would be a new concept for you. Assuming you have the knowledge in SOA, we will justify the above argument which is Microservices Architecture is a sub set of SOA.

What is Microservices Architecture?

Microservices architectural style is an approach of developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies. – “Martin, Fowler”

Let us concentrate on the definition of microservices architecture and discuss about each special characteristics.

The concept “small services which build around business capabilities”, is a concept we discussed under SOA. Which is Agnostic Logic and Entity Service concept in SOA. Those services are reusable, also concentrate on single small business problem.

The statement “Developing single application as a suite of small services” is yet another well establish concept in SOA known as “Service Composition”. There we have a Service Inventory which is a collection of reusable small services which will help to compose large services / applications.

The newly introduce concept on microservices architecture when compare to SOA is; microservices is individually deployable services which make them very easy to apply continuous integration and deployment. Where in SOA we deploy our services in shared resources. Microservices architecture is more driven by DevOps practices. Mostly deployed in cloud infrastructure, each service has the capability to auto scaling in built. With the immerging container technologies like Docker and surrounding technologies like Mesos and Kubernates will ensure the deploying micro services will be more unwind than ever. This concept will maximize the decoupling of logic and in addition the platform they are deployed. In the long run microservices architecture will minimize the change management cost compare to traditional SOA.

However if you have properly deign and implemented your SOA solution then you should be able to easily deploy your services independently in Tomcat / Nginx application servers across the nodes in your cluster too. Which will cover the key feature in micro services architecture.
In SOA, ESB and BPEL orchestration software plays a major role in building communication structures between different systems enterprise applications. Let’s see how microservices architecture replaces those tools.

 

ESB / BPEL Tools vs Smart Endpoints and dump pipes

Enterprise Service Bus (ESB) main capabilities are message routing, choreography, transformation, and applying business rules. In the microservices architecture ESB capabilities are covered through smart end points and dump pipes. REST protocol with different end points (smart endpoints) which has appropriate logic behind it will ensure the covering of ESB and BPEL orchestration capabilities we see in SOA. Application of a lightweight message bus act as the dump pipes in microservices architecture. It can be simply implemented using tools like RabbitMQ. The key added feature from dump pipes is reliable asynchronous messaging between services which is also common in SOA.

Below diagram illustrate the how microservices architecture differentiate from SOA.

Conclusion

So we can clearly see microservices architecture does not have much difference compare to SOA other than the deployment platform. Further as many articles express; “Microservices architecture is a design pattern of SOA” and Microservices architecture is a new term introduced to latch a new look to very old concept called SOA.

 

References

Read More

Building the Service Oriented Solution

Previous Blog Posts


As we learned from the previous posts, the main strategic goal of Service Orientation is that service must be inherently composable.

As you can see in the above diagram we can reuse services and compose service compositions which will provide a comprehensive solution for a complex problems in the business domain.

So as the time progress developers will get new requirements and as the first step they will check the service inventory.

Then do a proper design for the new business problem on what identifying what are the services they can reuse and what are the services they have to write from scratch.

The new services must be compliance with the set of rules we defined in the earlier posts, and must be placed in the service inventory with intention of future reuse and composition.

Domain Service Inventory

In a large organization which has multiple business domains it’s hard to maintain a single service inventory. So to ensure quick service discovery and easy maintenance, there we introduce a concept called Domain Service Inventory.

Each of the domain inventory is standardized and governed independently. For example, Finance, Shipping, Cargo, HR like domains can be exist in a large organization which has multiple subsidiaries. So having inventory for each domain will be a more organized inventory.

 

Now we completed the design of a Service Oriented Solution. In the coming posts lets investigate on how we can implement those using JAVA and many other systems in the global market.

 

References

Read More

Modeling the Service Oriented Solution by Breaking down the Business Problem

Previous Blog Posts


In this post we will work on how to model the Service Oriented Solution for a particular business problem.

Firstly what is a Business Problem?

It’s a business process which required automated solution. After implementing the business solution business will achieve the following goal.

  • Increased intrinsic interoperability
  • Increased federation
  • Increased vendor diversification options
  • Increased business & technology domain alignment
  • Increased ROI
  • Increased organization agility
  • Reduce IT burden

 

Let’s start the real work by organizing the business process actions into two primary categories which we identified in the earlier post, Agnostic & Non-Agnostic.  To do so we need to do the following steps

  • Functional decomposition : Identify the large problem and then create small collection of problems which will represent the large problem. Then find the solutions for each of the small problems. This method is also known as “Separation of concern theory”

  • Service encapsulation : In this step we need to identify what subset of logic needs to encapsulation within a service

 

Agnostic Context (Reusing the solutions)

  • Reusing the agnostic services : Now we have reusable solution logic units with proper encapsulation. Identification of solution logics which can reuse to solve different problems will take place in this step.

 

  • Utility abstraction : Separate the common, cross cutting functionality that neither specific to a business process nor a business entity . In the service inventory we will have a utility service layer, which can be used in services.
  • Entity abstraction : Similar to utility abstraction, we will identify services which are related to business entities and have them in the entity service layer of the service inventory.

 

Non-Agnostic Context

  • After identifying the all the above solutions related to agnostic context, remaining solutions will be specific to business processes.

 

Now we have organized the solution properly from the above process. So let’s build the Service Oriented solution in the next post.

 

References

Read More

Basic Dynamics of SOA and Service Modeling

Previous Blog Posts


In previous posts we identified what is a service. In this post let’s have a feeling about Service Inventory and Service Composition. Later discuss about Service modeling.

 

 

As illustrated in the above diagram we build services to support different problems. All those services are placed in a store which we name as Service Inventory. Using the inventory we can take one or more services and bind them together to produce a service which can be a solution for a another problem. This approach is known as service composition.  Above is the simplest explanation regarding Service, Service Inventory and Service Composition.

Now we have the fundamental knowledge about basic concepts of SOA. So let’s start the SOA designing from the basic level: “Service Modeling”

The first step in service modeling process is to identify and organize large logical units, so that they can be reassemble into service oriented solutions. Which means we need to group and categorize these according to the nature of their logic. When grouping the logical units there are two main categories: Agnostic and Non Agnostics logic

 

Agnostic Logic does not have any relationship to a parent task. So it can be used in multiple purposes. Hence it’s a reusable component and will help to automate multiple business process.

Non Agnostic Logic is concentrating on a single purpose task. Therefore it’s mainly designed as a single purpose solution.

 

With the logical units we can model the Services. There are four main types of Service Models.

  1. Task Service :- A service with non-agnostic functional context which correspond to single purpose, business process logic
  2. Microservice :-  A non-agnostic service often with a small functional scope encompassing logic with specific processing and implementation requirements
  3. Entity Service :- A reusable service with agnostic functional context
  4. Utility Service :- Again a reusable service with agnostic functional context. But will not cover business requirements. It will cover the low level technology functions like logging, security and notifications

With the above service categories and the logical unit behaviors let’s Breakdown a business problem and design the Service Oriented solution in the next post.

 

References

Read More

Service Oriented Enterprise Architecture

Previous Blog Posts


Previous blog post, we had an introduction to SOA. In this post let’s find out how we can apply SOA in our enterprise solution.

In theory we have Eight Deign Principles which we need to follow in Service Oriented Design Model.

 

When we apply SOA with the above design principles we can observe the below characteristics in our enterprise solution

 

In-addition our SOA solution can be one from the following types;

Service Architecture: Architecture of a single service

Service Inventory Architecture: Architecture that supports a collection of related services that are independently standardized and governed

Service Composition Architecture: Architecture of a set of services assembled in to service composition

Service Oriented Enterprise Architecture: Final outcome which is the Architecture of an Enterprise

High level positing of those types are shown in the below diagram

 

Now we have a clear idea about the design principles, SOA characteristics and four types. In the next post let’s further discuss about Service , Service Inventory and Service Composition.

 

References

Read More