- talk about the main components: router, transformer, adapter, filters, service activators - pipe-and-filter based architecture
class: center, middle # Training Course: Enterprise Spring  Trainer: Joel Budgor, [ExitCertified](http://www.exitcertified.com/) Training Material: [Pivotal Training](http://pivotal.io/training) Training Format: Live Feed (San Francisco) Date: June 9 - 12, 2015 Trainee: Jeff Mair, Jonah Group --- ### Background Q: What was the course motivation? * Support existing Spring-based Enteprise system at IBM/Algo * Expand my Java application development capabilities Q: How did I find this course? * Google search --- ### Course Delivery * instruction was via live video feed from [ExitCertified San Francisco](http://www.exitcertified.com/locations/san-francisco-training.php). * two-way video / audio conferencing on two large TV screens (one showing the instructor, other the content) <img style='width:600px' alt='pic' src='./img/exitCertifiedRoom.jpg' /> --- ### Course Delivery Critique Live-video course delivery: double-edged sword... <img style='width:400px' alt='pic' src='./img/exitCertifiedRoom.jpg' /> <div style='width:300px;float:left'> <h5>Pros:</h5> <ul> <li>less distraction from other trainees (just mute the tv)</li> </ul> </div> <div style='width:300px;float:left'> <h5>Cons:</h5> <ul> <li>more effort required to get attention</li> <li>possible to miss instructor nuiances</li> </ul> </div> --- ### Course Summary Four Day Course: 1. [Spring Tasks & Scheduling](http://docs.spring.io/spring/docs/current/spring-framework-reference/html/scheduling.html) 2. [Spring Remoting](http://docs.spring.io/spring/docs/current/spring-framework-reference/html/remoting.html) 3. [Spring WS](http://docs.spring.io/spring-ws/site/reference/html/server.html) 4. [Spring REST](http://docs.spring.io/spring/docs/current/spring-framework-reference/html/mvc.html) 5. [Spring JMS](http://docs.spring.io/spring/docs/current/spring-framework-reference/html/jms.html) 6. [Spring Transactions](http://docs.spring.io/spring/docs/current/spring-framework-reference/html/transaction.html) 7. [Spring Integration](http://docs.spring.io/spring-integration/reference/html/overview.html) -- > focus of this presentation 8. [Spring Batch](http://docs.spring.io/spring-batch/reference/html/) --- ### What is Spring? * Java framework; takes care of boilerplate code so you can focus on logic * Primary framework feature is XML-based object composition & injection * Many additional components: * spring integration * spring batch * spring security * spring web flow * spring social * etc * Spread out across many packages and jars (confusing) * Recommendation: use maven or gradle to manage jar dependencies!! <img style='width:400px' src='./img/spring-overview.png' /> --- ### Spring Integration Q: What is Spring Integration? A: an implementation of the *messaging patterns* defined in *Enterprise Integration Patterns* (Gregor Hohpe) <div style='float:left;margin-right:50px;'> <img style='width:200px;' src='./img/EIPBook.png' /> </div> <div style='clear:both' /> <br> [enterpriseintegrationpatterns.com](http://www.enterpriseintegrationpatterns.com/) [amazon.com](http://www.amazon.com/Enterprise-Integration-Patterns-Designing-Deploying/dp/0321200683/ref=sr_1_1?ie=UTF8&qid=1435433537&sr=8-1&keywords=enterprise+integration+patterns) --- ### Spring Integration Q: What is Spring Integration? A: an implementation of the *messaging patterns* defined in *Enterprise Integration Patterns* (Gregor Hohpe) <div style='float:left;margin-right:50px;'> <img style='width:200px;' src='./img/EIPBook.png' /> </div> <div style='float:left;margin-top:120px;color:#50a050'> <strong><em>Recommended Reading!</em></strong> </div> <div style='clear:both' /> <br> [enterpriseintegrationpatterns.com](http://www.enterpriseintegrationpatterns.com/) [amazon.com](http://www.amazon.com/Enterprise-Integration-Patterns-Designing-Deploying/dp/0321200683/ref=sr_1_1?ie=UTF8&qid=1435433537&sr=8-1&keywords=enterprise+integration+patterns) --- ### Styles of Integration (EIP) --- ### Styles of Integration (EIP) **File Transfer** * simple & fast * application code is nicely decoupled * not very scalable, nor highly concurrent * easily corruptible <img class='styleimg' src='img/FileTransfer.png' /> --- ### Styles of Integration (EIP) **Shared database** * better scalability, data consistency, and concurrency * applications all have access to the same data anytime they need it * more complicated to implement & modify than a formatted file <img class='styleimg' src='img/SharedDatabase.png'/> --- ### Styles of Integration (EIP) **Remote procedure invocation** * allows interacting with functionality in another application directly instead of a result of sharing some data * data is encapsulated behind a real API * however... often slower than other styles; more difficult to make reliable due to hidden implementation details; can be difficult to troubleshoot; also more tightly coupled due to reliance on a real API <img class='styleimg' src='img/RemoteInvocation.png'/> --- ### Styles of Integration (EIP) **Messaging** * like FT, applications are decoupled, except for the message format * sending is asynchronous; receiver even can be entirely unavailable at the time of sending * middleware messaging systems provide "guaranteed delivery", highly scalable, etc <img class='styleimg' src='img/Messaging.png'/> --- ### Core Messaging Components --- ### Core Messaging Components **Messages** * a message is the actual information (plus some meta) that needs to be transferred. This could be human-readable text, binary, etc. <img class='styleimg' src='img/Message.png'/> --- ### Core Messaging Components **Messages** * a message is the actual information (plus some meta) that needs to be transferred. This could be human-readable text, binary, etc. <img class='styleimg' src='img/Message.png'/> **Channels** * the connection between two end-points; usually implemented as a queue or topic <img class='styleimg' src='img/MessageChannel.png' /> --- ### Core Messaging Components **Filters** * sits between two channels, and optionally does not allow a message to pass from one to the next (based on your business logic) <img class='styleimg' src='img/Filter.png' /> --- ### Core Messaging Components **Filters** * sits between two channels, and optionally does not allow a message to pass from one to the next (based on your business logic) <img class='styleimg' src='img/Filter.png' /> **Transformers** * sits between two channels and alters a message based on the needs of the business; maybe changes the format, or adds additional information (enrichment) <img class='styleimg' src='img/Translator.png' /> --- ### Core Messaging Components **Routers** * connects one incoming channel to multiple possible output channels; forwards incoming message to particular channel based on the nature of the message itself <img class='styleimg' src='img/Router.png' /> --- ### Core Messaging Components **Routers** * connects one incoming channel to multiple possible output channels; forwards incoming message to particular channel based on the nature of the message itself <img class='styleimg' src='img/Router.png' /> **Endpoints** * where the message enters or exits from the messaging infrastructure; sender endpoint places the message on a channel; receiver endpoint lifts a message off a channel <img class='styleimg' src='img/Endpoint.png' /> --- ### Back to Spring Integration * Spring Integration takes the benefits of messaging patterns and applies within a single application (JVM) * now instead of loosely coupled *applications*, we have loosely coupled *POJOs* * messaging patterns are defined declaratively in Spring (very flexible!) --- ### Back to Spring Integration * Spring Integration takes the benefits of messaging patterns and apples within a single application (JVM) * now instead of loosely coupled *applications*, we have loosely coupled *POJOs* * messaging patterns are defined declaratively in Spring (very flexible!) <img style='width:400px' src='./img/Messaging.png' /> --- ### Back to Spring Integration * Spring Integration takes the benefits of messaging patterns and apples within a single application (JVM) * now instead of loosely coupled *applications*, we have loosely coupled *POJOs* * messaging patterns are defined declaratively in Spring (very flexible!) <img style='width:400px' src='./img/MessagingNot.png' /> --- ### Back to Spring Integration * Spring Integration takes the benefits of messaging patterns and apples within a single application (JVM) * now instead of loosely coupled *applications*, we have loosely coupled *POJOs* * messaging patterns are defined declaratively in Spring (very flexible!) <img style='width:400px' src='./img/MessagingNot.png' /> <img style='width:400px' src='./img/MessagingSpringIntegration.png' /> --- ### Simple Example: Filtering a String **Trivial example**: String comes in from STDIN (keyboard entry); passes through a channel to a filter; filter passes or discards the message; passed messages go to some logger, discarded go to another. <img style='width:100%' src='./img/IntegrationGraph.png' /> --- ### Equivalent Xml <img style='width:100%' src='./img/IntegrationBeans.png' /> --- ### More Interesting: Cafe Example <a style='font-size:0.8em' href='http://docs.spring.io/spring-integration/reference/html/samples.html'>Cafe Sample</a>, <a style='font-size:0.8em' href='https://github.com/spring-projects/spring-integration-samples/tree/master/applications/cafe/cafe-si/src/main/java/org/springframework/integration/samples/cafe'>source code</a> <img style='width:600px' src='./img/cafe-eip.png' /> #### Can you see any benefits here? * Why split composite messages? (hint: simpler implementation, easier to test) * Why route down separate paths? (hint: what if the cafe wants to start selling pastries too; what is the minimum change required?) --- ### Spring Integration Benefits / Alternatives #### Benefits * flexible way to implement complex workflows * forces a good separation of concerns * has plenty of adapters (connectors), handles plenty of infrastructure for you * acceptable GUI designer in eclipse which augments xml configuration * might be good for projects with loose requirements that are expected to change frequently --- ### Spring Integration Benefits / Alternatives #### Benefits * flexible way to implement complex workflows * forces a good separation of concerns * has plenty of adapters (connectors), handles plenty of infrastructure for you * acceptable GUI designer in eclipse which augments xml configuration * might be good for projects with loose requirements that are expected to change frequently #### Drawbacks * steep learning curve * difficult to troubleshoot * more trouble than it's worth...? It will be costly to get team members up to speed on the technology, then can you really recoup that cost later? Maybe, maybe not Alternative: *Apache Camel*. Another implementation of Spring Integration. Apparently more popular, has more external adapters. --- ### Questions during the Presentation **Q: Aren't Shared Database and Messaging basically the same?** A: With all four of the styles of integration, the most significant difference is in the receiver. Suppose you have a messaging-style receiver; typically your code is only responsible for having a callback method that receives a single message object. This is a simple pattern to program against; requires little code, easy to test & maintain, etc. You just process the single message and you are done. However, suppose your receiver is using a shared database instead. Your code in that receiver application is responsible for *fetching* a message from the database. So you would need something like a loop that periodically polls a particular table for a record. Then what happens if there are more than one new record, which one does it process, in which order? Then does it delete the record afterward? So there are a lot of details that need to be dealt with if you are sending "messages" via Shared Database. Decisions and assumptions surrounding those kind of details run the risk of leading to bugs. Also, this may not scale well if you want to add additional receiver applications that are polling the same database / table. --- ### Questions during the Presentation **Q: In spring-integration configuration, why do you need to configure a "channel" if it just connects two components and adds no value?** A: There are several types of channels available for you to choose. If you use a channel with no additional configuration attributes set, it will operate in a synchronous fashion, which indeed does not any value that I can see. However, you can configure any channel to be asynchronous, which of course means that whatever thread is placing the message on the channel won't be blocked until the downstream activities are finished. So there's some value there. --- ### Questions during the Presentation **Q: Can your pojo classes auto-generated while you implement your workflow in the spring integration graph (gui plugin)?** A: I did a little experimenting in Eclipse and I was not able to achieve this. It would be a function of the IDE plugin for spring. In my experience with IntelliJ, however, it often smartly recognizes broken references, missing imports, etc, and might be able to auto generate a class from the XML source view of the spring-integration context file. --- ### Questions during the Presentation **Q: How do the references to your business logic work? Are they references to concrete classes?** A: Suppose you want a router in your application. You would declare a router element in your spring context (xml), then assign the 'ref' element to some bean which is also declared in the spring context. This bean would explicitly reference a class by name (unless there is a way to get around that which I'm not aware of). If you want to be able to change this without recompiling the application (which I think was the point of the question), I believe you can. You just change the class that your bean is a type of in the xml spring context, and restart the application. Of course it would still need to be a type that is acceptable to whatever other beans are referring to it (such as your router), but as long as it satisfies any interface constraints, it should be fine. So you could add another jar later with a class that implements the necessary interface for the router, for example, and change the spring config and restart and you should be good to go. (Though I don't recommend doing this without testing!! :)) **Q: Is there a spring-integration visual designer plugin for IDEs other than Eclipse?** A: A cursory google search indicates to me that it is available in IntelliJ. https://www.jetbrains.com/idea/help/enabling-spring-support.html --- ### Questions during the Presentation **Q: Does spring-integration span a single JVM/process or a single application? E.g, you could have multiple applications running in the same servlet container.** A: Spring-integration is configured in the spring-context for a single application. --- ### Questions during the Presentation **Q: Is apache camel also limited to a single application like spring-integration?** A: What I read is that it is a "Java object based implementation of the Enterprise Integration Patterns". This means single application to me. --- ### Questions during the Presentation **Q: When should I use spring-integration?** A: Good question! I think that good cases for spring integration may be where your application already uses messaging *externally*. I found a decent example in the course slides (see attached diagram from pg 360 of the course notes PDF) where an application receives messages from a 'customer leads' source, then needs to decide if it should take an internal action, or send to an external web service, or send an email. Why is this a good case for SI? Well, it seems to be a natural progression to move from an external messaging system to an "internal" one, but more importantly I think it comes down to it being an intuitive form of abstraction. You could do the same thing with a hierarchy of java packages and classes, but you won't get the same sense of flow of the system until you read through a pile of imperative java code. Being able to read the declarative configuration, or better yet, view a visualiation, I think will make the system easier to maintain down the road. In addition, this framework of components (routers, channels, etc), really force you to write simple classes that typically have few dependencies on one another. This means loosely coupled and easier to unit test. And sometimes we need to be *forced* to program this way because we either don't know any better, or we get lazy. --- ### Links #### Spring / Enterprise Development * [http://spring.io/projects/spring-integration](http://spring.io/projects/spring-integration) * [https://github.com/spring-projects/spring-integration](https://github.com/spring-projects/spring-integration) * [Very Simple Spring Integration Project](spring-integration.zip) * [Enterprise Integration Patterns](http://www.enterpriseintegrationpatterns.com) #### Training Courses * [VMWare Course Catalog](http://mylearn.vmware.com/portals/www/search/findcourse.cfm?ui=www_edu&category=catalog) * [ExitCertified Courses](http://www.exitcertified.com/training/) #### Presentation Preparation * [Remark - simple markdown-based presentation framework](https://github.com/gnab/remark) * [Draw.io - excellent free diagramming tool](https://www.draw.io)