so my name is Alexander Weisenfeld I’m a consultant at a company in Germany which is called in OQ and I’m here to talk about enterprise integration patterns today just one one thing to mention first I’m on Twitter on the handle at Gulch tilt and if you tweet about this talk I would be would be very kind to include the hashtag so I can get back to you I will just sit through the tweets later on today and then I will respond to any questions that are there in the tweets okay so let’s start as I said I’m going to talk about enterprise application integration patterns and just let me cast a quick vote who have you already heard about the term eai or enterprise application integration perfect is there anybody who cannot handle this term or doesn’t know what the actual benefits of this is about perfect okay so basically this talk is introduction to the enterprise application integration in general and why in my point of view this is quite important to know about the patterns so let’s start when someone mentions enterprise application integration at least in Germany I often hear people say something like oh hey I patterns in 2013 really are you going that way nobody does it anymore and you know what actually that is my problem many solutions I saw didn’t recognize enterprise application integration patterns though in my point of view the things could have been much more easy and I just have to say that integration challenges are still around and in my point of view they are actually growing and why is that so because actually integrations necessary when at least two applications or modules connect either one way or bi-directional so actually machine to machine is not only about exchanging data but also about providing services to maybe get unknown applications and the reason for this is that today mostly every customer can access companies services for example via their mobile phone or their smartphones and thus company customers expect companies to provide their internal services which are actually only available via hotline or via the desk to offer these services as a kind of self care interface and that is why in my point of view we have more and more integration challenges so we’re going to talk about the eai patterns and these not only touch application integration architecture as you know but they describe solutions for common integration challenges and that’s why they are often called remedy for integration pains when we think about patterns most of us first of all talk about this 20 year old design patterns book by the Gang of Four which describes proven solutions for common problems but I don’t know how many of you were at Java one last time last year when we had multiple talks about why these design patterns aren’t actually worth watching anymore my point of view this is totally different for the enterprise integration patterns if you don’t know the the classic on eai patterns yet this is the enterprise integration patterns book by Gregor hoppy and Bobby Wolfe and this has been created under the guidance of Martin Fowler and this not only describes solutions but it actually defines a common capillary which was missing before that book and it describes a common body of knowledge for a synchronous messaging and that is why this book is also called the Swiss Army knife for a synchronous messaging and you can find more information about the book and current information at eai patterns calm I will get back to that page later on in the talk and in my point of view the most important statement in the book is in

forward when there are several integration styles discussed by Martin Felder himself and he said that we all believe that Aston Connors messaging carries the greatest promise so for the ones more advanced this means that he not only describes that asynchronous messaging is actually the way to go but the next step would actually be the stage event-driven architecture which is called or abbreviated as si de I’m gonna provide a link for those of you not familiar with Si de with the slides so is it really about messaging so my application needs a kind of inbox or something like a postal service well actually the benefits of a synchronous messaging maybe aren’t too clear when you first of all her hear the term the first thing that most people mention when they when they argue about asynchronous messaging is that applications who rely on a synchronous messaging are highly decoupled and that is actually because of the message based communication and also through the messaging infrastructure for example the message bus adapter we have the ability to integrate heterogeneous platforms and languages so it’s no problem to connect a java application to an SI p system or our net application also we have reliable communication when when we use transactions and persistent queuing where necessary so for we can actually decide where we want to have this reliability and we need it and where we don’t and through this decoupling actually comes another benefit which is called disconnected operation that means any component of the system can have a downtime without making the system fail now we’ll also get back to this later on and through this disk upload decoupling and disconnected operations you have a throttle system which actually means that you have a variable timing for each component of your system so you have to imagine that you have systems which are decoupled into separate components and that you can tap a time each component at its pace which means if one component can’t work on more than 100 messages a second you can easily scale this with the a synchronous messaging ok now maybe we got Y as mikanos messaging is nice but why do we need the patterns while the thoughts on enterprise application patterns is that Gregor happy once stated that real patterns aren’t actually invented by someone who is just a genius real patterns are actually observed from field practice and another point is that good patterns don’t solve everything but just a concrete problem and they provide ideas which means that they give you an idea on how to approach a different challenge or problem and another statement I really like is that good patterns evolve over time which comes in for the AI patterns especially because as I mentioned before the AI patterns calm website holds information on all patterns that are available and the changes which came in over time you remember the book was from it was written in 2004 and all the changes that happened from 2004 until now are actually incorporated into the into the website because this is still managed by Gregg Araki himself okay these aren’t nice ideas but you may ask why should I care really okay I can do it myself better so let’s dive into a kind of real life scenario there is a simple order management system from a a so-called fourth party logistics provider or 4pl

