Enterprise Integration and spring broad adoption on EI
-
Upload
chamantha -
Category
Technology
-
view
74 -
download
1
Transcript of Enterprise Integration and spring broad adoption on EI
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 :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
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...