In the Toolkit of IBM® WebSphere® Message Broker (hereafter called Message Broker) prior to V8, interaction with and visualization of artifacts that make up a solution were done differently depending on whether you were developing, deploying, or administering the artifacts. By introducing the concept of Applications and Libraries, this visualization and interaction is consistent and easier to understand within the three stages. This article describes Applications and Libraries, shows you how to use them, and explains the advantages of converting your existing solutions to use Applications and Libraries with Message Broker V8.
This article uses a simple example to illustrate the advantages that Applications and Libraries provide in Message Broker V8. You can download zip files of the example at the bottom of the article. The zip file migration_to_applib_v7projects.zip contains a set of projects authored in Message Broker V7. The zip file migration_to_applib_v8applib.zip contains several Applications and Libraries that show what the example looks like after it has been converted to an Application and Library structure in Message Broker V8.
As Applications and Libraries primarily affect the structure of solutions, the example focuses mainly on the structural layout of artifacts rather than their contents or the functional behaviour of the solution.
There are two solutions in migration_to_applib_v7projects.zip, named MyFirstSolution and MyOtherSolution. MyFirstSolution contains several deployable flows, one of which is shown in Figure 1:
Figure 1. Example of MyFirstSolution
For this discussion, the important aspects of the solution are the structural dependencies. The two main flows are in a single flow project called MyFirstSolution. While not included in this example, this solution may include other ESQL files or message maps within the same flow project. This flow project also has dependencies on three projects: MyFirstSolutionMessageSet message set project, CommonSubFlows flow project, and SharedMessageSet message set project.
The MyFirstSolutionMessageSet contains message definitions that are only used by MyFirstSolution. Both CommonSubFlows and SharedMessageSet contain artifacts used by this solution and possibly by other solutions. In the case of CommonSubFlows, it contains various reusable subflows (and possibly message maps and ESQL files), while SharedMessageSet contains message definitions. One conventional example where a message set may be shared is if it was created from an industry schema.
In MyFirstSolution, the message sets are being used by the MQ Input nodes to validate the message on the queue, and the subflows are being used to encapsulate certain functionality. For this discussion, the reasons for the dependencies are not important, but the relationship between the projects will be pertinent.
This PI also contains a second solution called MyOtherSolution contained in a flow project. This solution has a deployable message flow and puts dependencies on the message set MyOtherSolutionMessageSet and also on SharedMessageSet.
The next section shows why the visualization in V7 is not ideal when working with multiple solutions like the one above.
In the simple example on Message Broker V7, there are six projects within the Broker Development view that implement two solutions. Even at this small scale, as shown in Figure 2 below, some problems begin to arise.
Figure 2. Example of two simple solutions within the Broker Development View
- It is not clear which projects belong to which solutions. Some projects may be correctly named, but it is not clear whether a project like CommonSubFlows belongs in MyFirstSolution, MyOtherSolution, or both. The answer is that it belongs only in MyFirstSolution, which is not evident by simply looking at the Broker Development view.
- As solutions scale, the number of projects within the Broker Development view becomes unwieldy, and it becomes hard to work with so many projects at once. You can use working sets to address this problem in the Message Broker V6 and V7 Toolkits, they require you to be active in keeping the working set consistent with the actual projects used in your solution. Later sections of this article explain how the Applications and Libraries feature will help you with these problems.
As you continue in the workflow of building and deploying a solution, the next step is to create a BAR file. The BAR File Editor lists deployable artifacts and it is up to you to choose which ones to include within the BAR file. An example of the BAR File Editor is shown in Figure 3:
Figure 3. BAR File Editor showing the example
In order to build a BAR file for a single solution, you need to understand which artifacts to include in the BAR. For example, if you are trying to deploy MyFirstSolution, you need to know to check AnotherDeployableFlow and MainFlow (and not check MainSolutionFlow) under the Message Flows category. Likewise, if you are trying to deploy MyOtherSolution, you need to know to check the message set under MyOtherSolutionMessageSet and SharedMessageSet because of the dependency on SharedMessageSet. This procedure becomes more difficult and error-prone as other artifacts such as adapters and Java code are included in the solution, and as the number of flows and projects in the workspace increases.
In the example, you build a BAR file for both solutions and store it under the BAR files project. If you open this BAR, you will see what artifacts have been built within the Manage tab, as shown in Figure 4:
Figure 4. Example of built artifacts from various solutions within a BAR file
Figure 4 illustrates another difficulty that a developer or an administrator may face. Similar to the Broker Development view and the Prepare tab of the BAR Editor, artifacts from multiple solutions are displayed within a flat list, and it is hard to determine which artifacts belong to which solutions, especially since the context of the physical project is no longer shown. After this BAR file is deployed to the runtime, a similar issue occurs, as shown in Figure 5:
Figure 5. Example of several solutions deployed to a single execution group on a broker
While this example is from the Brokers view in the Message Broker Toolkit, a similar view can be seen in the Message Broker Explorer. An additional problem shown in Figure 5 is a lack of isolation. In the example, both solutions use SharedMessageSet. If you were to deploy a new SharedMessageSet, the change would affect both solutions (which may be an expected outcome). You can deploy each solution to its own execution group in order to achieve this isolation, but having an execution group for each solution may be undesirable in some circumstances, and the BAR files may not be constructed in a way that facilitates this arrangement, as in this example.
The preceding sections have described situations where the current visualization can be improved, and explained why the structural organization of solutions has been improved in V8. The next section describes the concepts introduced as part of Applications and Libraries before showing how you can model and convert the example to use Applications and Libraries.
An Application is a logical container that houses the functionality required to solve a problem. An Application is also a method of encapsulation to restrict access to and visibility of the Application's contents from artifacts that are not part of the Application. This encapsulation begins during development and continues through deployment and runtime. A Message Broker Application is similar to the concept of a solution, but a large solution may be implemented across several Applications.
An Application can contain one or more Libraries. A Library facilitates reuse. For example, if you want to share subflows or message sets across several solutions, you should put them in a Library. In addition to facilitating reuse, a Library can also be a structural component that improves organization. For example, a Library can contain all of the ESQL, or all of the artifacts needed to access an external service.
Applications and Libraries can be combined in a variety of ways, some of which are shown in Figure 6:
Figure 6. Examples of structures using Applications and Libraries
In the first diagram in Figure 6, an entire solution is contained within a single Application. In the second diagram, a solution is structurally organized into an Application and several Libraries. The third diagram shows multiple Applications using a common Library. These examples are just some of the ways you can structure your solution, and you should look at your current artifacts to determine what structure makes the most sense. Here are the rules Applications and Libraries in Message Broker V8:
- An Application may not reference another application, but may reference 0 or more Libraries.
- A Library may reference 0 or more Libraries.
Here are some best practices for using Applications and Libraries to structure your solution:
- Deployable flows that are specific to a solution should reside in an Application, not in a Library.
- Data artifacts such as schemas or message sets should reside in a Library.
- If a data or functional artifact is reusable (for example, ESQL code), consider putting it in a Library.
The following sections explain how your projects and artifacts from previous versions of Message Broker can map to Applications and Libraries, and how to convert them to use Applications and Libraries in V8.
Now that you understand what Applications and Libraries are, this section shows you how to transform the existing example from Message Broker V7 to use Applications and Libraries. In Message Broker V7 and earlier, artifacts were stored within message flow projects and message set projects. In Message Broker V8, message flow projects no longer exist. An Application can contain the same types of artifacts as a message flow project, and in addition:
- New artifact types from Message Broker V8, such as DFDL schemas, XSD, and maps
- Data artifacts from message set projects, such as adapter files, IDL files, and WSDL files
Finally, an Application can also contain entire message set or Java projects in the event that your solution requires them.
A Library can contain exactly the same types of artifacts and projects as an Application. While there is no difference in what they can store, there are distinct differences regarding when an Application or Library should be used, as described above. In the example, MyFirstSolution consists of the following projects:
- A flow project named MyFirstSolution
- A message set named MyFirstSolutionMessageSet
- A flow project named CommonSubFlows, which may not be solely used by MyFirstSolution
- A message set named SharedMessageSet, which may not be solely used by MyFirstSolution
You can map the structure of this solution onto Applications and Libraries:
Figure 7. Example of mapping V7 projects to V8 Applications and Libraries
In Figure 7, you construct an Application called MyFirstSolution that contains all the artifacts from the flow project, and the message set MyFirstSolutionMessageSet. Since you have identified CommonSubFlows and SharedMessageSet as potentially reusable artifacts, each one is placed in a separate Library. You can both of these projects into a single Library, but SharedMessageSet is used separately in MyOtherSolution, and each Library is then referenced by the application (not shown in the diagram). Thus, you often need to take a holistic view of your solutions when reorganizing them into an Application and Library structure.
Once you have an understanding of how the Message Broker V7 projects will be mapped to Applications and Libraries, you can do the conversion. The best practice when moving between versions of the Message Broker Toolkit is to export all of your projects in a single PI file, and then import the PI file into the new version. To convert the example, use the migration_to_applib_v7projects.zip file, which you can download at the bottom of the article.
As Applications and Libraries can be used only in Message Broker V8 or later, begin by bringing in projects from a prior version through a Project Interchange (PI) file. Since message flow projects no longer exist in V8, each message flow project will be converted into a message broker project. This conversion changes the metadata associated with the project, but does not make any functional changes. Your imported projects will still be valid after importing into V8, as long as they were error-free before importing.
In V8, Message Broker and message set projects are displayed underneath an Independent Resources category in the Broker Development view. Figure 8 shows the projects from the example immediately after they have been added into a V8 workspace:
Figure 8. View of projects from previous version after importing into a V8 workspace
To convert a single Message Broker project into an Application or Library, simply select the project and select Convert to Application or Library from its context menu. It is generally a good practice to convert the dependencies (Libraries) first. An example where CommonSubFlows is converted is shown in Figures 9 and 10:
Figure 9. Initiating the conversion of CommonSubFlows into a Library
Figure 10. Converting a Message Broker project to a Library
This conversion converts the project in place -- that is, the metadata of the project is updated so that it is now considered a Library. After a project has been converted into an Application or Library, the project no longer appears under the Independent Resources category. Applications and Libraries are displayed within the Broker Development view as a top-level item above Independent Resources, as shown in Figure 11:
Figure 11. Example of a Library being displayed in the Broker Development view
You can use the same procedure for the other project types, such as message set or Java projects, with these minor changes. For example, when converting SharedMessageSet into a Library, you must specify a name for the Library, because instead of actually converting SharedMessageSet into a Library, you are creating a new Library that contains this Message Set.
The explanation of Applications and Libraries mentioned that an Application or Library can contain artifacts or other projects. In the case of Message Broker projects, an Application or Library can contain any artifact that existed in the Message Broker project, and therefore the project metadata can simply be changed so that it becomes an Application or Library. In the case of message set projects and Java projects, Applications and Libraries contain the entire project and therefore you must create a wrapper Application or Library.
Finally MyFirstSolution and MyOtherSolution can be immediately converted into an Application through the context menu. This action automatically includes the associated message set projects MyFirstSolutionMessageSet and MyOtherSolutionMessageSet into the respective Applications. The completed conversion is shown in Figure 12:
Figure 12. Completed conversion of V7 example into Application and Libraries
The next section shows how the new Applications can be visualized and used more effectively to solve the problem raised earlier in this article.
Converting a solution into Applications and Libraries makes it much easier to identify and work on the solution. Each solution from the example has been placed in its own Application, and all artifacts, including any common artifacts, are displayed beneath the application. An example based on MyFirstSolution is shown in Figure 13:
Figure 13. Artifacts used in MyFirstSolution are displayed below the Application
In Figure 13, you can see that the flows, the message set, and the subflows and message sets from CommonSubFlows and SharedMessageSet are shown directly below the Application. You do not need to scroll around the Broker Development view to find the relevant artifacts or projects, as they are all listed with the same parent. All other artifacts that can be contained within the Application, such as DFDL or XSD schemas, maps, ESQL files, and test clients, would also be displayed below the Application.
One other method of concentrating on an Application is to focus on it, which you can do through the context menu as shown below. You can focus on one Application or Library at a time, and when focused upon, only the contents of that Application or Library are visible in the Broker Development view:
Figure 14. Context menu item that enables focusing
Focus is an evolution of working sets, and will always include the artifacts and projects that the focused Application or Library contains, without any active maintenance.
The simplicity of visualizing Applications and Libraries continues in the BAR File Editor. If you wish to include an Application or Library in a BAR file, all deployable artifacts in the Application or Library are automatically included. If you include an Application that references a Library, you need only select the Application in the BAR File Editor, and referenced libraries will be automatically included. Creating BAR files is greatly simplified because you no longer need to understand and identify which artifacts need to be deployed. An example of the streamlined process is shown in Figure 15:
Figure 15. Example of building a BAR for MyFirstSolution
In Figure 15, you simply identify which Application you want to build by selecting it in the tree. The deployable artifacts that will be included in the Application are shown below it. Selecting Libraries that are not included in Applications is a similar process after selecting the Message flows, Libraries, and other message flow dependencies radio button. After a BAR file has been built, the Manage tab also displays its contents organized by Application or Library, as shown in Figure 16:
Figure 16. BAR file contents organized by Application
A similar view of the artifacts is shown when the BAR is deployed to the runtime. An example of this from Message Broker Explorer is shown in Figure 17, and an example from the Brokers view is shown in Figure 18:
Figure 17. Deployed Applications and Libraries in Message Broker Explorer
Figure 18. Deployed Applications and Libraries in the Brokers view
Applications also enforce isolation within the runtime. For example, both Applications in this example use the SharedMessageSetLib Library and deploy a separate copy as part of the Application. In this manner, you can update SharedMessageSetLib and deploy an updated copy of the MyOtherSolution Application without modifying the existing deployment of MyFirstSolution. Any flows in MyFirstSolution cannot see across the application container and access resources in MyOtherSolution, and vice versa.
This article showed you how to take solutions authored in Message Broker prior to V8, and convert them into an Application and Library structure, which provides a powerful new way to visualize, understand, and work with artifacts in a consistent way throughout the development, deployment, and runtime stages of your project. Using Applications and Libraries also provides isolation for your Applications, and reusability for artifacts stored within Libraries. By converting your existing Message Broker V6 or V7 solutions to use Applications and Libraries, you can leverage this new functionality and simplify your development processes.
|Code sample||migration_to_applib_v7projects.zip||32 KB||HTTP|
|Code sample||migration_to_applib_v8applibs.zip||33 KB||HTTP|
- WebSphere Message Broker resources
- WebSphere Message Broker V7 information center
A single Web portal to all WebSphere Message Broker V7 documentation, with conceptual, task, and reference information on installing, configuring, and using your WebSphere Message Broker environment.
- WebSphere Message Broker developer resources page
Technical resources to help you use WebSphere Message Broker for connectivity, universal data transformation, and enterprise-level integration of disparate services, applications, and platforms to power your SOA.
- WebSphere Message Broker product page
Product descriptions, product news, training information, support information, and more.
- What's new in WebSphere Message Broker V7
WebSphere Message Broker V7 provides universal connectivity with its ability to route and transform messages from anywhere to anywhere. Through its simple programming model and a powerful operational management interface, it makes complex application integration solutions much easier to develop, deploy, and maintain. This article describes the major enhancements in V7.
- Download free trial version of WebSphere Message Broker V7
WebSphere Message Broker V7 is an ESB built for universal connectivity and transformation in heterogeneous IT environments. It distributes information and data generated by business events in real time to people, applications, and devices throughout your extended enterprise and beyond.
- WebSphere Message Broker documentation library
WebSphere Message Broker specifications and manuals.
- WebSphere Message Broker forum
Get answers to your technical questions and share your expertise with other Message Broker users.
- WebSphere Message Broker support page
A searchable database of support problems and their solutions, plus downloads, fixes, and problem tracking.
- WebSphere Message Broker V7 information center
- WebSphere resources
- developerWorks WebSphere developer resources
Technical information and resources for developers who use WebSphere products. developerWorks WebSphere provides product downloads, how-to information, support resources, and a free technical library of more than 2000 technical articles, tutorials, best practices, IBM Redbooks, and online product manuals.
- developerWorks WebSphere application integration developer resources
How-to articles, downloads, tutorials, education, product info, and other resources to help you build WebSphere application integration and business integration solutions.
- developerWorks WebSphere business process management developer resources
WebSphere BPM how-to articles, downloads, tutorials, education, product info, and other resources to help you model, assemble, deploy, and manage business processes.
- Most popular WebSphere trial downloads
No-charge trial downloads for key WebSphere products.
- WebSphere forums
Product-specific forums where you can get answers to your technical questions and share your expertise with other WebSphere users.
- WebSphere on-demand demos
Download and watch these self-running demos, and learn how WebSphere products and technologies can help your company respond to the rapidly changing and increasingly complex business environment.
- developerWorks WebSphere weekly newsletter
The developerWorks newsletter gives you the latest articles and information only on those topics that interest you. In addition to WebSphere, you can select from Java, Linux, Open source, Rational, SOA, Web services, and other topics. Subscribe now and design your custom mailing.
- WebSphere-related books from IBM Press
Convenient online ordering through Barnes & Noble.
- WebSphere-related events
Conferences, trade shows, Webcasts, and other events around the world of interest to WebSphere developers.
- developerWorks WebSphere developer resources
- developerWorks resources
- Trial downloads for IBM software products
No-charge trial downloads for selected IBM® DB2®, Lotus®, Rational®, Tivoli®, and WebSphere® products.
- developerWorks blogs
Join a conversation with developerWorks users and authors, and IBM editors and developers.
- developerWorks cloud computing resources
Access the IBM or Amazon EC2 cloud, test an IBM cloud computing product in a sandbox, see demos of cloud computing products and services, read cloud articles, and access other cloud resources.
- developerWorks tech briefings
Free technical sessions by IBM experts to accelerate your learning curve and help you succeed in your most challenging software projects. Sessions range from one-hour virtual briefings to half-day and full-day live sessions in cities worldwide.
- developerWorks podcasts
Listen to interesting and offbeat interviews and discussions with software innovators.
- developerWorks on Twitter
Check out recent Twitter messages and URLs.
- IBM Education Assistant
A collection of multimedia educational modules that will help you better understand IBM software products and use them more effectively to meet your business requirements.
- Trial downloads for IBM software products
Kevin Quan is a Software Developer on the WebSphere Message Broker Toolkit Team at the IBM Canada Software Lab in Toronto. He earned a Bachelor's degree in Electrical Engineering and a Master's degree in Computer Engineering, both from the University of Waterloo in Canada. You can contact Kevin at firstname.lastname@example.org.