Essential Camel Components

Editor's Notes

• #8: ESB product = something you buy and magically all of your enterprise systems can “integrate” with each otherCamel isn’t a container like tomcat, or websphere. You don’t deploy code to Camel. You deploy your code along with Camel to a Java container (or stand alone if desired)Proprietary, closed source = community driven… “free” if you will, but care must be taken to differentiate between “free as in beer” and “free as in speech” Liberal licensing, use, can package in your own products, can make changes without having to contribute back, input from everyone, etc
• #9: Integration is necessary in just about any IT shop
• #10: One thing any good IT department will tell you is that Integration is Hard!You have to deal with different “system vintages” both off the shelf and in house developed… Vintages = Mainframe, ETL, File based integration EAI = HubsIn house products = J2EE, EJB
• #11: Windows based (.NET), Java on Linux, Web based, Fat client, Mobile!!HTTP, messaging, CORBA, COM/DCOM, EJB, RMI, custom TCP/IPPlan XML or sub categories: MISMO, Accord, SOAPJSON, Protocol Buffers, Fixed-file formats (COBOL mainframe files), HL7, CSV, EDITiming = synchronous calls over a network… either party in the integration must be availableBut that becomes difficult because often times the systems to be integrated are aligned with business units or IT units.. You don’t have control over the systems you’re integrating with, so communication between groups is crucial.. And establishing coherent communication between groups always seems to be difficult to accomplish
• #12: Patterns to the rescue right?Well after the GoF book, seems like patterns are a “trend” or “hype” more than anything useful. If you do a search for software patterns on Amazon, you’re gonna come back with a large list of results, some useful some not. Patterns are useful if they can package up some useful concepts and convey them intelligently to other developers. That’s the role of patterns, to convey knowledge. Typically, they describe a specific context, go into the different forces that apply to any solution or alternative solutions, describe a concrete solution and what the trade-offs are, and are ultimately to be used for guidance. The EIP book does exactly that by formalizing 65 patterns often found when doing enterprise integration
• #13: Lightweight in that it’s not an overblown, overhyped, ESB product… it’s just a set of a few java jar files that can plug into any java projectOpen source! Apache Licensed, vibrant community 700 subscribers, 45 messages per day, 24 committers, excellent response time from JIRA and mailing lists.Mediation? Router?resolve/negotiate differences between the two so they can exchange dataGives you an out of the box implementation for the EIPs described in Gregor’s bookOver 130 pre-packaged “components” for interfacing with different protocols and third-party systemsRuns in any container!
• #15: Let’s take a look at a very simple integration scenario where you would like to read files from a file system and send them to a messaging system, but filter out only certain ones. Let’s only send Widget Quotes to the messaging system, and not Gadget quotes… What would something like that look like in Camel? Well, first let’s conceptualize…
• #16: In plan language, we’re going to be taking “From a file system”, Filtering out the Gadgets, and “Sending to a messaging system”
• #17: We can start to formalize it using some java methods… where we want to go from A and filter on a predicate, then send to B
• #18: Now we are pretty close to what Camel’s DSL looks like…
• #19: And now we have a camel route…The key here is that Camel routes are intended to be easy to read and comprehend. Integration is difficult, so let’s start by making certain things clear.
• #20: This is actual java code. Notice the readability of the code as it expresses exactly what it’s doing.
• #21: A DSL is a special purpose language for describing problem or solutions more clearly than a general purpose language (or programming language) using syntax and grammar applicable to a given domain.Examples include SQL, regex or Mathematica (for symbolic math), excel macros, etc
• #22: Camel routes are built using a “Pipes and Filter” model, where smaller, well defined “filters” are connected up by “pipes” to perform a sequence of processing steps according to the business rules.For example, consider a business that accepts new orders. A requirement of the order is that it’s encrypted so nobody else can snoop it, it must contain authentication credentials so that only approved customers can place orders, and it must also be able to track and eliminate duplicate orders. We could have one piece of code that does all of this, but that would be quite inflexible. What happens if there needs to be a change and we need to check inventory before sending to “clean orders”? Using pipes and filtesr allows us to keep the filters small for flexibility, easy testing, and potential reuse. Camel routes follow this mentality.
• #23: Routes are described as a series of steps that an incoming message can travel.There must an entry point to the route, and that’s where the notion of “consumers” comes in. Consumers are endpoints that Listen for incoming messages. This can be a file endpoint, jms, web service, etc. Then the message is processed by zero or more “filters”And if desired, the message can be sent along to another system using a Producer endpoint…Note the slight difference in terminology here… in web services, a provider is the web service and a consumer is the client invoking the web service. But in the case of Camel, a consumer is actually acting more like a “provider” of messages to a route. Wherease a producer is “sending messages”You can have any number of filters…
• #24: import org.apache.camel.builder.RouteBuilder;/** * A Camel Java DSL Router */public class MyRouteBuilder extends RouteBuilder { /** * Let's configure the Camel routing rules using Java code... */ public void configure() { // here is a sample which processes the input files // (leaving them in place - see the 'noop' flag) // then performs content based routing on the message using XPath from("file:src/data?noop=true") .choice() .when(xpath("/person/city = 'London'")) .to("file:target/messages/uk") .otherwise() .to("file:target/messages/others"); }}
• #25: import org.apache.camel.builder.RouteBuilder;/** * A Camel Java DSL Router */public class MyRouteBuilder extends RouteBuilder { /** * Let's configure the Camel routing rules using Java code... */ public void configure() { // here is a sample which processes the input files // (leaving them in place - see the 'noop' flag) // then performs content based routing on the message using XPath from("file:src/data?noop=true") .choice() .when(xpath("/person/city = 'London'")) .to("file:target/messages/uk") .otherwise() .to("file:target/messages/others"); }}
• #26: What is a component?A component is a prepackaged extension to camel that allows you to communicate with external systems. Primary extension pointYou use it by specifying which component to use, which context (consumer or producer) you want to use it in, and then configure it specifically for what your integration needs are. The remainder of these webinar will introduce 6 often-used components and give an idea of how to use them and configure them. Camel has over 130 components, some of which are listed on the next slide…
• #27: It’s a URI that describes an endpoint. Endpoints can be used to bring messages into a camel route (consumer) or send messages out from a camel route (producer). The URI has three parts a scheme which describes a component which is basically the “type” of endpointLocalpart is usually a name or path whos context (what it really means) is specific to the componentAnd options, which lets you configure a specific component.
• #28: This is by no means an exhaustive list… Please see the components URL
• #30: These are the components I’ll cover in this webinar.These are not listed in any kind of meaningful order. They are the components that I’ve seen used quite a bit in integration routes. There are plenty more that I wish we could have talked about, including jetty, http, twitter, drools, twitter, Amazon Web Services, etc.
• #31: Let’s start by taking a look at a component that allows you to integrate with file based solutions….
• #32: Interestingly enough as it is, file based integrations are still around, and will probably not go away for some time. One of the tenants of integration is that there will be different protocols and integration should be flexible enough to deal with them. This is a good example. Systems such as mainframes or other nightly batch applications tend to expect files as input. Well, there are many good file libraries out there, you could probably write a lot of file integration solutions yourself. But after doing this enough times, you’ll find that writing and reading files is largely very similar between different processes… wouldn’t you want something a little more “out of the box”? Well, that’s what you get with Camel’s components.
• #33: Think for a moment about how long it would take you to write an application that does the following…An hour? A few hours?At a recent gig I was on with a large financial company, the answer was an astounding 200+ hours (including unit testing, build processes, and management approval, etc). This simple route with camel gives an idea of how packaged components can provide out of the box functionality to make your development a little easier
• #34: So the File Component allows you to read or write files from and to the file system. You specify the endpoint using absolute or relative paths.Notice the URIs are as defined in the previous slide… the file component prefix followed by a path on the file system and followed by options to configure the specifics of the endpoint…
• #35: By default, the file component will read all files in a given path… for each file, it will create a new message exchange that will be processed by the camel route. Keep in mind that any file or directory starting with the “.” character are ignored!File component is very configurable, as we will see some options in the next slide.
• #37: A couple things to keep in mind when working with the file component are the default behaviors…
• #38: Read a relative location named “inbox”, move a file to the “inprogress’ folder, process the message (sends to activeMQ) then move to .done folderDirect invocation sending a message to a file named report.txtPick up files in data folder, exclude any file starting with a _ underscore… then send the message to handleData beanSort files
• #39: Let’s take a look at a component that allows you to work directly with Java Beans
• #40: The bean component allows you to connect in any Plain Old Java Object into your route processing… Specifically, this component implements the “Service Activator” pattern from the EIP book which allows you to connect existing services (usually synchronous) to an integration route (could be asynchronous or synchronous). If you’re not familiar with the SA pattern, I encourage you to look it up, or look up any of the patterns that you come across using Camel. This should give you a good foundation for how to use Camel’s different component and EIP implementations.
• #41: So specifically, the bean component allows you to invoke methods on your own, possibly existing, java beans. The endpoint definition follows the same pattern as all of the other components… bean: beanId and then some options.. Although not very many options for this componentCamel will automatically try to bind the parameters of the POJO method to elements of the message or message exchange…
• #42: You can invoke the bean component using it as an endpoint in the “to” method… or take advantage of a more expressive Method called “bean”Either you can have the bean available in the registry (spring, jndi, osgi, etc), or you can have the route lazy create it when the route is invoked. Note, this will not create a new bean each time the route is run.. It will create it once and cache it.
• #43: Continuing the example… You have a POJO class called CreditService… Camel will automatically bind the params, but in this case we’re being explicit by binding to a path in the XML payload. This expects the payload to be XML…Define the bean in spring with a bean ID of “enrich service”Then can use as an endpoint
• #44: What if you don’t specify a method name??Camel is smart enough to try and figure out which method to use… though it’s probably best to specify a method name…
• #45: How are the parameters bound? Magically of course, but there are some well-known types that will automatically be bound if used as parameters
• #46: These are not listed in any kind of meaningful order. They are the components that I’ve seen used quite a bit in integration routes. There are plenty more that I wish we could have talked about, including jetty, http, twitter, drools, twitter, Amazon Web Services, etc.
• #47: It’s a good practice to log your exchanges as they go through critical parts of a route. Under the covers, the Log Component uses SLF4J which itself delegates to log4j, java util logging, logback, or some other supported logging facility.Specifically, the log component logs interesting parts of an exchange, like headers, body, body type, properties, etc.
• #48: Some questions may come up about what to use as far as the Log Component or the Log DSL. Just like Bean Component could be used as an endpoint or in a DSL method, Log offers the same options. Use the log component to log coarse parts of an exchange, or the entire exchange.Use the log dsl method to customize the log method and include simple expressionsBoth allow yout specify the logging level
• #52: These are not listed in any kind of meaningful order. They are the components that I’ve seen used quite a bit in integration routes. There are plenty more that I wish we could have talked about, including jetty, http, twitter, drools, twitter, Amazon Web Services, etc.
• #53: The JMS component does not belong to camel-core.. The reason why all components aren’t included is because each of these external components depends on other libraries and the classpath would become quite polluted with all of these extra dependencies and transitive dependencies…But it’s simple to add the components that you’re interested in using
• #54: You can use JMS component to connect to JMS providers such as ActiveMQ, HornetQ, or commercial providers such as Websphere or Weblogic. For AMQP or MQTT protocols, there are corresponding camel components. You could connect up to ActiveMQ with either of those components as well.The URI will be just like other components, except that when you declare the JMS provider you’re going to use, you might want to use a “component” name that matches your provider. Doing so is as simple as naming your spring bean with the name you want to use in your route. For example…
• #55: By default, you don’t need to specify whether you’re listening or sending to a Queue because that’s implicit if it’s left out.If you want to send to a topic, you specify that after the component name
• #56: One of the things to note when using the JMS component is to cache your connections, and consumers where possible. Doing so for durable subscribers is not recommended because the JMS spec disallows multiple connections with the same clientId and durable subscription name…But to set it up correctly, instantiate a new PooledConnection Factory… by default the cache strategy will be CACHE_AUTO which would be fine because it will select CONSUMER under the covers, but I like to be explicit with this setting to make sure there is no confusion. Also, when switching to use transactions, the TX manager will use its own cache setting, and this way it will be set correctly.
• #57: Please please take a look at the component documentation for JMS… there are many configuration options for tweaking the endpoint…
• #60: The JMS component does not belong to camel-core.. The reason why all components aren’t included is because each of these external components depends on other libraries and the classpath would become quite polluted with all of these extra dependencies and transitive dependencies…But it’s simple to add the components that you’re interested in using
• #61: Dealing with SOAP web services can be a pain in the ass, but CXF really simplifies this task. Furthermore, integrating with CXF becomes much easier with Camel. Just take note of the nomenclature differencesThere are two different ways to use the CXF component: bean or address style
• #62: Let’s take a look at how to configure the cxf endpoint for the bean style of integrating with CXFAs consumer Factor out how message payloads are received into soap or rest.
• #63: CXF uses WSDL to abstract away service details.Note the difference in what the “serviceClass” signifies… In CXF it depends on whether we’re a client or server.In Camel, it’s always the interface. This is because when running as a “server” or exposing it, we want camel route to provide the implementation, not a CXF impl classUsing the JAX-WS annotations helps reduce some of the XML properties that need to be configured.
• #64: You could also use the address style of configuring the CXF component, but there are some drawbacks.You can already see it’s more verbose, kinda clutters up the rotue, and cannot configure CXF bus or interceptor details this way.Use for simple routes or for testing…
• #65: Cant talk about CXF integration without mentioning how the payloads of a SOAP message are dealt with. For small payloads, you can consider using the POJO approach where Camel can automatically convert to your domain objects.But often times you’ll need to operate on the xml in a less resource-intenstive way… use PAYLOAD to access the soap body, or use MESSAGE for the raw input stream. You could use something like MESSAGE to send large messages, or messages with attachments. None of the extra CXF processing happens on MESSAGE data types.Note the difference in configuration…
• #75: [email protected]