which I did a couple of years ago and I don’t know whether you all are familiar with the four PL term and this is actually a a service provider who has no real logistics hardware or or trucks or something like this who is just into providing services and organization and therefore 4pl is always about integrating other business partners and in this case the customer said okay I need an order management system and really all I need is a small basic Java EE application where I can type on the artists manually or were my where my employees can type all the artists so we created a small trut application based on Java EE which was actually a so-called information sealer so it had no connections to any other system and all the information that was should be insert it had to be typed in manually and all the information that should have been extracted had to be printed out via the web interface but as it happens there are changes and it took only a month until the customer said well this typing takes actually a lot of time for my employees I want you to enhance the system with an order importer and we have a external business partner who sends you CSV data beyond HTTP POST and this CSV data contains header detail records and I want you to import these data into our database so we can see it in the web application and hello we were into integration challenge so we thought about ok we have a simple Java EE crud application here why not solve it with Java EE ap is so here’s a simple Java EE sample which solves the problem what this does it’s actually a a simple Java servlet registered on the on the context root of / auto / import and it takes a post request reads the CSV data parameter from the request and hands it over to a CSV data parser which is a self created class and this parser returns a list of orders and then we simply persist the orders with a Java EE being so that was a simple change what if we do to the system from architectural point of view we just added an HTTP endpoint added a transformer and so the external business partner was able to send a CSV data and yeah it seemed good so far so is everything okay here until now I would say yes no problem works okay but you know change happens and after about another three months the requirements of our 4pl service provider grew and grew and then we had to integrate another system of a for water I don’t know whether you are familiar with the photo of for water term this is actually a service provider for shipment and what this should do is that new shipping should be sent to this for water system via FTP but unfortunately only the for water system couldn’t send us any responses back so the employees of the for water would create a mail put in the their necessary data and sent it to our system so we needed an SMTP adapter and then the business partner from outside had another requirement that he wanted to see the status of an order and he wanted to have a rest interface for this so he could for example cancel an order or things like this but unfortunately

the for water system wouldn’t let us change anything except for a soap web service security and encrypted endpoint so we had multiple interfaces which were there to to implement into our and a simple crud application so what do we learn from this change happens okay now would say you can recognize an integration task when it’s staring in your face yep that’s easy and the solution might look like this yeah if you want to build an easy and maintainable solution for multiple integration challenges that is actually no problem but the solution might look like this so when we think about the new requirements that we had just let me cast a few a short vote I’m interested in this how many of you have seen such an implementation in encode yet yeah thought so and who wants to maintain a code base like this okay perfect Thanks so going back to our simple Java EE sample I would ask against everything good here or is something wrong is anyone developing agile here so what is about easily testable doesn’t look too good reusable mmm maybe we can you reuse the CSV data parser it should also be testable about hmm okay it’s this extensible easily I guess not so and this point in time we also have to ask ourselves if this is not tests not too good testable not too reusable and not extensible how good would a new team member accept such such interfaces that we created for a simple thread application which grew over time oh sorry and the answer is mostly they won’t understand our yet standard based but self-developed code that is where the application integration patterns come in so let’s introduce a simple but very common integration pattern called pipes and filters the pipes and filters pattern is actually about dividing your task into small steps that is the main point of application integration that you think about what you actually want to do and divide your integration challenge into as small steps as possible because these small steps he referred to as filters are much better testable extensible and reusable when we think about this sample here which is directly taken from the enterprise integration patterns book what do we have here I think we can easily see that there is an incoming order and the incoming order arrives as a message and we see that the order is encrypted for security reasons and to show ensure integrity so we need to decrypt this what else happens there we have an authentication filter this means that we have to check that this is actually a trusted customer who deserves a special treating and another point is the deed up we won’t we don’t want to duplicate orders in our systems so we also have to check this and let’s say when you have requirement changes here for example you introduce another step where you say ok my incoming order data is changing and I need to transform this this is easily possible so we can just introduce another filter for example between the authenticate and deed so that the data before we check for wk ssin is actually transformed into the

