Increasing Reach

Software reuse has always had issues. In my opinion, the most common types of reuse are:
1. "Copy & Paste Reuse".
2. Off-The-Shelf Reuse - Here, we leverage JVM's, .Net API's, J2EE libraries, open source offerings, etc. that are pre-built and providing immediate value.

The third (and elusive) category would be the homegrown libraries - often domain specific. Let's be clear - the more general the problem, the easier to reuse; conversely, the more specific the problem, the harder to reuse. The easy stuff is packaged in your favorite off-the-shelf library - leaving the more difficult stuff for the I.T. department.

Reuse is difficult - and reuse via language specific code snippets is often easy but fails to scale and provide real value. Reuse via off-the-shelf packages is great - but in many organizations - this one has already been tapped. This brings us to Reuse Through Reference.

Services are a great mechanism for providing reuse through reference - however, many people seem to forget one simple item: REACH.

Reach describes the 'reusability potential'. Imagine having 10 systems 9 of which were in COBOL mainframe apps and the 10th was a .Net application. Let's state that the COBOL applications don't have the ability to access the native services provided by the .Net application, but do have the ability to talk Web services. Interesting - I just stated that it can speak "Web services" - does that mean WS-I basic profile? Which other WS specs does that include?

In an attempt to increase reuse through reference, we (the enterprise architects) are finding the need to increase reach. This means that we must identify protocol ubiquity levels within our organizations and quickly create critical mass.

Generally speaking there are two methods for increasing the reach:
1. Modify the connector capabilities at the endpoints (COBOL apps, etc.) via service enablement (WS-PaintJob)
2. Provide protocol mediation/translation in the network.

WS-PaintJobs are an easy way to black box systems and increase reach. However, the total number of protocol permutations between any given client and any given service grows exponentially with the size of the service network. This leads to the realization that a protocol mediation strategy is not only useful but mandatory.