Simplify Enterprise Integration with Apache Camel
•Descargar como PPT, PDF•
11 recomendaciones•4,166 vistas
This document provides an overview and introduction to Apache Camel, an open-source integration library. It discusses what integration is and why it is difficult. It then introduces Apache Camel as a lightweight integration library that uses enterprise integration patterns and components to provide routing, mediation, and transformation capabilities. The document provides examples of how to define integration logic in Camel using Java and XML domain-specific languages. It also discusses Camel's support for enterprise integration patterns, pre-built components, testing framework, and management capabilities.
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (20)
Similar a Simplify Enterprise Integration with Apache Camel
Similar a Simplify Enterprise Integration with Apache Camel (20)
Más de Kenneth Peeples
Más de Kenneth Peeples (19)
Último
Último (20)
Simplify Enterprise Integration with Apache Camel
- 1. Simplify Enterprise Integration With Apache Camel Christian Posta Principal Consultant and Architect 12/16/13 1
- 2. Agenda • • • • • 2 What is Integration? What is Apache Camel Why Apache Camel? Example Questions?
- 3. Your speaker Christian Posta Blog: http://christianposta.com/blog Twitter: @christianposta Email: christian@redhat.com ceposta@apache.org • Principal Consultant and Architect at Red Hat (FuseSource) • Based in Phoenix, AZ • Committer on Apache Camel, ActiveMQ, Apollo • PMC on ActiveMQ • Author: Essential Camel Components DZone Refcard 3
- 4. Poll: Estimate how long to implement the following usecase: Consume XML messages from a queue, call a SOAP webservice if the message is an “alert” message, store data to the file system Options: • Less than 1 day • A few Days • A few weeks • A few months • Cannot be done 4
- 8. Just use one computer. No integration needed. 8
- 9. Why is integration hard? • Off the shelf? Home Grown? Acquisition? • Platforms • Protocols / Data Formats • Data Formats • Timing • Organizational mismatch 9
- 13. Extract the heart of ESB • Protocol mediation • Routing • Transformation • EIPs • Start small, build up • Open Source • Community driven 13
- 14. Patterns FTW! • Common language!!!!! • Specific context • Forces at work • Concrete solution • Guidance • Other patterns… • 65 patterns 14
- 15. What is Apache Camel? 15 15
- 16. Proud parents of Camel 16
- 17. Apache Camel Apache Camel is an open-source, light-weight, integration library. Use Camel to integrate disparate systems that speak different protocols and data formats 17
- 18. Why the name Camel? • Can carry more weight that other beasts? • James fancied cigarettes? • A horse designed by committee? 18 Concise Application Messaging Exchange Language
- 19. What is Apache Camel? • Light-weight integration library • Enterprise Integration Patterns • Components • Domain Specific Language • Routing and Mediation (like an ESB?) • Runs in any container (or stand alone) 19
- 20. Not an ESB…per-se… • An integration library • • • Routing (content-based, dynamic, rules-engine…) Mediation (xformations, protocols, wire transports…) DSL • Can build an ESB (real ESB.. Not just box in the middle) • Many options based on Camel! • • • • 20 Fuse ESB / JBoss Fuse Apache ServiceMix (Karaf + Camel) Talend, wso2, others… Not tied to vendor lock-in and commercial licenses!
- 21. Very popular • Used at top companies in finance, shipping, retail/e-retail, health care, airline reservations, etc • E*Trade: http://goo.gl/FDqgpV • • Sabre: http://goo.gl/RrWcQ5 21 CERN: http://goo.gl/vEO7zR
- 22. Open source • • • Apache Software Foundation ASL v 2.0 Licensed Vibrant community • • 22 Jira, mailing list, github Lots of contributions! Check out the components!
- 24. Quick Example File System 24 Message Oriented Middleware
- 28. Quick Example isWidget = xpath(“/quote/product = ‘widget’”); from(A) .filter(isWidget). to(B) 28
- 30. Pipes and Filters • Step by Step – “Processors” in Camel terminology • Complex processing – “Routes” • Flexible • Testing • Reuse 30
- 31. Camel Routes • Defined in Java, XML, Scala, Groovy • Step by step processing of a message: • Consumer – Listen for incoming message • Zero or more “filters” or Processors • Producer – Send outgoing message • Number of processing filters, or “Processors” in Camel-speak • EIPs • Tranform, redirect, enrich 31
- 32. Domain Specific Language • Domain specific (integration) • Used to build and describe Camel Routes • Embedded within a general programming language • Java, Spring XML, Scala, Groovy • Take advantage of existing tools • Fluent builders (builder pattern…) • 32 from(“..”).enrich(“…”).filter(“..”).to(“…”);
- 33. Java DSL public class OrderProcessorRouteBuilder extends RouteBuilder { @Override public void configure() throws Exception { } } from(“activemq:orders”) .choice() .when(header(“customer-rating”).isEqualTo(“gold”)) .to(“ibmmq:topic:specialCustomer”) .otherwise() .to(“ftp://user@host/orders/regularCustomers”) .end() .log(“received new order ${body.orderId}”) .to(“ibatis:storeOrder?statementType=Insert”); 33
- 34. Spring XML DSL <route id=“processOrders”> <from uri=“activemq:orders”/> <choice> <when> <simple>${header.customer-rating} == ‘gold’</simple> <to uri=“ibmmq:topic:specialCustomer”> </when> <otherwise> <to uri=“ftp://user@host/orders/regularCustomers” /> </otherwise> </choice> <log message=“received new order ${body.orderId}”/> <to uri=“ibatis:storeOrder?statementType=Insert”/> </route> 34
- 35. Enterprise Integration Patterns • Message Routing • Transformation • Aggregation • Splitting • Resequencer • Routing Slip • Enricher • All 65 from the book! 35
- 36. Components • Prepackaged bits of code • Highly configurable • Maximum interoperability • Used to build “Adapters” to existing systems • Don’t reinvent the wheel and end up with a box 36
- 37. Components http://camel.apache.org/components.html • ActiveMQ, Websphere, Weblogic (JMS) • GMail • AMQP • HTTP • ATOM feeds • IRC • AWS (S3, SQS, SNS, others) • jclouds • Bean • JDBC • Cache (EHCache) • Jetty • CXF (JAX-WS, JAX-RS) • Twitter • EJB • MQTT • Drools • MyBatis • File • JPA • FTP • Spring Integration • Google App Engine • Spring Web Services 37 To see list of all components!!
- 38. Components • URI format: • scheme:localPart[?options] from(“aws-sqs://demo?defaultVisibilityTimeout=2”) • scheme: identifies the “component” • localPart: specific to the component • options: is a list of name-value pairs • Creates endpoints based on configuration • Route endpoint “factories” • Integrate with Camel Routes by creating producer/consumer endpoints 38
- 39. Another Example public class MyExampleRouteBuilder extends RouteBuilder { @Override public void configure() throws Exception { from(“aws-sqs://demo?defaultVisibilityTimeout=2”) .setHeader(“type”).jsonpath(“$[‘type’]”) .filter(simple(“${header.type} == ‘login’”) } .to(“jms:quote”); } 39
- 40. Test Framework • Powerful way to test your Camel routes • http://camel.apache.org/mock.html • Uses Mocks • Mocks vs Stubs? • http://martinfowler.com/articles/mocksArentStubs.html • Provides declarative testing mechanism • Declare • Test • Assert 40
- 42. Developer Tooling Support Fuse IDE 42
- 43. JBoss Fuse (aka Fuse ESB) Integrate Everything! 43
- 44. More info on JBoss Fuse… http://www.jboss.org/products/fuse https://www.redhat.com/products/jbossenterprisemiddleware/fuse/ 44
- 45. Live Demo 45 45
- 46. Resources 46 46
- 48. Professional Training Camel Development with Red Hat JBoss Fuse (Online Training) http://www.redhat.com/training/courses/jb421r/ Red Hat JBoss A-MQ Development and Deployment (Online Training) https://www.redhat.com/training/courses/jb437r/ Red Hat Certificate of Expertise in Camel Development http://www.redhat.com/training/certifications/jbcd-cameldevelopment/ 48
- 49. Dzone Refcardz REFCARDZ • Camel Essential Components • http://refcardz.dzone.com/refcardz/essential-camel-components • Essential EIP with Apache Camel • http://refcardz.dzone.com/refcardz/enterprise-integration 49
- 50. Apache Community • http://camel.apache.org • Mailing list: users@camel.apache.org • Nabble Archive: http://camel.465427.n5.nabble.com/Camel-Users- f465428.html • Source code: https://git-wip-us.apache.org/repos/asf?p=camel.git • Blogs, Articles, Examples • http://www.davsclaus.com • http://www.christianposta.com/blog • http://www.ossmentor.com/ • http://camel.apache.org/articles.html • http://camel.apache.org/user-stories.html • http://camel.apache.org/user-stories.html 50
- 54. Questions 54
Notas del editor
- Main points about “who I am and what I do” I am active in the open-source community, committer/PMC I work as a consultant @ Red Hat after the FuseSource aqcuisition. FS – founded by James, Rob, Hiram, etc. FuseSource was the commercial support company behind Apache Camel, ActiveMQ, CXF, and ServiceMix. Companies don’t usually like to base their middleware stack around software that does not have a commercial backing… mailing lists are not their preferred mode of support We have since been merged in with the Jboss middleware group, and for the most part our integration technology has not only been kept in tact and continued as it is (because it’s so awesome) but it’s even been adopted by other parts of the middleware stack. Merge this slide and next slide… Say some things about FuseSource + Red Hat here… and what I do… So I started out working for FuseSource about a year and a half ago. Fuse Source was a open-source subscription company built around the integration projects at Apache, specifically Apache ActiveMQ, Camel, ServiceMix, and CXF. Basically these projects are best-of-breed and highly adopted freely by community users and used for mission critical infrastructures when building out SOA and other distributed integrations. The thing is, big companies who invest millions of dollars into their businesses aren’t willing to accept using a mailing list and irc for production support, aka when shit hits the fan, they need to be able to rely on some strong partners who would be able to help them out. That’s were fuse source, fit into that picture. It was started by the guys that co-founded the projects, and they were able to build up an amazing set of support engineers and consultancy teams. Along the way, they hired up a lot of the committers on each of the respective projects, and put together professional documentation, on-site and virtual training, an annual conference devoted specifically to these technologies, as well as and most importantly support subscriptions for both production and dev support. We were officially welcomed into the Jboss Redhat family almost exactly a year ago and the spirit of open-source itnegration and SOA lives on under the RedHat umbrella and in complement of the existing Jboss offerings including EAP, Drools/BRMS, and jBPM, etc.
- Integration is about getting multiple disparate systems, pieces of software to be able to work together to achieve some business function. Kinda like putting a puzzle together, Blue pieces, red pieces, ec.. To make a beautiful collage of puzzle pieces…. Well, actually that would be too nice. A puzzle has pieces that are desinged to fit together. Disparate software systems are usually not designed specifically for integration or to work together. But never the less, business base a lot of their cash flow and profitability on integration. These systems need to be able to work together, be agile, loosly coupled, and reliable.
- Really, It’s like taking a heaping pile of broken glass, throwing some glue in there, and hoping to create a window. That’s what integration is…
- Integration would be easy if there was just ONE machine. And actually… back in the 60s/70s, that’s kinda what you had… a mainframe that did everything. Transactions, databases, virtualizations, security, etc, etc… all lived on the mainframe… problem with that is how do you scale up one box? Sure IBM will sell you whatever you have the money for, and that’s the problem. Only companies will huge reserves of capital can afford to use these machines. Even though the drawbacks of scalability and integration still exist…. But with the advent of the PC or commodity machines, distributed systems are now used to solve the scalability issue.. and these systems are supposed to work together to achieve some common business function
- Made up of different systems, different vintages, platforms… .NET, Java, Mainframe, Corba, EJB,Web Services, etc, etc.
- Hexagon! Expensive… commercial… at the time (late 90sish) no opensource options….
- Rectangle! Gartner… CPU, memory controller, front side bus, disk IO,.. Etc… like that right?? Not really… still a rectangle box….
- More organic, distributed, life of it’s own… but still coordinated…and reliable.. Controlled chaos? But camel IS NOT AN ESB… camel is not the previous picture… it’s not this picture.. It actually would live on one of these nodes let’s say… or on the client.. Or both…
- A few years latter, James Strachan who had already been working on solutions in the integration space, went out drinking one night and James came up with this idea to create a library that implements the patterns. And this was fairly unique to be able to “componentize” or package up a “design pattern”… you don’t see libraries of “observer” pattern or “strategy” pattern from the GoF book… but in this case the model worked out to lend itself to this… The reason being the composition model…. GoF wrote OO patterns.. OO is a much richer compisitional model…pipes and filters is VERY simple… so much more straight forwrad way of componentizing… Excluse the typos.. Gotta little wine in me….
- ASF: will always be around… very community driven, will never be taken over by one company, etc, etc. ASL is one of the most liberal licenses.. Yoy can use in commercial projects w/out contribuing back, or disclosing source, etc, etc.
- Make the use case more engaging
- The model it’s built on and that is exposed to the developers is the pipes and filters model…
- Show a quick example…