format that we understand so you see by applying this pipes and filters pattern we have a very good structured application architecture and what this mean for for our sample let’s apply the pipes and filters pattern to our sample that we had first of all we have a inbound filter which would be the servlet for example then we would send the data through a pipe which is nothing more by the channel and the channel could be a persistent channel for example persisted in the database or it could be an in-memory channel just as we think is necessary next we want to do a transform which is a custom implementation then we sent this transformed data you remember the CSV contains all the headings and order details so we have to transform this into just the orders with a list of order details send these list of orders into another pipe and outbound would be AJ PA outbound adapter which just sends it to the database and this is actually easily this can easily be put together by plumbing code in CDI now most of you will argue that such a solution is actually pretty hard to test when you think about integration testing but I can prove you wrong because you can easily test this integration with the arquillian framework and fitness so don’t fear the the benefits you get when decoupling and dividing your application to model components you get easily testable components in unit tests and you still have the ability as you are using Java EE ap is in general that you can easily test this with arquillian with the achillion framework which provides a simulated java ee container for you during integration testing so this is no excuse for not applying the enterprise integration patterns to your application so actually we could say um when you get the right tools to do the job everything is fine right yeah everything is infallible but maybe the solution won’t be as expected one could argue that this is actually pretty nice because we have all the adapters there and we have multiple ways to enhance this and to put other things in in there but there should be a simpler solution and is there a simpler solution I say yes we have frameworks which provides you adaptors for more than just the common interfaces which are around these days and this is where the so called eai frameworks enter the stage so when you think about the eai frameworks there are multiple around and I’d like to introduce to you the the most or let’s say the the best open-source eai frameworks which are there which is namely apache camel and spring integration concerning the differences between both they both one very fine with the spring framework as a dependency injection but camel can also integrate very well with the CDI at the moment unfortunately spring integration is not so widely distributed and the java ee environment i got it running on a JBoss 5e ap with the JBoss specific framework called snowdrop but this won’t unfortunately run on on GlassFish at the moment but as we know we have this CI extensions project and they’re working on exactly this that we can actually start spring contexts within a CDI container and that would be

a great fit for spring integration so for further differences that are actually measuring to us I would say that camel has way more adapters available than the spring decoration framework which means that camel not only has standard adapters for example HTTP FTP file system but it also has common adapters for things like s AP for the Amazon s3 and for multiple multiple other things you can imagine so if you have really a large integration filled with large integration challenges then I would really advise you to take camel on the other hand spring integration seems much more flexible lightweight and unobtrusive well sorry about that so now just look let’s look at a simple sample for apache camel we have a simple camel root here which actually handles our scenario that we introduced before and handled via our servlet implementation so what this does is it takes requests from a HTTP endpoint which is here located at the localhost / order / import we provided a specific route ID which is the name of this route so to say and then we do actually the same that we already did with our self implement it sorry with our self implemented servlet the first thing that happens here is a post parameter processor which does nothing more it’s actually a three lines three lines of code which actually does nothing more but extract the post parameter CSV data and writes it into the body of the message and afterwards this is say yeah let’s say camel specific that we extract all double quotes from our string and then this is built in service by Apache camel as I said we can unmarshal our incoming CSV data which is provided by camel so you don’t have to implement anything this is really great configurable and in this case you can provide several several ways for extracting the CSV data and what this does is actually that you have the CSV data and this is split into into a list the same way that our self implemented CSV data parser did it only with the abilities of apache camel so we didn’t have to build anything ourselves and so we don’t have to test this because apache camel and also spring integration have a pretty decent test coverage and all the things that you don’t write yourself you don’t have to assure that it works for yourself but the nice thing is see this is a very fluent API for for apache camel camel also has the ability to to be configured by an XML but it also has the ability to be used as plain java objects so you can configure it either way you like it or which fits best for your application that means you can easily integrate your components with apache camel implement the interfaces of camel and mix your stuff and test your components on a very simple basis let’s look at another sample for spring integration so what spring integration does here is actually the same but splain integration doesn’t provide a fluent api yet what it does is basically the same in the XML we create a HTTP inbound channel adapter which

