Manage Learn to apply best practices and optimize your operations.

Taking a middleware approach to app modernization

The middleware approach is a popular method for app modernization. Tom Nolle explains what developers need to know about this approach.

Research from firms such as Capgemini confirms that many organizations are placing increased pressure on IT to...

modernize applications. However, not all these IT departments are going about it the same way, and a method that works for one may not necessarily work for another.

In this feature, Tom Nolle walks us through what we need to know about a popular approach to modernization -- the "middleware" approach -- explaining how to ensure it is the right method for you, how to simplify your process, and how to prepare for the future.

Application modernization (app mod) has been an issue for planners and architects for some time, but the convergence of business agility trends, online customer/supplier relationships, componentization of software, and cloud computing has made the problem acute for companies who've been able to put off modernization up to now. Many of the app mod options available involve "middleware" -- tools that live between applications and users. To be sure a middleware-based path to app mod gets you to the right place, look first at the future application model in a holistic way, find the easiest path that gets you to where you need to be, and make sure your middleware choices will support your future in a broad sense.

Middleware augments basic operating system or network-resident services, in most cases by packaging them into higher-level features/services that facilitate and standardize development. Major software companies like IBM, Microsoft and Oracle all have extensive middleware tool inventories, designed to support everything from database operations to communications. While all of these products are flexible, and third-party "best-of-breed" options for middleware tools offer even greater flexibility, you can't afford to let middleware run amok in your software -- costs and risks will rise through lack of standardization, particularly in ALM. You have to take a unified view.

Companies whose applications are sourced from one of the major software companies noted above should start by looking at the application model those companies support, and how middleware supports that model. Most applications today are either transaction driven or analytics driven, with the former deriving input from users on a network and the latter being an offline examination of stored data. The prevailing application model for transaction-driven applications is the web front-end model, and implementation of this model will often involve creating web inputs to existing applications. The application model for the analytics-driven application is really determined by database design, so database middleware is the key thing to explore.

In the transaction-driven application model, web servers provide the UI and feed application processes through a gateway interface. CGI was at one time the de facto gateway standard, but other middleware approaches are emerging. One that gets a lot of interest is WSGI (Web Services Gateway Interface), which is both a specification with web-to-application interfacing rules and a model for middleware (often available in the popular Python language). WSGI is generally more flexible than CGI and middleware based on it is often capable of higher performance and resilience.

To be sure a middleware-based path to app mod gets you to the right place, look first at the future application model in a holistic way.

In database-driven applications, one of the most complex questions is whether it's necessary to shift from a classic SQL model to a no-SQL or even unstructured (Hadoop) model of data storage. Most business applications tend to use SQL queries, and so it's important in database-driven app mod to find effective SQL middleware for your primary vehicle for data access. Recently, the Spark project has generated a lot of interest and vendor support as a Map-Reduce (like Hadoop) database model that is significantly faster in execution. The speed difference versus Hadoop could make Spark a viable basis for analytics app mod even where SQL is heavily used.

Whatever middleware features are needed, it's also important that the middleware exchange data with the applications in an efficient way. That means insuring that the front-end interface to the applications can link with the middleware. For databases this is largely a matter of supporting the query interfaces used or expected, but for transactional applications there is likely to have to be a message or service bus injected between the web front-end and the application.

All the major software vendors and many third-party vendors offer message/service busses, and some CGI/WSGI tools will include them. Enterprises often use J2EE as transactional middleware, and it includes service bus support. Because it's often easier to use a single high-level middleware tool than several lower-level ones, explore the application architectures of your primary vendors first and dip into specialized middleware choices when you can't find what you need at the higher level. That will also help guide you in insuring the lower-level tools work in your high-level framework.

If you're developing web front-ends from scratch, it may be useful to consider "do-it-yourself" middleware. Most web-related languages (Python, Ruby, JavaScript, and Java) will support the development of "middleware" in the form of standard function implementations that can then be incorporated in web pages/software as needed. This practice can standardize the way important features/functions are implemented, reducing development cost and time and also improving debugging and reducing software errors.

The final point to consider in middleware-driven app mod is that software choices often live long past the activities that generated the need to choose in the first place. Middleware is an element in nearly all componentized applications and is increasingly a part of cloud application design and development. It's highly inconvenient, to say the least, to have to change middleware strategies a few years down the line. Look ahead to where your applications are going and what your hosting strategy is likely to be in the future.

One area often neglected in future-proofing middleware used in app mod missions is flexibility of integration. In componentized software, message/service busses are often used to link components, and so if you pick app mod middleware that includes such a bus, be sure it can be adapted easily to component workflow management later on. Similarly, cloud-hosting of components for failover and cloud bursting will require load balancing, which middleware supports in many ways -- some of which are not cloud-optimal. Check to be sure your app mod choices don't stall your cloud evolution.

That may be the most critical point of all in a middleware approach to app mod. Projects are almost inherently susceptible to "tunnel vision;" planners look for solutions to the problem they've been presented and not the best solution overall. "Modernization" doesn't stop with your current mission; it is essential to keep it going as your needs and IT infrastructure evolve over time.

Next Steps

Test your application modernization know-how

Check out our guide to application modernization

Discover the keys to successful modernization

Learn how to deal with a legacy infrastructure

Understanding component coupling and middleware

This was last published in July 2015

Dig Deeper on Legacy application modernization

Join the conversation

1 comment

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

Are you using, or planning on using, middleware as part of your app modernization approach? Let us know about your experiences.