[CONF] Apache ServiceMix: Should I Create My Own JBI Components? (page edited)

[confluence]

Page Edited : SM : Should I Create My Own JBI Components? Should I Create My Own JBI Components? has been edited by Eric Renault (Jan 16, 2008). (View changes) Content: Should I Create My Own JBI Components? Development with JBI can be quite a departure from traditional application development. Therefore, many developers are a bit confused when they first encounter JBI. This confusion is rather common and is the topic of this FAQ entry. One of the overarching ideas in JBI is that every integration scenario should not require custom code to be created. Instead, the most common components should be provided by vendors that use the JBI APIs. This will make the integration developers' job a bit easier because they are most concerned with simply providing a configuration for these existing components. In JBI parlance, binding components (BCs) and service engines (SEs) are defined by the JBI spec and are key building blocks for working with JBI containers. However, the JBI APIs are meant to be used for container development and not for application development. The difference here is subtile, but important. To better understand the difference, let's examine the differences between these two roles. Development Roles The majority of developers fulfill the role of application developer; those developers building applications for business reasons using the JBI container versus the role of container developer; those developers deliberately extending and improving the JBI container functionality. Clarifying the difference between these two roles will help to understand how to approach development with the JBI APIs and the JBI container. Application Developers The role of application developer is focused on simply using the JBI container to develop a business application. In performing application development using a JBI container, developers should spend their time creating JBI service units (SUs) and chaining them together to create a flow of sorts. In the case of ServiceMix, BCs for the most commonly used communication protocols are already provided along with SEs for the most commonly used engines. Application developers use these existing BCs and SEs to develop SUs for their integration needs. The vast majority of business requirements can be met using the existing BCs and SEs. Examples For Developing JBI SUs JBI service units are used to develop integration applications. A SU provides a configuration for an existing JBI component to tell it how to behave. Let's look at a few examples in using existing JBI components for creating SUs: A developer needs to integrate messages being sent using JMS queues - A very common use case is to integrate messages that are already being sent via JMS queues. In this case, the developer would create a configuration to tell the servicemix-jms component how to behave. This configuration is packaged as a JBI SU and then wrapped in a JBI service assembly (SA) to be deployed to the JBI container. A developer needs to integrate files on a FTP server - Another common use case is to integrate files on a FTP server, no matter whether these files are being consumed from the FTP server or produced to the FTP server. In this case, the developer would create a configuration to tell the servicemix-ftp component how to behave. This configuration is also packaged as a JBI SU and then wrapped in a JBI service assembly (SA) to be deployed to the JBI container. Files coming from a JMS queue need to be transformed from one format to another format to be published to a FTP server - This is another very common use case within the integration space. This is most commonly achieved through the use of a transformation of some sort using, for example, the servicemix-saxon component, the servicemix-script component or maybe even the servicemix-bean component. No matter what is used, the developer would again create a configuration, but this time s/he would specify to which component the transformed files should be sent. This is all then packaged as a JBI SU and then wrapped in a JBI service assembly (SA) to be deployed to the JBI container. Analogy Web application developers only make use of a servlet container to develop applications. Most typically, these developers have no need to modify the functionality of the servlet container itself. They make use of the functionality that is provided by the servlet container. In order to deploy their applications, all configurations, views, dependencies, etc. are packaged up in a WAR file to be deployed to the servlet container. Therefore, application developers typically do not need to develop JBI components. However, there are exceptions. Container Developers The role of container developer is deliberately focused on improving the JBI container itself in some way. Sometimes the application developer can unintentionally change roles to become a container developer without explicitly intending to do so. This role reversal is actually quite natural for a particular reason. Most often, this role reversal occurs when an application developer needs to make use of a protocol for which a BC does not yet exist, or an unsupported engine needs to be deployed to the JBI container. Examples For Developing JBI Components Let's look a couple of examples that would require a developer to create a BC or SE. A developer needs to support the SNMP protocol - Because a JBI binding component does not yet exist for the SNMP protocol, this developer would need to create a new JBI binding component that speaks the SNMP application layer protocol to integrate SNMP messages into the JBI normalized message router (NMR). A developer needs to deploy EJBs to the JBI container - In this example, a business might want to deploy EJBs to the JBI container. This would require that a EJB container such as OpenEJB be wrapped as a JBI service engine using the JBI APIs. This would allow the JBI container to handle the deployment of EJBs because the EJB container would run inside the JBI container process and would speak JBI normalized messages to communicate with the JBI normalized message router (NMR). NOTE: Please note that once the BC or SE is created and deployed to the JBI container, in order to make use of it, a SU must be developed and deployed to provide the JBI component with a configuration. Analogy Servlet container developers are mainly concerned with improving the functionality of the servlet container according to the servlet spec. However, some improvements are not guided by the spec and are therefore specific to the servlet container. Therefore, it is somewhat common for a developer to switch roles in order to implement a BC or SE. But this task is much more involved than creating SUs and requires a fair amount of knowledge about JBI. Summary The point of this FAQ entry is to describe the difference between developing integration applications through the use of SUs versus the development of the JBI compliant components through the use of the JBI APIs. The differences between these two paradigms can be difficult to discern when first encountering JBI. Hopefully the explanations above have helped to clarify this topic. If you have any further questions on this topic, please discuss them on the Mailing Lists.

Powered by Atlassian Confluence (Version: 2.2.9 Build:#527 Sep 07, 2006) - Bug/feature request

Unsubscribe or edit your notifications preferences