listens on the on the context root of slash order slash import and only accepts post methods and sorry only accepts the post method when a request comes in it is transformed into a message this message is sent into the orders in Channel the upcoming splitter is listening on the artists in input channel and you see here we have a we have a reference to a simple spring beam which is here this is a reference to the order splitter and this calls the method split so you see this is the way to use your components with spring integration this is another way spring integration doesn’t provide a a standardized CSV import so I had to write it myself but the nice thing is that spring digression doesn’t rely on that you implement any interface you just have to write a a simple class name it whatever you want name the method whatever you want expect an incoming string return a list of objects and then you can use it this way in your spring integration configuration which means this is far more easy to test then when you have to implement any interface which has to be there in your tests and you have a larger test scope actually then when you just have your plain java code another nice thing is that spring also provides a our spring integration provides a very decent way to handle the the JPA entity managers here as you see the JPA updating outbound gateway will actually only take our list of orders and call the entity manager for this list of orders and simply update or insert the orders which are in the list so we don’t have to check for duplicates or things like this if the order is already there it is updated for us if the order is not there it’s inserted so that is a nice feature of spring integration so now you could ask so should i always use an e aí framework actually that is your choice it really depends and your choice should from my experience depend on your existing application which means if you already have a Java EE application and want to use a eai framework or want to integrate the integration challenge to your system that would mean that you would have to couple your application with an e aí framework which as I mentioned is at the moment only possible with apache camel but the other question is whether you actually wanted to introduce an e aí framework into your java ee application with JMS 2-0 it’s much easier to just send out in JMS message which can be handled by a separate application this separate application is actually nothing more but apache camel or spring integration so what you have is afterwards you have your Java EE application running just fine and you have you have separate applications running there doing your integration stuff and that is the nice thing that when you have such a decoupled system that you can easily scale your system as you need it you can easily pull out a for example in an apache camel root and put it into another application and start it twice for example let’s say you have a a database back-end as I said which cannot handle more than 100 requests per second then it would be very easy to reproduce this database back-end and to duplicate it and to duplicate the application that is actually putting the data into the the database system so in this way you

have for example two integration systems which both put 100 requests per second into your database into separate databases and these can be synchronized afterwards so you have no problem to actually scale and throttle your application as you need it and there’s another point on the asynchronous messaging that you can also say how many messages may be cute in a persistent Q this is for example necessary if you want to have a disconnected operation feature so let’s say you want to maintain one of these two integration systems which right into your database you can if you have a persistent queue you can simply shut down one of them and the other one will just run fine but only at the speed of 100 requests per message per saying sorry so as I said your choice depends on your application but it also depends on your infrastructure if you don’t have the infrastructure and the network resources and the people that actually can maintain and maintain an operation those multiple systems then the choice would be that you had to actually implement the integration into your Java EE application to have as few systems as possible but yeah this is not the the way we actually want it to be and mostly when we discuss with operation teams on a consulting basis that actually comes out that they first of all fear that more systems would be would be an overhead of more maintenance but actually as these small integration applications become very lightweight it’s actually a relief for them because the maintenance time they need actually is being reduced because of the decoupled operation and disconnected operation so they don’t have to wait until for example 8 p.m and the evening to shut down an application but they can easily do it by the day during the day and the third thing your choice should actually depend on is the know-how of your team if you have a team which is already familiar with Java EE I guess you wouldn’t want to introduce the Spring Framework if your team is actually very familiar with the Spring Framework maybe you wouldn’t want to introduce Java EE as an integration solution so my advice is if you have a Java EE application Java EE 5 Java EE 6 then start with the Java EE 7 api’s me great and have a look at how many integration challenges and interfaces are actually there and then afterwards if you consider to decouple your components and to make them as small as possible then you can easily scale up with your created components to apache camel or spring integration which means you have your Java EE application which contains your small components and you can just pull out these classes and put them into the spring integration application and use them there without implementing any interface without changing your code this worked at a larger customer telephone company in Germany which was really skeptical about this so further tips considering EA I from my side as already said small building blocks is actually the main message I want to get over today because the smaller your building blocks are the easier the faster and the cleaner is your feedback and that is actually what we are talking about when we are talking about agile development we want to have a fast feedback we want to have easy testable components and that means create small building blocks another point is on keeping it simple please consider – don’t have shared mutable state in many applications I see that there are like global configuration stores or a global cash system where multiple multiple classes of the application read from and

