What sets Camel apart from the pack

Camel introduces a few novel ideas into the integration space, which is why its authors decided to create Camel in the first place instead of using an existing framework. We’ll explore the rich set of Camel features throughout the book, but first let’s look at the main innovations behind Camel, listed in table 1. We’ll detail these features in the following sections.

Table 1 Noteworthy features in Camel

Routing and mediation	Payload agnostic	Enterprise integration patterns (EIPs)	Domain-specific language (DSL)
Modular and pluggable architecture	Automatic type converter system	70+ components	Real programming languages as DSLs
POJO model	Noninvasive	Lightweight and runnable anywhere	Java DSL, XML DSL, Scala DSL, Groovy DSL
Easy configuration using URLs	No XML needed	Maven tooling	Visual integration designer in Eclipse
Integrated in popular frameworks	Data mapping and transformation	Test Kit provided	OSGi ready

Table 1 lists 20 features that are highlights of Camel. In the following sections, we’ll take a closer look at the majority of these features.

Routing and mediation
The core feature of Camel is its stellar routing and mediation engine. When you are more acquainted with Camel, you’ll understand why. The Camel blog sphere has many testimonies from people getting started with Camel and finding it easy to route messages. Later, when we take our first Camel ride, you’ll start to see why.

Payload agnostic
Camel can route any kind of payload. You aren’t restricted to carrying XML payloads. This freedom means that you don’t have to transform your payload into a canonical format to facilitate routing.

Enterprise integration patterns
Although the integration problems are diverse, authors Gregor Hohpe and Bobby Woolf noticed that many problems and their solutions are quite similar. They catalogued them in their book Enterprise Integration Patterns, a must-read for every integration professional. If

you haven’t read it, we encourage you to do so. At the least, it will help you understand the Camel concepts faster and easier.
The enterprise integration patterns, or EIPs, are helpful not only because they provide a proven recipe for a given problem, but also because they help define and communicate the problem itself. Patterns have known semantics. The difference between using a pattern language and describing the problem at hand is similar to using spoken language rather than sign language. If you’ve ever visited a foreign country, you’ve probably experienced the difference.
Camel is heavily based on the EIPs. Although EIPs describe integration problems and solutions as well as provide a common vocabulary, the vocabulary isn’t formalized. Camel tries to close this gap and provides a language to describe the integration solution. There’s almost a one-to-one relation between the patterns described in Enterprise Integration Patterns and the Camel DSL.
The next topic that sets Camel apart from the pack is the use of domain-specific language.

Domain-specific language
Domain-specific language (DSL) is a major contribution of Camel to the integration space. As of now, a few other integration frameworks feature a DSL (note that some frameworks do allow you to use XML to describe routing rules), but unlike Camel their DSL is based on a custom language. Camel is unique because it offers multiple DSLs in regular programming languages such as Java, Scala, Groovy, and an XML variation.
The purpose of the DSL is to allow the developer to focus on the integration problem rather than the tool, the programming language. Although written mostly in Java, Camel does support and allows you to mix multiple programming languages, such as Java, XML, Groovy, Scala, Ruby, and Python. Each of these languages has its own strengths, and you may want to use them for different tasks. With as few constraints as possible, you have the freedom to build a solution your way.
Here are some examples of the DSL using different languages: Java DSL
from("file://acme/inbox").to("jms:queue:order");
XML DSL

Scala DSL
from "file://acme/inbox" -> "jms:queue:order"
These examples are real code that shows how easily we can route files from an inbox folder to a JMS queue.
A great benefit of the Camel DSLs is that there’s programming language underneath, so you can use all the existing tooling support such as code completion and compiler error detection.

We continue by looking at another Camel feature from table 1, which is all the components you get out of the box. After this, there are nine features left to explore, but they are all worth your while to understand.


Extensive component library
Camel provides an extensive component library, which ships with more than 70 components. To those you can add third-party components written by Camel end users and provided free of charge for other users.

