Projects tagged ‘esb’ and ‘mule’

Mule is an ESB (Enterprise Service Bus) and integration platform. It is a scalable, highly distributable object broker that can seamlessly handle interactions with services and applications using disparate transport and messaging technologies.

jEmbedded- SOC Container (Service Oriented Container) focused on managing and composing Services and other elements (as pojos, components etc...). - Create and test faster your Integration/SOA/RIA ... [More] prototypes or applications composing work flows of services in a graphical way (using the native jBPM support) or just using annotations and the dynamic creation/injection of services (+ any of the supplied services). - Integrated with GWT/Spring MVC to create SOC-RIA applications. - Introducing the Gwlets/Widglets components, similar in concept to portlets/applets but using GWT widgets and embedded services. Have a look at the integration/esb case study using jEmbedded, GWT/Gwlets, jBPM, Emmbeded Database, Mule, JMS, Spring/Spring MVC to have an idea of what you can do: http://code.google.com/p/jembedded/wiki/jECaseStudy FeaturesDynamic injection: create/compose services just with an interface + annotations (no impl needed). Compose your service workflows graphically using the jBPM native support. Implement services using Java or Ruby. 100% Annotation based configuration (plus .properties files for externalization). Can be used as a standalone container, in a web environment or integrated with other containers. Integration testing: http://code.google.com/p/jembedded/wiki/UserGuide. Monitor and manage the services through JMX (status, start, stop...). Spring native support (Spring/Spring MVC). Maven plugin. Several embedded services are provided out of the box and ready to use: - Embedded-database (HSQLDB/ Derby). - Mule-Service and client (native support + validation-service). - jBPM-Service (native support). - JMSBroker-Service and client (ActiveMQ). - CXFServer-Service (Apache CXF webservices). - GWT-Service (Google Web Toolkit integration + SpringMVC). - GWlet-Service (introducing the gwlets and widglets components). - Spring-Service (native support + supporting services: i18n, validation, hibernate/jpa orm and mvc). - Jetty-Service and Http-Client. - Jdbc-Service (HSQLDB / Derby). - Tomcat-Service and Http-Client. - Jasper-Service (compiler). - jRuby-Service. - Validation-Service (annotation based, oval). - Dao-Service (ORM). - Hibernate-Service. - Agent-Service. - JMX-Service. - Rules-Service (Drools). - Properties Service. [Less]

Overview - What are Mulefaces?The goal of the MuleFaces project is provide developers with a modular API for building SOA oriented applications and to provide end users the ability to compose and ... [More] deploy such applications easily within an ESB environment. Specifically the goals of the MuleFaces project are: RAD framework for building SOA GUI Applications in a modular and extensible fashion - from simple wizards, to applets, and all the way to full blown applications GUI Applications should have easy access to invoke SOA services and return simple JavaBeans or JSON objects back to an AJAX client Create jobs with configurable workflows that can be scheduled and run on the back-end with easy access to SOA/ESB services. The essential building blocks of a MuleFace are the !MFaceServlet and the !MFaceApplet. A MuleFace can be composed of one or both of these (Servlet and/or Applet). The !MFaceServlet provides the API for implementing and executing backend services within a workflow chain. The !MFaceApplet provides the abstraction for building AJAX Web enabled applications that can do everything from editing/customizing the input JavaBeans that are consumed by the !MFaceServlet to building full blown GUI applications that invoke services using ESB/SOA API. Workflow ProcessingThe inputs and outputs of a MuleFace are defined as JavaBeans. A MFaceServlet consumes a JavaBean as input and returns a JavaBean as output. These input and output JavaBeans can have customizers/viewers that can edit and render the contents of the input/output JavaBeans. These MuleFaces can then be composed and packaged together into back-end jobs and/or GUI applications. As a job they can be scheduled and run as a normal job would be run. As an application they can be published and presented to users as applications that can be edited and executed. Also, the requirement is that MuleFaces be deployed and loaded dynamically within their hosting container, without requiring server restarts. The GUI and server code that makes up a MuleFace is bundled and packed in a JAR called a MAR (Mulefaces ARchive). The specification defines a life cycle for the execution of one or more MuleFaces that are chained together to execute a single piece of logic. Individual MuleFaces can pass JavaBeans to each other during the execute of the workflow (a chain of MuleFaces). The output JavaBean of one MuleFace can serve as the input to another MuleFace. This is done through a mapping specification to allow the end user the ability to configure which properties of one particular output JavaBean get mapped to which corresponding properties of another input JavaBean. MuleFaces provide easy access to Mule services and can easily live within Mule Containers and/or interface and communicate with remote and local Mule services and providers. MuleFaces also leverages the GWT framework which serves the basis for its Web UI extensibility and application technology. HistoryMuleFaces is an evolution of the original TaskBean component API concept and specification. You can read more about !TaskBeans here. Status and NewsWork is on-going towards the 2.0 release and specification. RoadmapQ1 2008 - 2.0 Release of MuleFaces API Q3 2008 - Research into OSGi support [Less]