write into if you want to parallelize processing you have a big problem there when you don’t pay attention to concurrency and if you use if you don’t use shared mutable state but immutable objects you won’t have these problems and the next type is actually derived from this use immutable data transfer object objects which are an AI contexts also known as messages I don’t know who many how many of you already seen this message interface of offspring integration or apache camel but they are using the Builder pattern which means you create a message via the Builder pattern and you cannot change this message anymore you can just hand this message you have over to a over to a message builder and then modify via this message builder the attributes that you want to have modified but you cannot modify a message so everyone who has a reference to this message can be sure that this data won’t be changed and this is a very relaxing and relieving a pattern when you actually think about paralyzing your your threads because you don’t have to think about concurrency and the concurrent modification problem so use immutable data transfer objects and by using you actually increase your scalability of your applications and make it ready for scalable processing and for those of you who want to have and let’s say advanced insight into this get familiar with the so-called actor model the actor model is actually a way of handling state only buyer immutable messages and as you see this is underlined here in the slides there will be a link to a very nice visual explanation of the actor model and how you can actually implement it into you in your application so that’s it from my side I would say thanks for your attention I hope everyone takes away something from this talk though most of you already had were familiar with the enterprise integration patterns what I really love to have is your feedback on the chart because this was the first time I gave it and yes I would really love to have your feedback your questions and so either ask questions now or you can also tweet with the hashtag j1e AI if you like so any questions from your side yeah you mean with the apache camel a CSV configuration okay the question was how does camel handle a different data formats in CSV file you can actually configure this most of this is handled automatically which is pretty nice so may even has a kind of sorry apache camel has a kind of analyzing your data and so it will recognize whether this is a date or not but you can actually configure this so you can say okay column four is a date and use please please use this date pattern to transform it why is that advantage because I can see okay I decided for watching a few years ago I am okay so the the question was how is what are the benefits of spring integration compared to Apache camo

as I said a my point of view the spring integration is much more lightweight than apache camel will not only considered considering the dependencies which come in but also from a point of view of the application development model i can show you a sample where you actually wouldn’t expect that there is a spring digression happening there what you can have first of all you are absolutely right you don’t have to implement or you don’t necessarily have to implement interfaces when you’re using apache camel but what you don’t have with patchy camo is spring provides a kind of proxy mechanism which lets you inject a interface into your class you can use it as a normal class calling these the methods on the interface and there actually is no implementation for this interface so you just create an interface for example with them with a with a method that takes is actually in your XML code and then or in your Java code if you if you want to configure a spring in Java independent of spring integration which makes it much more easy to test so if you use the fluent API of apache camel you always have to test with the kappa mechanical components in mind and you have to create a matching test context and this isn’t the case for most of the things you use spray integration for I know yeah as as I said it’s you’re just providing the information but it’s I know that that is actually the point but you have to use these camel test classes that is that is the point and what I what I wanted to mention is that oh right well with Apache County yeah yep you’re welcome my opinion on mule ESB is yes I’m actually a little bit opinionated on this because we had a really large pain when migrating an application from J bus for ei p2j bus v EAP with mule one of the problems was that we were using new – prior to this this is about I guess three years ago and mule – was open-source you can use it for free but moo3 isn’t so that was actually the first problem when we thought okay do we want to pay for new just the the framework not the ESB or don’t we want to do this and the problem here is that actually we couldn’t see the the benefit as we were just using the mule integration framework so that we would have said okay there are so many benefits that we want to pay for the integration framework and that was when we really got into struggle when we had to integrate mule 2 into J bus five there was a lot to be done and mule still yeah doesn’t feel too good in my opinion and as I said if you want to have a SB product the mule ESB comes into mind but if you just need an application integration framework then I would certainly say that mule 3 isn’t superior to anything either spring integration or apache camel i would always choose both over the mule integration framework you’re welcome

any more questions yes you seen the jameise 2-0 API okay let me just think about whether I have assembly the API got very very very very much easier than JMS one and I think yeah Aaron Aaron Gupta just published the Java EE 7 samples which are related to his book on on github he one I can give you the link and you can have look into this it’s it’s just a breeze it’s really easy and nice to use he has several samples on different scenarios there and actually he’s always up for feedback on these things so that would be what probably be a way to to look at this okay any more questions so as most of the others already gone I would say thanks very much for attending and yeah let me know your thoughts on on Twitter or yeah I’ll be around the conference for the next couple of days so maybe we’ll meet each other thank you very much