Modular and pluggable architecture
Camel has a modular architecture, which allows any component to be seamless and easily embedded with Camel, regardless whether the component ships with Camel, is a third-party component, or is your own component. From Camel’s point of view, all components are the same and treated as equal.
Next we focus on another area where Camel innovates, the POJO (Plain Old Java Object) programming model.

POJO model

Beans (or POJO) are considered first-class citizens in Camel, and Camel strives to let you use beans anywhere and anytime in your integration projects. We understand that our end users can be trapped in situations where they must work around or use Java code to solve their integration problems. With Camel you’ll never be in a position where the framework locks you out. Throughout this book you’ll learn how important a role beans play with Camel.  You can even use beans for routing. 

Easy configuration
Camel adheres to convention concerning configuration, which minimizes configuration requirements. Camel also uses easy and intuitive URI configuration, which allows you to configure endpoints directly in routes.
For example, we could configure the file consumer to scan recursively in a subfolder and
include only a .txt file, as follows:
from("file://acme/inbox?recursive=true&include=*.txt") .to("jms:queue:order");
The next feature is one of the top favorites from the Camel community. After a while you should start wondering why it wasn’t provided in Java itself.

Automatic type converters
Camel has a built-in type-converter mechanism that ships with more than 150 type converters. The best part is that it works under the covers, so you don’t have to worry about it. You no longer need to configure type converter rules to go from byte arrays to strings, for example. The Camel API provides methods that accept a desired type as an argument, and Camel will provide the data as that type.
For example, to get a payload as a string you can do the following:
String payload = exchange.getIn().getBody(String.class);
The Camel components also leverage this feature; they can accept data in most types and convert the data into a type they’re capable of using. Camel is pluggable as well, so you can easily provide your own type converters.
We’re almost there! There are only four more features from table 1 that we want to explain.

Lightweight and runs anywhere
The Camel core is lightweight, with the camel-core.jar file being only 1 MB. It depends only on commons-logging.jar. Camel doesn’t set any preconditions or requirements for your application or platform. You can think of Camel as an API that’s another .jar file.
Camel isn’t a server or ESB but instead is designed to be embedded with your platform of choice. That allows you to embed Camel in any way you like it, such as a standalone application, web application, Spring application, J2EE application, JBI container, OSGi bundle, Java WebStart, or Google App engine. Camel makes your platform agile and capable of running inside your existing infrastructure.
In some situations your application need to communicate with another system. Because Camel provides a lot of existing transports and protocols and is lightweight and embeddable as well, you can use Camel as a client to simplify integration with that other system. Add the Camel .jars you need, and you can use Camel as an API in your application to integrate with the other system.
You can also use Camel to make your existing applications more open to the world. For instance, you can expose an endpoint over another protocol, opening it up to another set of clients, without the need for a hub in the middle. A common example is exposing legacy applications as web services.

Test Kit provided
Camel provides a Test Kit that makes it easier for you to test your own Camel applications. The same Test Kit is used extensively to test Camel itself, with more than 3500 unit tests. The Test Kit contains test-specific components, which, for example, can help you mock real endpoints. It also contains setup expectations, which Camel can use to determine whether an application satisfied the requirements or failed.

Eclipse users will be glad to know that Camel also provides tooling in this area. The rest of us can seek comfort in the Maven tooling that Camel provides.

Tooling
You can easily get started with Camel projects from Eclipse because Camel is listed in m2eclipse. Camel also ships with Maven plug-ins to easily run Camel.
Progress provides a commercial state-of-the-art visual integration designer running inside Eclipse, which we look at in chapter 10—yes, screenshots are included.
We’re nearly done; only one more to go.

OSGi ready
All Camel modules are OSGi (formerly known as the Open Services Gateway initiative) bundles and are ready to run in any OSGi container, such as Equinox, Felix, or Spring DM.
We made this last feature a short one because we know you must be dying to get your hands dirty and see the Camel in action. Don’t despair; you’ll soon get dirty and have a great and fun ride on the Camel. For now, you should take comfort in the fact that figure 1 and the DSL snippets we revealed are real Camel code.
At this time we want to ensure that you’re well prepared for Camel; we need to cover some Camel basics and the integration space in general. We’ll turn our attention to the architecture.

