Mule Core Concepts

Let's discover the core concepts that sit at the heart of this ESB.
Model

The first logical layer is the model layer. A Mule model represents the run-time environment that hosts services. It defines the behavior of Mule when processing requests handled by these services.
Consequently, the model that the Mule instance would host would establish a runtime environment optimized for asynchronous processing of messages, as no synchronous reply is expected anywhere in the overall message processing chain.
Service

A Mule service is composed of all the Mule entities involved in processing particular requests in predefined manners. To come to life, a service is defined by a specific configuration. This configuration determines the different ele-ments, from the different layers of responsibility, that will be mobilized to process the requests that it'll be open to receive. Depending on the type of input channel it uses, a service may or may not be publicly accessible outside of the ESB.
For the time it gets handled by a service, a request is associated with a session object. As its name suggests, this object carries all the necessary context for the pro-cessing of a message while it transits through the service.
Transports

The transport layer is in charge of receiving or sending messages. This is why it's involved with both inbound and outbound communications.
A transport manifests itself in the configuration by the following elements: connec-tors, endpoints and transformers.

1. Connectors:

A connector is in charge of controlling the usage of a particular protocol. It's config-ured with parameters that are specific to this protocol and holds any state that can be shared with the underlying entities in charge of the actual communications.
For example, the FileConnector can read and write file system files.
Configuring connectors:
FileConnector:

<file:connector name="FileConnector" streaming="false" pollingFrequency="1000">
    <file:expression-filename-parser/>
</file:connector>

JDBC Connector

<jdbc:connector name="jdbcConnector" dataSource-ref="dataSource">
      <jdbc:query key="statsInsert" value="insert into alerts values
    (0, 123, 'Sai', 'Shirdi')"/>
</jdbc:connector>

HTTP Connector

<http:connector name="HttpConnector"
proxyHostname="${proxyHostname}" proxyPort=="${proxyPort}" proxyUsername="${proxyUsername}" 
		proxyPassword="${proxyPassword}"/>

STDIO Connector

<stdio:connector name="SystemStreamConnector" promptMessage="Please enter something:" 
		messageDelayTime="1000" />

JMS Connector

<jms:activemq-connector name="jmsQueueConnector" specification="1.0.2b"
		brokerURL="tcp://localhost:61616" />

2. Endpoints:

Inbound and outbound endpoints exist in the context of a particular service and represent the expected entry and exit points for messages, respectively. These end-points are defined in the inbound and outbound routers. It's also possible to define an inbound endpoint in a response router. In that case, the inbound endpoint acts as a response endpoint where asynchronous replies will be consolidated before the service returns its own response.
Global endpoints can be considered abstract entities that get reified only when referenced in the context of a service: as such, they're a convenient way to share common configuration attributes.

3. Transformer:

A transformer optionally changes incoming or outgoing messages in some way.This is usually done to make the message format useable by a downstream function
For examples, the ByteArrayToString transformer converts byte arrays into String objects.If we want our own transformers to convert input we can write our own java and we can call from the mule.
We can implement custom java transformer by extends AbstractTransformer and AbstractMessageAwareTransformer.
AbstractTransformer is a normal Transformer, it will carry only payload in the sense input/result from before execution.
AbstractMessageAwareTransformer is a special transformer, It will carry payload, messahe properties of mule and alo details regarding exception.

4. Routers:

Routers play a crucial role in controlling the trajectory a message will follow when it transits in Mule. They're the gatekeepers of the endpoints of a service. In fact, they act like railroad switches, taking care of keeping messages on the right succession of tracks so they can reach their intended destinations.
A router is the object that does something with messages once they have been received by a connector, or prior to being sent out by the connector.
pass-through-router: Input will pass as it is to outbound from inbound. Single service will be available.
filtering-router: input will pass based on condition it's like filtering input. Multiple Services will be available.
chaining-router: Every statement will pick up by procedure functionality, nothing but there is no condition after finishing one service it will go to the next service. Multiple Services will be available.
etc...

5. Filter:

A filter optionally filters incoming or outgoing messages that are coming into or going out from a connector.
For example, the File Provider comes with a FilenameWildcardFilter that restricts which files are read by the connector based on file name patterns. For example only files with the .xml extension can be routed.
Note: writing condition is filtering-router and way of condition is filter. Based on filter, service will be picking up by filtering-router.

6. Components:

Components are usually business objects. They are components that execute business logic on an incoming event. Components are standard JavaBeans (containers)
There is no Mule-specific code in components, it is a java class to implement business logic especially.
To Install mule follow steps from below mulesoft link
http://www.mulesoft.org/documentation/display/MULE3INSTALL/Hello,+Mule!