Mule Source code for the Open Source ESBs in Action book published by Manning

This project contains the source code snippets and sample application for the book Mule in Action, authored by David Dossot and John D'Emic, and published by Manning Publications. Buy ... [More] Now!Required configuration: JDK 5 or better Maven 2.0.8+ Mule 2.1.x or better Build setup: MAVEN_OPTS="-Xms128m -Xmx512m -XX:MaxPermSize=256m" Be sure to check the current known issues. [Less]

SOA examples of ESB based service provisioning and RIA based service consumption

SOAFacesThe goal of the SOAFaces project is to provide developers with an API for building SOA and RIA powered components (called SOAFaces Bundles or just Bundles) that can be composed easily into web ... [More] applications or workflows and jobs with convenient access to local and remote messaging services. SOAFaces = RIA + SOA With SOAFaces you get the full power of an AJAX API combined with a SOA API. What can I build with SOAFaces? Secure Web Applications Mashup applications to full-blown AJAX clients Batch job scheduling Workflow processing You decide........ SOAFaces download page. Specifically, the goals of the SOAFaces project include the following: No need to write GWT RPC code anymore. Use the UniversalClient API to talk with POJO services that are packaged in your application server and/or talk with Mule accessible services/endpoints all across your enterprise and internet. Your GWT application will have convenient access to messaging services (SOAP, JMS, ESB ...etc) that can return JavaBeans or JSON objects back to the GWT client. All marshaling is handled by the framework. A framework for building SOA GUI applications using modular/pluggable components. Build anything from a simple AJAX type weblet all the way to a full blown web application. Package your code as a component and deploy your code as a modular/pluggable and self contained component. SOAFaces components are packaged into a simple JAR formatted archive and easily shared, deployed, and run. Create back-end workflow powered jobs and services that can be scheduled and run on the back-end with easy access to web services. Workflow properties and configuration rules can be configured using a web GUI. There are three main constructs: UniversalClient API - An API to use from any GWT client to make SOA service calls with no RPC. This API can be used with our without weblets/tasklets (you can use it in any plain old GWT client). Cool way to build GWT apps without all that RPC code and with easy access to web services. Weblet - A modular/pluggable way to build/package/deploy front-end web applications using GWT and SOA. Tasklet - A modular/pluggable way of build/package/deploy back-end tasks that can be run in scheduled batch jobs with convenient SOA integration. Sounds like a lot doesn't it? Well the SOAFaces framework is up to the task and keeps it as simple as possible. Keep reading if you would like to hear more........ Building Web ApplicationsWith SOAFaces you can build and deploy web applications that are powered with SOA and GWT. You can build your web GUI using the GWT (Google Web Tookit) framework and deploy your GWT applications on any standard j2ee servlet engine (like Tomcat). With SOAFaces, web developers can focus on building applications that can easily tap into web services hosted across the network. SOAFaces provides a MuleClient like API called UniversalClient. For those not familiar, the MuleClient interface is a universal messaging client available from the Mule Project that can invoke services endpoints such as JMS, Web Services, SMTP, SFTP, ...etc and send and receive data. UniversalClient is an extension of the MuleClient API for AJAX/GWT applications with even more extended capabilities. UniversalClient gives a GWT client the ability to access ESB services exposed by Mule. You can also expose our own POJO services using UniversalClient and make them available from your servlet engine (WAR webapp) directly. So you can message with remote Mule services or develop your own services and access them all from the UniversalClient API. To develop your own services, you create "local" services that you deploy in our servlet engine, and access these services using the same UniversalClient API. In fact the UniversalClient API functions as a universal messaging interface for GWT clients. It automatically marshals data in JSON and/or POJOs for you with no GWT RPC programming. The UniversalClient API builds on and extends the Mule endpoint notation, allowing you to access local POJO services within your web application (servlet engine). With this UniversalClient API you can mix and match resources and services all across the network to build GUI applications with a clear separation between the services/implementation and the GUI presentation. Building Modular and Pluggable Client ApplicationsA Weblet is the essentially building block for building modular component based applications. It is simply a GWT client that adheres to the SOAFaces API for building a GUI component (called a Bundle) and provides for an easy way to deploy big or small GWT GUI applications into a container. A Weblet is a modular GWT client that you can pick up and deploy in any SOAFaces container. Using the power of GWT and SOA, you can build mashups that pull and combine data from different sources across your intranet or internet, allowing developers the freedom to focus on what they do best - building applications and not dealing with implementing server-side code and marshaling data between client and server. Building Modular and Pluggable Workflows and JobsWorkflow? Yes, you can use SOAFaces to build jobs and tasks that can be run and scheduled in a workflow within a job processing container. The essential building block is called the Tasklet. Jobs (composed of one or more Tasklets) can be scheduled and run on a timer or executed on demand (this is up to the container to provide these services). A SOAFaces workflow can execute any arbitrary server-side java code and/or access messaging services via a MuleClient interface. The input properties of a workflow/job can optionally be edited, graphically, using the same GWT GUI framework used to build applications. So you are free to give your job/workflow components full-blown GUI interfaces to customize them anyway you chose. Or if you like just write server-side code (with no GUI) and package it up in a Bundle for use in a job. A Job can be composed of multiple Bundles. Where/How to use the SOAFaces Framework?With SOAFaces you have several ways you can use the framework. You can use the framework for building modular Bundle jobs/tasks, modular Bundle GWT weblets, or as a SOA messaging API in your existing GWT clients code to extend your GWT client to the SOA universe. Here is a break down of the scenarios you have for using the SOAFaces API: Usage Scenarios Deploy Where? Do What? Tasklet API Weblet API IOViewer API UniversalClient / Services API Standalone GWT Client Any standard J2EE container (e.g. tomcat, jetty...etc As a messaging API for use in any GWT client to access SOA services Required GUI Component (Bundle) SOAFaces Container (e.g. JobServer, SoaFacesRunner) For deploying and running modular weblets/applications Required Optional Workflow Component (Bundle) SOAFaces Container (e.g. JobServer, SoaFacesRunner) For batch job scheduling & workflow processing Required Optional Optional Optional (with Weblet/IOViewer) Standalone GWT ClientThe SOAFaces framework can be used as part of your existing GWT web application and provide you the ability to connect your GWT application with POJO services in your backend webapp and to access Mule/SOA services all across your network. You can use the SOAFaces framework with any standard GWT application to access remote SOA services with no RPC coding. The UniversalClient is only one small part of the SOAFaces framework but it is a very powerful and useful API to use directly in your GWT web applications. The UniversalClient API provides any GWT client the ability to access Mule services/endpoints and to send/return JSON and POJO objects with minimal effort - no RPC! The API also allows creating "local" services that can be deployed within the Bundle server-side and accessed as POJOs services from the UniversalClient API. So you get simple POJOs exposed as local services with remote access provided using the UniversalClient API. Simply include the SOAFaces framework JARs in with your servlet code and in your GWT code and you instantly have extended your GWT application with convenient messaging capabilities. No extra deployment or anything is needed. Simply use the SOAFaces framework with your existing GWT application and go. To get more information on how to get started using the UniversalClient API with you GWT application go here. Bundles as Application ComponentsIf you want to build modular component application (weblet), then you can package your code as a Bundle and deploy it in a SOAFaces container that will run and manage your Bundle Application. A Bundle Weblet uses the the Weblet API to allow you to build GWT applications that are managed and run with a SOAFaces container. You of course have full access to the UniversalClient API as well, to access SOA services. Bundles as Workflow ComponentsA Bundle Tasklet uses the Tasklet API to build modular server-side Java code that can be run as part of a larger job. The job can be scheduled for example and run any number of ways. The tasklet is packed in a Bundle and can also include a GUI customizer using the Weblet API. A Bundle Tasklet is deployed, run and managed, all within a SOAFaces container. Underneath the HoodThe essential building blocks of SOAFaces are tasklets and weblets. A packaged SOAFaces component is called a SOAFaces Bundle (or Bundle). A Bundle can be made up of a weblet and/or tasklet. The tasklet provides the API for implementing and executing back-end java code and services when the Bundle is used to build a workflow job. The weblet provides the abstraction for building AJAX Web GUIs of any kind. A weblet can be a standalone web application, that interfaces with remote web services, or it can be the GUI used to customize the input properties of a tasklet. As discussed, SOAFaces also provides easy access to Mule services and can easily interface and communicate with remote and local Mule services of all shapes and forms. SOAFaces leverages the GWT framework which serves the basis for its Web GUI API. Weblet - Building ApplicationsThe Weblet is the main abstraction for building end user GUIs with SOAFaces. A weblet enabled application can be deployed and run from a web application server. A weblet based application can be deployed and loaded dynamically within a hosting container without requiring server restarts. The code that makes up a SOAFaces Bundle is bundled and packaged in a JAR called a Bundle (SoaFaces Bundle). Here are details on creating a SOAFaces Bundle (Bundle). With a weblet, you have the full power of the GWT API at your disposal. The weblet interface itself is nothing more than a GWT Composite widget that can contain any GWT widget you drop into it. It functions as the top level UI panel for your application, mashup, or any other UI thing you want to build. What is especially nice about a weblet, is that you can just compile your GWT java classes into java binary classes and include them in a JAR file and the container will handle compiling your GWT java code into actual ajax/javascript. You can use virtually any standard GWT or third party GWT widget libraries and include them in your Bundle JAR and it will all get linked and compiled for you into ajax/javascript; this sort of similar to how a j2ee server complies JSP pages on the fly. Cool don't you think! So develop your components in GWT, package them up in a Bundle, and drop them into a SOAFaces container and go. No need to mess with GWT javascript to java compiling! Weblets - Accessing Remote Server-Side ServicesWeblets and generic GWT applications can access services using the GWT UniversalClient interface. This API is similar to standard MuleClient API available in native server-side java. The GWT UniversalClient API can pass and return POJOs (basic java primitives and objects that support the GWT IsSerializable interface) and/or JSON types. So using the GWT UniversalClient interface a GWT weblet can access web services and other ESB endpoints throughout your enterprise and over the internet, and do this directly from a GWT GUI. If we stopped there that would be interesting enough. However, you can also define your own "local" services and access such services directly from the GWT UniversalClient interface as well. A local services is a POJO method that is exposed as a local service and bundled directly within the Bundle JAR. So a Bundle can contain all the client and server/services code ,if that is what you prefer, or you can mix and match local services with remote service across your network or internet. For example access a remote web services might go something like this: //pass POJO and returns POJO UniversalClient.send("axis:http://my-web-services.com/?method=hellworld", "Bob", asyncPOJOHandler);All endpoints supported by Mule are supported the GWT UniversalClient interface. Accessing a local services would look like this: //pass POJO and returns POJO UniversalClient.send("soafaces://com.acme.local.MyServices/getHelloWorldEndpoint", "Bob", asyncPOJOHandler); //pass POJO and returns JSON UniversalClient.send("soafaces://com.acme.local.MyServices/getHelloWorldEndpoint", "Bob", asyncJSONHandler);The prefix soafaces:// tells the UniversalClient to route the call to a POJO service in the current Bundle JAR and return the results of the method. In this example the method com.acme.local.MyServices.getHelloWrold("Bob") is called and a POJO or JSON result can be returned via the asyncHandler. Tasklets - Building JobsA tasklet is a simple way to create any arbitrary server-side java code and run it a container that supports the SOAFaces Bundle API and run it as part of a job. The input and output of a tasklet is a JavaBean. One JavaBean for input and another for output. A tasklet consumes a JavaBean as input and returns a JavaBean as output. These input and output JavaBeans can have UI customizers/viewers that can edit and render the contents of the input/output JavaBeans for user manipluation. The Weblet API is used to render the GUI for the customizers/viewers. So you can pair a tasklet with a weblet if you want to give your tasklet a graphical representation (this is optional of course). Multiple tasklets can be composed and packaged together into back-end workflows and executed on timers and schedules for example as part of a job. The specification defines a life cycle for the execution of one or more tasklets that are chained together to execute a single job. Tasklets - Property MappingTasklets even get more interesting and powerful when you understand how the property mapping features works between multiple tasklets that can makeup a job. Tasklets can share and communicate with each other when they run as part of a job/workflow. Individual tasklets can pass JavaBeans to each other during the execution of the workflow (a chain of tasklets). The output JavaBean of one tasklet can serve as the input to the next tasklet in the chain (or even other tasklet further down the chain). This is done through a mapping specification to allow the end user (business analyst type person or developer) the ability to configure which properties of one particular output JavaBean get mapped to which corresponding properties of another input JavaBean. This is a very powerful features, it allows end users to customize behavior using a simple point and click GUI where the output of one tasklet can function as input to another tasklet. It allows tasklet's with no knowledge of each other to work together to perform a larger and more complex job or workflow operation. The SOAFaces API makes all this possible and straight forwards. Weblets and Tasklets - Use Them Together or SeparatelyAs mentioned, if you are only interested with building a RIA GUI, then you do not have to use the Tasklets API - you just focus on an use the Weblet API (org.soafaces.bundle.client package). Now, if you want to build back-end jobs and workflows then you should use the Tasklets API (org.soafaces.bundle.workflow package), and only use weblets, along with the tasklets, if you want to build GUIs to customize your tasklet's properties. Using weblets with tasklets is optional but is very powerful as it provides you with a way to allow end users to customize the inputs of tasklet. Once you have constructed your code, you then take it and package it up into a SOAFaces Bundle (Bundle JAR file) and deploy - that's it. It is very similar to deploying a WAR file but even simpler :) OSGiSOAFaces Bundles sort of sound like OSGi bundles don't they? Well, the two have similar goals with regard to building modular components that can be deployed in a runtime container and discover each other....etc. SOAFaces takes it a little deeper, but the underlying requirements of packaging code into components and hot deployment, for example, are very much similar. The SOAFaces project will make every attempt to align itself with the OSGi effort where it makes sense. Getting StartedReview SOAFaces Javadocs Download and test drive UniversalClient sample webapp to see API in action Download and review sample Bundle component source code from the BeanSoup sub project and write your first Bundle Download SOAFaces binary and source News and EventsProducts Using and Supporting SOAFacesJobServer - A commercial implementation of a SOAFaces container for managing, deploying and running Bundles. Free for non-commercial use. SoaFacesRunner is the SOAFaces container Reference Implementation - you can deploy and run SOAFaces Bundles (Bundles) with SOAFacesRunner in any servlet engine. This includes deploying and running weblets and tasklets. Available SOAFaces ComponentsBeanSoup is a small project and code with many sample SOAFaces Bundles (Bundles) implemented. A Bundle is a SOAFaces component that can be deployed to any compliant SOAFaces container. RoadmapQ1 2010 - SOAFacesRunner 1.0 (RI implementation of SOAFaces container) Q2 2010 - Support for other major ESBs Q3 2010 - JSON Proxy Annotation/Compiler HistorySOAFaces is an evolution of the original TaskBean component API specification. The TaskBean API was a framework before its time :) You can read more about TaskBeans here. [Less]

XAware 5 is open source data integration software for creating and managing composite data services for SOA and Web 2.0 applications. XAware enhances the productivity of other development tools and ... [More] frameworks by building composite data services. These services provide real-time access to information and the ability to abstract, transform, aggregate and mashup data. Developers use these XAware capabilities to create a data virtualization layer, which delivers a single view of re-usable meta-data that is granular, normalized and can be consumed or served up easily. [Less]

This provides some mule components that work together to simulate the infrastructure needed to deliver sms messages. The focus of this project is to provide a mule sample we do not support telco specific protocols of a real telco company.

Java Open Source Shop is a project that use many open source java frameworks and components.