Camel’s architecture

We talked about the things that make Camel a great integration framework. Let’s now look at how Camel is designed to deliver on those items. We’ll be going over only the CamelContext, components, endpoints, processors, and DSL so that we can quickly get to a real example in the next section. A lot more is going on under the hood, but we’ll leave that discussion for the book! 

Camel in Action

Camel is an integration framework that aims to make your integration projects productive and fun. Although relatively young, about two years old at the time of this writing, Camel is already a mature open source project, available under the liberal Apache 2 license, and it has a strong community. Camel’s focus is on simplifying integration. We’re confident that by the time you finish reading these pages, you’ll appreciate Camel and add it to your “must have” list of tools.
At the core of the Camel framework is a routing engine, or more precisely a routing engine builder. It allows you to define your own routing rules, decide from which sources to accept messages, and determine how to process and send them to other destinations. Camel uses an integration language that allows you to define complex routing rules, akin to business processes.
One of the fundamental principles of Camel is that it makes no assumptions about the type of data you need to process. This is an important point, because it gives you, the developer, the opportunity to integrate any kind of system, without the need to convert your data to a canonical format.
Camel offers higher-level abstractions that allow you to interact with various systems using the same API regardless of the protocol or data type the systems are using. Camel components provide specific implementations of the API, targeting different protocols and data types. Out of the box, Camel comes with support for over 70 protocols and data types. Camel’s extensible and modular architecture allows you to implement and seamlessly plug in support for your own protocols, proprietary or not.
These architectural choices eliminate the need for unnecessary conversions and make Camel not only faster but also very lean. As a result, it’s suitable for embedding into other projects, for richer processing capabilities. Other open source projects such as Apache ServiceMix, and ActiveMQ already use Camel as the integration framework of choice. 

Why Node chose JavaScript

Node is programmed using JavaScript, a language familiar to web development professionals. JavaScript’s syntax and naming conventions are influenced by C and Java, but the language is higher-level, meaning it generally takes less lines of code in JavaScript to express the equivalent C or Java logic. Despite JavaScript’s comparative brevity, however, it is powerful. In its early years, JavaScript was disparaged due to incompatibilities between browser implementations and difficulty of debugging, but, as time went on, implementations improved and the expressiveness of the language gained appreciation.
JavaScript is excellent for specifying asynchronous logic because functions are “first-class objects.” This means the language allows functions themselves to be passed as function arguments, used as return values, and assigned to variables.
Callback functions are used to specify asynchronous logic. A callback is a function argument that contains a reference to program logic. Callbacks indicate an action to take when a programming event occurs or after intermediary logic is completed. JavaScript’s callback syntax is very elegant: either a function name or syntax- defining function logic can be passed as a callback.
JavaScript also has the advantage of being portable between the browser and the server. As long as any APIs accessed by logic are available on both the browser and the server, the same logic should run in either environment. Form validation, for example, is often duplicated on the client and the server. Why write the same code twice? Reusing logic on both the browser and the server enforces consistency and means not having to reinvent the wheel. It also means you have to maintain less code. Another benefit is you don’t have to mentally context-switch between languages when working on different parts of a web application. Staying in one language is likely to increase your productivity and make development more enjoyable.

