Enterprise Integration and Spring broad

adoption on EIChamantha De Silva

Senior Software Engineer, Leapset Inc.

Topics in this session

� Introduction

� Integration Styles

� File Transfer

� Shared Databases

� Remoting

� Messaging

� For Each Style

� Pros/Cons of each style

� Where Spring comes to play

� Our Concerns on Integration styles

� Based on requirement

� Based on trend

Hypothetical scenario….

� An example to illustrate how this enterprise integration space evolved

� ABC Entertainment is a shopping and hotel Complex, which is a large entertainment precinct located on US. It was started early 1970s and became one of the busiest hospitality destinations with large number of transactions per day

� Why hospitality industry to illustrate

� All of these trends adopted by almost of all of industries; but with hospitality industry...

� Easy to explain

� Also its a predominant industry and an industry helped IT space to grow exponentially after Space programs and Banks

File Transfer � Appeared ~1970s

� Export data as files

� Export data with bunch of information at once

�

File Transfer :Pros and Cons

� Pros

� Its Simple : has simple formats such as CSV, XML, Cobol flat files etc.

� Interoperable : does not contain language dependent information nor system dependent

� Easy : Most of the time it is simple parsing of one type of object

� Cons

� Not real time : Data transfer is not immediate. Systems can be out of sync most of the time

� Processing is Bulky :Large amounts of data needs to process at a time, concurrent issues may occur.

� Not transactional : if something has gone wrong there is no way it can un done

File transfer : Spring support

� Spring batch

� A lightweight, comprehensive batch framework designed to enable the development of robust batch applications vital for the daily operations of enterprise systems.

Shared Database� Appeared ~1980s

� Two or more applications access the common database

Shared Database :Pros and Cons

� Pros

� Transactional : if something has gone wrong things will be rollbacked (All or nothing...)

� Real time : Data is consistent and data is real time data

� Easy : Retrieving or adding data is simple if the system follows/knows the schema

� Cons

� Changing is difficult : If we want to change the database schema, changes needs to apply across all systems otherwise systems will breaks

� Performance issues :Since database/table/row/cell is locked by a system other system might have waiting times

Shared Database : Spring support

� Spring JDBC template

� DataAccessException Hierarchy

� Spring provides transaction management in a transparent way...

Remoting� Appeared ~1990s

� One system calls another to perform a function in a responsive way

� Invoking a function rather than directly engaging with data

� Good old days : number of Remote Procedure Call (RPC) approaches: CORBA, COM, .NET Remoting, Java RMI, etc

Remoting :Pros and Consbased on Remote Procedure Call (RPC) approaches: CORBA, COM, .NET Remoting, Java RMI, Hessian etc.

� Pros

� Real time : function invocation happens at real time.

� developer friendly: Functions can be invoke in OO fashion

� Cons

� Non interoperable : language dependent/protocol dependent

� Hidden complexity : even though functions stick with OO paradigm, complexity is high when it comes to handling exceptional situations

� Performance issues : since most of these RPC approaches are not scalable has limitations when scaling

Remoting : Spring support

� Spring RMI, Hessian /Burlap

� Spring provides Service exporters to transparently expose services through RMI, Hessian/Burlap infrastructure easily

� ProxyFactoryBeans to communicate with service exporters from client side

Messaging � Appeared ~2000s

� Asynchronous messaging is the key introduction in this decade and it still exists

� Separation of systems were introduced via middleware

� Both systems doesn’t need to be up and ready at the same time

� But what about synchronous messaging : web services comes under this? Yes it is Contact 1st SOAP became trend, but then REST is the trend…on this categorization

Asynchronous Messaging:Pros and ConsVia channels

� Pros

� Scalable : Systems are not coupled since interaction happens between Message Oriented Middleware

� Asynchronous: fire and forget message will some how deliver the other system, since its taken care by Message Oriented Middleware

� Efficient : Since system is asynchronous more number of requests can be served

� Cons

� Not Real time : might take a long time to response

