TIBCO BW6 Application Version

Versioning is very important within TIBCO BusinessWorks 6.x (BW6).

One approach to managing EAR file versioning is to incorporate the version into the EAR file name. For example, ApplicationName.application_1.0.0.

However, there are limitations to this approach.

  • you are dependent upon the accuracy of the person or process that created the EAR file and named it
  • it doesn’t include the qualifier portion of the version
  • if you are using a version control system for the EAR file then you don’t want the file name to change between versions

Luckily, EAR files follow the same standard as JAR files. The following code snippet will query the EAR file for the “Bundle-Version” and output it

import java.io.IOException;
import java.util.jar.*;

public class EarVersion {
   public static void main(String[] args) {
       JarFile jf = null;
       Manifest mf = null;
       Attributes att = null;
       try {
           jf = new JarFile(args[0]);
       } catch (IOException e) {

       try {
           mf = jf.getManifest();
       } catch (IOException e) {

       att = mf.getMainAttributes();


If you run this against an EAR file you will get an output that looks like, assuming that the application Version: (in TIBCO BusinessStudio for BusinessWorks) is set to “1.0.0.qualifier”.

You can use this in the following Windows command script to set a variable with the major.minor version number. (This example assumes that you generated the ear-version.jar file from the code snippet above and that your TIBCO HOME is c:\tibco.)

SET JAVA_HOME=c:\tibco\tibcojre64\1.8.0
FOR /F “usebackq tokens=1-2 delims=.” %%G IN (java -jar ear-version.jar %appname%.ear) DO set appversion=%%G.%%H

The value of the variable appversion would be 1.0 for a full version value of

The application’s major.minor version number is required for the following common bwadmin operations.

  • backup
  • start
  • stop
  • undeploy

A deployed application’s major.minor version number can also be queried using the following Windows command script.

cd /d c:\tibco\bw\6.5\bin
FOR /F “usebackq tokens=2” %%i IN (`bwadmin show -d %domain% application ^| findstr %appname%`) DO set appversion=%%i

Visual Studio 2013, Entity Framework 6 and Oracle ODP.NET

I just went through an exercise trying to use code based configuration with Oracle’s ODP.NET and although there is a lot of information out there I had to eventually go to the Official API documentation to close the loop.

This is what I had to do – hopefully it will help someone else.

I created a WCF self-hosted console application. All this sample does is take a primary key integer value and return a first and last name from a USERS table in Oracle 11gR2.

First thing – don’t do the heavy lifting yourself – use NuGet. Right-click on your project¬† in the Solution Explorer and select “Manage NuGet Packages…”.

In the search box enter “odp.net managed”.

Select “ODP.NET, Managed Entity Framework Driver – Official” and “Install” it. Note that this screen shows green checkmarks because they are already installed in my case.

It is dependent upon the Entity Framework and “ODP.NET, Managed Driver – Official” so it will automatically include them.

Note that it will include Entity Framework 6.0.0. Use the “Updates” section to update it to the latest version.

After doing this you will have the following installed packages.

Your project will now be configured to use Oracles ODP.NET Managed Entity Framework Driver.

I am going to quickly skip through some details of my simple sample. I added an ADO.NET Entity Data Model for my sample.

And I selected “Code First from Database”.

My Oracle database is a single table where ID is also a primary key.

The resulting model artifacts are:


I have a GetData operation as part of my service that takes the ID value and returns the first and last name.

If you run this it will work using the values from the application configuration file.

However, the Entity Framework and DB Providers sections in the configuration file can be replaced by creating a DbConfiguration object with the following settings. The “using” values shown are the ones that I had to add.

Additionally, the Model’s DbContext must be annotated to use this DbConfiguration. (Note that there are other options for associating the DbConfiguration with the DbContext that I am not covering here.)

You can now remove the following sections from your app.config file and it should still work.

<defaultConnectionFactory type=”System.Data.Entity.Infrastructure.LocalDbConnectionFactory, EntityFramework”>
<parameter value=”v12.0″ />
<provider invariantName=”Oracle.ManagedDataAccess.Client” type=”Oracle.ManagedDataAccess.EntityFramework.EFOracleProviderServices, Oracle.ManagedDataAccess.EntityFramework, Version=, Culture=neutral, PublicKeyToken=89b483f429c47342″ />

<remove invariant=”Oracle.ManagedDataAccess.Client” />
<add name=”ODP.NET, Managed Driver” invariant=”Oracle.ManagedDataAccess.Client” description=”Oracle Data Provider for .NET, Managed Driver” type=”Oracle.ManagedDataAccess.Client.OracleClientFactory, Oracle.ManagedDataAccess, Version=, Culture=neutral, PublicKeyToken=89b483f429c47342″ />

I hope this helps.

DbVisualizer – No install and uses JDBC drivers

DbVisualizer is a good tool if you want to access and navigate through your database using a graphical user interface.

It is a good solution if you don't have a tool installed to access and view your database. This is because it doesn't have to be installed, which means that you don't need local system administrator privileges to run it.

Also, because it uses JDBC drivers to connect to the database it is a good tool for validating your JDBC drivers if you are having issues connecting to the database from another application using the same JDBC drivers.

Reuse Practices

Here are some key software development reuse practices:

  • strong software architecture that provides framework for reuse activities
  • software development process that promotes and controls reuse
  • reuse more than just code; reuse at the architectural level
  • practice domain engineering; develop reusable components at the domain level
  • integrate reuse through all of the life cycle activities and the management of those activities
  • use software tools that support reuse; modern IDEs along with supporting knowledge bases are very useful.
  • organizational structure that facilitates partnering across project boundaries

Reuse can occur at many levels. Some of the levels, starting at the lowest level and working up are:

  • code fragment (cut and past reusability)
  • subroutine or function
  • object (data and methods)
  • component
  • architecture
  • business patterns
  • packaged application frameworks

Effectively reusability doesn't just happen. It is a planned event that
takes time and resources. A separate domain engineering and knowledge
base is required to promote and push its use throughout the

The problem with reusability is that it usually isn't cost effective
until a component has been reused (with very little analysis or
modification) 5 or 6 times. Designing components for reusability slows
down the current design and implementation process and requires a domain
engineering/knowledge sharing organization to support and carry-on the
reuse efforts.

Reuse is most effective when it is tied to business or technical
patterns. The lower the level that reuse occurs the smaller its payback.
This is because the first four (4) levels that I listed above only
affect the implementation or coding cycle. Architectural and business
patterns and customized packaged applications cut across many more of
the software development lifecycle (SDLC) cycles and therefore have a
larger impact.

Big Projects, Done Small – Computerworld

I agree with the premise of this ComputerWorld article by Frank Hayes - "propose big and build small".

Just make sure that you don't follow a huge waterfall methodology. This approach requires an agile methodology.

As you implement additional portions of the system you will have to revisit and refactor portions that you already finished. Don't stress out over this.

Change and release management are also important parts of making this approach work.

Evolving Database Design

The concept of the "golden" and immutable database schema makes me crazy.

Agile methodologies, like SCRUM, have been adopted by many development groups to account for the fact that a perfect and unchangeable requirements specification will never exist before programming begins.

However, a big impedance mismatch will threaten your efforts if the application's database schema is under the control of a separate DBA group that is following a traditional waterfall methodology. (Note that I am talking about the application's database schema and not enterprise data store schemas.)

Academically I have seen and discussed many different ways of dealing with the issues associated with database changes. Martin Fowler and Pramod Sadalage discuss many of these issues in "Evolutionary Database Design".

In practice I have favored individual developer database instances with data architecture/DBA review. Just as solution architects don't babysit each system design change I don't think that data architects or DBAs should either. Any issues related to a design change can be dealt with using regular reviews and subsequent re-factoring.

In this practice the database schema and build scripts are part of the solution. To get a local database instance to work with the developer just gets the latest solution from source control and runs the DB build script. If they need to make changes to the DB then these changes are made and tested locally by the developer and then finally checked into source control for the rest of the team. The developer who makes the DB changes is also responsible for making sure that any required code changes are also checked in at the same time. A communication mechanism needs to be put into place so that the rest of the team knows that they will need to update their database at their next integration point (i.e. source code get latest).

Depending upon the phase of development, changes may be made to the original schema and everyone will have to rebuild their database or changes will be implemented as alter scripts and everyone will only have to update their database. Once the system goes to production all modifications will need to be implemented as alter scripts.

Lean Modeling (or, there are sure a lot of UML diagrams)

In UML version 1.4 there were 9 diagrams.

In UML 2.2 there are now 14 diagrams. There are seven structure diagrams and seven behavior diagrams. Within the behavior diagrams four of them are interaction diagrams.

But, this entry isn’t really about the number and type of UML diagrams. It is about lean-modeling using UML. As I mentioned in my entry on Modeling Philosophies, over-modeling is worse than under-modeling. What you really want to achieve is just-what-is-needed-just-in-time modeling.

You have been asked to develop the software architecture for a new system and to document it for presentation and review. And, by the way, use UML diagrams. What do you do? Throw your hands up in exasperation and complain that you don’t have enough time to do 100’s of pages of documentation?


To start with, let’s assume that you were going to do some analysis and design before you started coding. The UML models should flow naturally from your analysis and design process.

You are going to need to determine what things/nouns/objects/entities you are going to be working with. Document them in a class diagram.

You are going to need to determine what actions the user or other systems can cause or trigger. Document them in a use case diagram. If the actions are not self-evident then provide more detail using activity diagrams.

If an action is complex and requires coordination between multiple objects then you may want to create a sequence diagram to illustrate the interaction between the objects.

If you have a process flow with a number of states and each state can transition to multiple other states then a state machine diagram is very useful.

I also recommend that you develop a package diagram for your system. It will help you determine how to structure your code/solution, group your objects together for deployment (dll / jar files), and avoid cyclical references.

Finally, I am not saying that you shouldn’t use any of the other diagrams. Depending upon your application type, its complexity, and your audience, additional diagram types may also be very useful.

Four Phases of RUP

Are you having problems determining which phase you are in and what your focus should be?

Forget the standard names:

  • inception
  • elaboration
  • construction
  • transition

Use the following questions to determine if you are on track and to remind yourself what you are trying to achieve:

  • Should we build it?
  • Can we build it?
  • Is it built yet?
  • Is it delivered yet?

When you have answered yes to the question for that phase it is time to move to the next phase.

If you realize that you will not be able to answer yes to a phase, within your time and budget constraints, then it is time to kill the project.

No one likes to fail but not everything is possible and killing a project at $1mil is a lot better then doing it at $10mil or $100mil.