Web applications are just the beginning
Node can develop much more than web applications. Node is also a good fit for designing servers, protocols, and command-line applications.
Server applications such as file transfer, email delivery, and instant messaging applications have traditionally been created in non-dynamic languages such as C, C++, and Java. C is a flexible and powerful language but is comparatively low level and can be challenging to learn. C++ significantly extends C but offers a cornucopia of language features that, if not used correctly, allow you to “shoot yourself in the foot” (the ability to redefine operators like “+” is one example). Java has fewer sharp edges than C++ but is more verbose than C and less flexible than dynamic languages.
As we mentioned earlier, Node breaks from tradition and leverages JavaScript, which makes it accessible to a large number of programmers. Given JavaScript’s strengths, if Node is widely adopted by server developers, the result will likely be quicker application development and increased diversity in server software.
Node versions of a variety of traditional server applications have already been written. Node-based DNS servers, web crawlers, message queue servers, and many other types of applications exist.
Node is also useful for exploring and implementing TCP/IP protocols. A recent example of improving the Web with new protocols is the WebSocket protocol. The Web’s first real-time applications used AJAX to exchange messages with the web server. AJAX uses HTTP as a transport mechanism to send messages back and forth to the server. Because HTTP requires a lot of communication overhead, AJAX’s performance is limited and both server and client have to do extra work. WebSocket was created in 2010 to provide an alternative: a lightweight, bidirectional protocol specifically focused on real-time textual communication.

The popular Socket.io project, which implements a robust Node-driven WebSocket server, is a good example of Node being used for protocol development.

The things that make Node perfect for server development also make Node a great candidate for the development of command-line interface (CLI) applications. Examples of common CLI applications include version control applications, database clients, and compilers. In addition to its networking API, Node offers access to functionality commonly needed by CLI applications: filesystem, process, and operating system functionality.

The Node community has created modules that make CLI application development easy by elegantly handling option and command parsing. The combination of the familiar JavaScript language with Node’s elegant APIs and easy CLI parsing has the potential to unleash the creativity of many who have, until now, only dabbled in CLI application creation.

Node can pretend to be a browser
Because Node is programmed in JavaScript, the language of the Web, another useful thing that Node can do more easily than other web frameworks is emulate web browser functionality. Emulating a web browser is useful for “web scraping” (parsing HTML from files or websites) and automated web application testing.
JSDOM, a Node community add-on, allows Node to emulate the web browser’s Document Object Model (DOM). The DOM is essential for web browser emulation, acting as a JavaScript-accessible interface to HTML/CSS content. By emulating the DOM, Node can read and write HTML in a virtual browser. Node can then take advantage of high- level JavaScript libraries, like JQuery, that allow high-level manipulation of the DOM.

Summary
We think any web developer who spends the time to explore Node is going to end up thinking of web development in a new way and will greatly enjoy themselves in the process. 

Asynchronous programming

Asynchronous programming
Asynchronous programming sounds mysterious, but the underlying concept is simple. For example, in traditional, synchronous programming, a program will initiate a request for a database record and then sit there and wait until the request is fulfilled. In asynchronous programming, however, the program will initiate a request to the database, specifying what should be done with the request’s result. The program will make a note of what is to be done then move on to the next task without waiting for the result to be returned. The specified result-handling logic is triggered only when the database request result returns. Asynchronous programs, in short, spend less time waiting around. In the context of programming, unnecessary waiting is referred to as “blocking.” Asynchronous logic and applications are referred to as “non-blocking.”
Asynchronous development is a bit like cooking a meal. If you were preparing a pasta dish, you wouldn’t wait until the water boiled to chop your vegetables and start frying them. You’d simply put water on the stove, turn on the heat, make a mental note of what needs to be done once the water boils, then immediately move on to chopping the vegetables. By the time the water is boiling, as shown in figure 1, you’d likely have the vegetables chopped and could fry them up as the pasta cooks.

Because the sequence of logic is more variable in asynchronous development, programming requires a different mindset. There are a number of techniques and third-party add-ons that can be employed to manage asynchronous execution at a higher level.

Until Node, web frameworks were largely based on languages without built-in support for asynchronous programming: Perl, PHP, Java, Python, and Ruby. While third-party libraries for these languages support event- driven programming, they also require additional knowledge, sometimes with considerable learning curves. If you’ve explored alternatives to Node, you’ll likely come to appreciate Node’s elegant approach.

The Node.js Framework