� Hidden complexity : complexity is high since message oriented middleware architecture has taken in to play

� Context is distributed : Transaction, security is not in the same context need one more level of extra handling

Synchronous Messaging :Pros and Conswith SOAP and REST

� Pros

� Real time : function invocation happens at real time.

� Interoperable : does not contain language/protocol dependent information

� Easy/Less complex : easy for developers, less complex to handle exceptional situations compare to previous generation of RPC and even easier than asynchronous messaging

� Cons

� Spec Dependent : does not have any standardized mechanism for dynamic discovery of the services.

� Changes will be hard : since its spec dependent, some of changes might break existing clients

Asynchronous Messaging : Spring support

� Spring JMS

� JMS integration framework simplifies the use of the JMS API. its more like Spring JDBC template

� Spring AMQP� provides a "template" same as Spring jdbc template with a high-level abstraction

for sending and receiving messages.

� Spring Integration � Provides lightweight messaging within Spring-based applications and supports

integration with external systems via declarative adapters. Spring has extended its programming model to support the well-known Enterprise Integration Patterns.

Synchronous Messaging : Spring support

� Spring REST� Spring's annotation-based MVC framework serves as the basis for creating

RESTful Web Services. configure servlet contaiIner for a Spring MVC application using Spring' is all you need to do

� In other hand at client end can use Spring's RestTemplate which is a robust and easy to use

� Spring SOAP� Focused to facilitate contract-first SOAP service development, allowing for the

creation of flexible web services using one of the many ways to manipulate XML payloads. SOAP endpoints are similar to MVC endpoints

� Spring-WS provides a client-side Web service API that allows for consistent, XML-driven access to Web services

Our Concerns on Integration styles

� Where are we fit into ?

� Best of synchronous and asynchronous messaging ...

� RESTful Web services for synchronous

� Middleware Oriented Messaging for asynchronous messaging ...

Introduction to RESTful Web services

� REST stands for REpresentational State Transfer

� Its a simple stateless architecture that generally runs over HTTP ...

� Not a standard but has some de facto features

� Spec based interfacing

� Not tied to HTTP but associated mostly with HTTP

HTTP based REST.. - de facto

� Request URI to identify resources

� Make use of HTTP methods so we can manipulate the ame resource different aspects ...

� POST

� PUT

� GET

� DELETE

� HTTP headers will be meta data that describes the message

� HTTP 1.1 spec says ...

The POST method is used to request that the origin server, accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line...

� In other words, POST is used to create

POST

� HTTP 1.1 spec says ...

The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI...

� In other words, PUT is used to update the existing resource and if resource does not exists create it.

PUT

� HTTP 1.1 spec says ...

The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI...

� In other words, Retrieve information

� Must be safe and idempotent

GET

� HTTP 1.1 spec says ...

The DELETE method requests that the origin server delete the resource identified by the Request-URI. This method MAY be overridden by human intervention on the origin server. The client cannot be guaranteed that the operation has been carried out...

� In other words, Delete the resource

� Does not need to be deleted at real time

DELETE

Demo...

� Back end needs so support REST….

� Create Customer

� Get Customer

� Update Customer

� Delete Customer

Introduction to Messaging with RabbitMQ

� RabbitMQ is a message broker based on AMQP protocol

� Message broker and their roles

� Message brokers receive messages from publishers and route them to consumers

� Since AMQP is a network protocol, the publishers, consumers and the broker can all reside on different machines

� AMQP is also an open protocol, so systems which is based on different languages/platforms can communicate easily

Producer and consumer via RabbitMQ

image credits : http://www.rabbitmq.com/img/tutorials/intro/hello-world-example-routing.png

Demo….

� Create a message receiver

� Create a message consumer

� Communicate

Messaging via Messaging Bus based on EIP

� Spring has introduced Spring integration to adopt EIP

� Spring integration provides all most all features of an Enterprise Service Bus but its more of an embedded component rather than an different middleware system

� Will be a separate presentation...

Questions and Answers