Category: mulesoft

Rest (Representational State Transfer) webservice style is getting widespread acceptance across the Web fraternity. Industries and software communities are looking alternative to SOAP and WSDL based webservice. To compete with SOAP and WSDL based webservice REST need to support Descriptive Language based API.

Webservices APIs that follow and apply to the REST architectural constraints are called RESTful APIs. API descriptive language need to include blueprint of service, contract of service, metadata of service and documentation of service.

Many REST API descriptive language (API DL) are available today. Here I am discussing top 3 active API DL available for REST.

RAML — RAML is sponsored by MuleSoft. RAML Built on broadly used standards such as YAML and JSON, written in CoffeeScript, and can be used as a node.js. This is one of the very famous API DL and widely use with MuleSoft ESB. RAML support blueprint and contract of service design before you start your original coding. RAML API design approach is top-down. Writing spec for RAML is simple, human readable format.

SWAGGER – Sawwagger is sponsored by couple of companies like Apigee, Reverb and supported  with a large number active developer communities. Swaager format is based on JSON but they also support YAML. Swagger right now doesn’t support design before code. SWAGGER API design approach is bottom-up. Writing spec for SWAGGER  looks incomplete.

API Blueprint – API blueprint is sponsored by Apiary.API blueprint is based on Markdown. Markdown is a text-to-HTML conversion tool for web writers. There is no active developer community support for API Blueprint. API Blueprint right now doesn’t support design before code and its design approach is top-down. Writing spec for API Blueprint is simple and easy.

Mule ESB is one of the leading open sources ESB in market. Mule ESB product is maturing every day. Recently it released new version of Mule 3.6 and Anypoint studio January 2015 to support development for Mule 3.6 released. This release of mule adopts design-first and resource based approach. With this release user can quickly connect and design API based on a new HTTP connector.
Here is quick view of some of enhancement with Mule 3.6
1. New Http connector – New http connector is more resource centric, simpler to use and allow using RAML specs.
2. Shared Resources – New released support shared resources allow to share connector across multiple project and application. This is managed by new project inside Mule editor called Domain.
3. Continuous Integration enhancement — This release features a powerful new agent that provides access to MuleSoft’s runtime API for integrating with existing continuous integration processes and SDLC tools like Jenkins
4. New Support for Microsoft – Sharepoint and Dynamics CRM are two new connectors to integrate with Microsoft services.
5. AMQP 0.9 connector – This connector is now officially part of Mule soft connector. It is built on top of the previously-available community AMQP transport, and includes support for multi-channel receivers

Mule, JBPM and spring framework is one of the best combinations to implement SOA framework. These combinations are very famous among open source and easy to implement. Integration among this technology is always a challenge. I am adding some integration bullet point to make this integration easy.
These file are involved to integration among JBPM, spring and Mule ESB.
1) ApplicationContext.xml – spring framework
2) mule-config.xml – Mule ESB
3) jbpm.cfg.xml – JBPM file
4) All library for spring, JBPM and Mule ESB jar file
mule-config.xml
Add these lines into mule-config.xml file

	
<mule xmlns="http://www.mulesource.org/schema/mule/core/2.2"
     	 .....
      	xmlns:bpm="http://www.mulesource.org/schema/mule/bpm/2.2"
     	 xmlns:spring-context="http://www.springframework.org/schema/context"
     	 xmlns:spring="http://www.springframework.org/schema/beans"
    	  ...   >

	
<spring:beans>
       	 <spring:import resource="applicationContext.xml"/>
   	 </spring:beans>
	<spring:bean id="jbpm-ref" parent="jbpm" />

	
<bpm:connector name="jBpmConnector" bpms-ref="jbpm-ref" 
                  	 allowGlobalReceiver="true" allowGlobalDispatcher="true"
                 	  processIdField="requestId">
      	  <custom-exception-strategy class="com.vanrish.exception.ApplicationExceptionStrategy"/>
   	 <!—This is custom exception class based on your business logic --><
  	  </bpm:connector>

applicationContext.xml
This is spring specific file. So we are defining jbpm specific configuration to call from mule.

<bean id="jbpm" class="org.mule.transport.bpm.jbpm.JbpmImpl"  destroy-method="destroy">
		<property name="configuration">
			<value>classpath:jbpm.cfg.xml</value>
		</property>
		property name="processDefinitionsResources">
			<list>				
				<value>classpath:verifyAge.xml</value>
				.....
				<!-- Define JBPM specific process file -->
			</list>
		</property>
		<property name="createSchema">
			<value>false</value>
		</property>
	</bean>