The Web has somewhat reached that level of capability and becomes richer and faster as it continues to evolve. Advances in browser technology (such as HTML, CSS3, and WebGL) hint at unprecedented levels of interface sophistication, while applications like Twitter provide a glimpse of the promise of real-time web applications. Still, implementing real-time web apps has been neither quick nor easy because conventional web development is hampered by the inelegance and scaling issues of established web frameworks.
The Node project takes a fresh approach to web application development, eliminating traditional barriers to speed and simplicity. Node focuses on asynchronous, also called event-driven, programming: a paradigm in which a developer describes how a web application should respond to specific events rather than describing application logic sequentially.
Node, programmed using JavaScript, leverages a number of existing open-source projects to make event- driven programming happen: most importantly, Marc Lehmann’s libev and libeio C libraries and Google’s V8 JavaScript engine, the latter created primarily to provide a fast JavaScript engine for Google’s Chrome browser but open-sourced for other projects as well. While the libev and libeio C libraries handle the intricacies of event-driven networking and input/output, V8, unlike other traditional JavaScript engines, compiles, rather than interprets, on the fly, without causing noticeable delays for users. This technique is referred to as Just in Time (JIT) compilation and is time tested, having been used by the Java and Smalltalk programming languages. At V8’s core is a virtual machine: an emulated abstraction of a computer that can be programmed the same regardless of what hardware it’s running on.
Node gained traction in the developer community in late 2009 when well-known Python programmer Simon Willison recognized its potential and became an evangelist. From that point, interest grew rapidly and the Node community began to take shape. Node’s community is now thriving and is well regarded for its friendly guidance of newcomers and collaboration and innovation: once a development need has been identified, the community generally self-organizes to take care of it.

Outlook 2011 for Mac - Auto Archiving Mail

This article explains how to create a rule to automatically archive email in Outlook 2011 for Mac.

Archiving in Outlook 2011 for Mac is achieved using rules to automatically copy over messages older than a set number of days into a local folder. These steps demonstrate how to automatically move mail out of your Exchange mailbox, and place it on your local computer's hard drive. Please keep in mind archived messages will not be viewable through Outlook Web App (OWA) because they are no longer stored on the Exchange server. Once this mail is moved out of the Exchange mailbox system, you will be the only one who has a copy.

Viewing Local Folders

Ensure you can see the On My Computer folder in Outlook 2011.

1. In Outlook 2011, click on the Outlook menu at the top of your screen, choose Preferences, then General.
2. Uncheck the box that says Hide On My Computer folders.
   


3. Close the General Preferences window.

Creating Local Folder to hold Archived Mail

1. Right-click (or ctrl-click) the On My Computer heading (probably at the bottom of your folder list) and choose New Folder.
   


2. Give your folder a name such as Archived Mail.

Creating Archiving Rule

1. Go to Tools > Rules.
   


2. With Exchange selected from the On My Computer section, click the + near the bottom of the window to create a new rule.
   


3. Name the rule from "untitled" to something meaningful like “180 Day, Auto Archive.”
   
4. In the section called When a new message arrives: define the criterion as "Date Received" + "is Greater than or equal to" + "180" ... days old to apply to messages older than 180 days (for a 6-month archive rule).
5. In the section called Do the Following: define the action as "Move message" + "Archived Mail (On My Computer)"
   Note: If you do not see the folder you wish to archive to, you will need to click on the drop-down arrow next to "Move Message" and select Choose Folder... then search for the archive folder. Under the folder name, the location "On My Computer" should be displayed.
6. Click the checkbox for Enabled.
7. Click OK.
   


8. Close the Rules window.

Running the Archiving Rule

1. To apply it to all mail in your inbox that is already six months or older, highlight the proper inbox, then select Message > Rules > 180 Day, Auto Archive. The first time this rule is run, it can take several minutes.
   
   
   Note: If you have arranged your inbox folder into sub-folders, you will need to run this rule on each folder individually.

Viewing the Archives

To access your archived mail, click on the folder you designated under the On My Computer section