Your key products for enterprise application integration

Middleware suites and application integration

Applications today are normally built on a set of communications, work and component management tools, collectively called "middleware." Many businesses have a dominant IT and application vendor and, if you're one of these, you should always look first at the comprehensive middleware suites from your vendor. These will often include all of the enterprise application integration products you'll need, and they have the advantage of being offered in a coordinated package from a single source you're already familiar with. Even some users who don't have a dominant vendor may want to look at these suites to reduce finger-pointing -- which happens often with multiple component vendors -- and installation complexity.

The major IT software companies such as IBM, Oracle, Microsoft, HP and Dell have collected middleware suites designed for coordinated deployment and operation. If your company relies on one of these major vendors for hardware and software, your first question should be whether their middleware suites are suitable to meet your enterprise application integration needs. The following points will help you determine whether your primary vendor's suite is likely to be a fit.

If your company is workflow- or directory-driven based on service-oriented architectures (SOAs), then consider IBM. IBM's WebSphere software is aimed primarily at SOA, and it provides a service/integration bus, directory management and component addressing. There's even cloud computing integration for hybrid cloud applications. The downside to IBM's approach is that it's primarily aimed at larger firms with considerable internal software development activity.

For smaller businesses dependent on SOA, consider Microsoft's middleware tools. Microsoft has a complete set of Web services for SOA, including directory services and service busses, and these can extend across the boundary between the data center and a Microsoft Azure cloud service. Microsoft's SOA technology tools are particularly adept at integrating applications and components from multiple vendors, and they're targeted at every business size.

Companies that are more Web-driven than SOA-driven may find other middleware a better fit. Oracle is a premier provider of Web software tools and also the owner of the popular Java development environment. J2EE, the enterprise-business version of Java, includes a service bus and directory management tools, and these can be added to other Java editions from either Oracle sources or third parties. In addition, Oracle has an Application Integration Architecture product family that can provide agile business integration across applications and even enhance mobile application support. Oracle doesn't make hardware, though, and before considering Oracle as software for your company, note that their application integration tools work best when there are some Oracle applications involved.

Companies that have large server farms, distributed servers in multiple locations, or that contemplate a large server purchase might find a computer vendor like Dell or HP a better contender, because they provide a unified infrastructure. These vendors are single-source providers of applications, operating systems and middleware, and applications and can also provide integration services. Even where they have application relationships of their own, they tend to be accommodating of other application choices.

Application integration workflow products: Service/message busses

Where a middleware suite is not available or optimal, you'll have to pick application integration products separately, and the best place to start this is workflow integration. Workflow products will handle interfaces, message flow and also normally include tools for directory management. There are two options here: a service/message bus or discrete interfaces. Where applications are complex and highly componentized, and where business requirements are highly dynamic, then a service or message bus is usually the best approach. The products even offer business control of work through a simple script-like language, and there is considerable flexibility in data formatting and interface selection to accommodate a wide range of applications and components.

Four vendors dominate in the message/service bus area, in addition to the middleware suite providers. They are Fuse, MuleSoft, Talend, and Tibco, and while they offer the same general capabilities, users will likely find significant differences in the details.

Tibco has arguably the most broadly integrated and capable of the bus integration products, and reportedly the highest performance and strongest ability to accommodate all possible applications and partners. They also tend to be expensive and complex to use. Fuse, Mulesoft and Talend are all open source-based, which means licensing costs are lower. However, nearly all users will want to purchase support contracts, so these products are not truly "free," and integration efforts are likely to be higher with these products because of their relatively narrow feature range.

Fuse has strong Red Hat JBOSS roots and is ideal for companies with a specific commitment to Red Hat Linux or strong open source opinions. Mulesoft is the most integration-friendly of the open source bus-based products, and Talend the most data-oriented of that group.

Message/service busses are probably overused as often as used properly. Don't assume you need this product class -- assume you don't unless you have many complex applications from multiple sources. In most cases, simple applications and in particular Web-centric applications are best handled using discrete interfaces that are native to all operating systems and middleware.

Directory and interface integration and object brokers

Service/message busses provide component linkage and workflow control. SOA and REST define interface models for applications and components. Because basic workflow and directory services are mandatory for all applications, standard vendor middleware will provide all the enterprise application integration tools you'll need for virtually all RESTful applications, and for many SOA applications.

Where standard vendor middleware may fall down is where you have to mix applications from many sources or deal with connections to out-of-company partners. For these situations, if your needs don't match service/message bus products, you may want to consider a third class of integration tools: object brokers.

Object brokers support the long-established Common Object Request Brokerage Architecture (CORBA). They expand basic middleware tools that interface among software components and create a more architected, adaptable and flexible framework for building applications by calling diverse components. They are explicitly a part of application design and componentization, so to adopt them you'd either have to buy applications based on CORBA or build them yourself. Industry trends seem to be moving away from object brokers and CORBA, albeit slowly, so you should take care before undertaking a new development project based on CORBA. Because there are literally thousands of existing CORBA applications, it will remain a factor in enterprise application integration for some time.

There are two primary CORBA offerings, Orbix and VisiBroker, both from Micro Focus. VisiBroker is the more generalized of the two and the most widely deployed both in terms of number of users and industry breadth. Orbix is widely used in financial, telecommunications and transportation applications. Because CORBA is justified in part by its ease in supporting application connections across company boundaries, it's wise to pick the product most used in your own industry.

CORBA and object brokerage is difficult to justify in small businesses, so if you are a small business, it would be better to look to the basic tools for interface and directory integration provided by your standard middleware, the exception being if you are already committed to CORBA due to trading partner relationships or existing applications.

Deployment and operations integration

Virtualization and cloud computing have added a dimension to enterprise application integration because they've introduced the notion of dynamic resources for hosting applications and components. In addition, the trend toward building highly componentized applications has made the task of deploying an application a complex and error-prone one. Integration obviously requires finding the components in order to link them, so elastic assignment of component hosting points impacts integration significantly. Automation of deployment and redeployment reduce risks, which is why they're important.

Any discussion of deployment and operations integration products has to start with the two dominant tools, Chef and Puppet. Application vendors, hardware vendors and operating system vendors will normally offer one or both of these products to their users, and it's important to understand the primary differences not only to support a selection where both are available, but to understand the trends in deployment and operations.

Chef is based on scripts, which means that you use Chef by writing specific instructions for deployment. For companies that are used to deployment scripts for loading applications, Chef is often an easy transition. Puppet is what is called a model-driven approach to deployment operations. It's a descriptive language that models the outcome desired, and a processor that converts the model into steps to achieve that goal.

Script-based or "procedural" approaches like Chef are favored by the majority of users because they evolve naturally from current practices, but model-based or "declarative" operations tools seem to be the industry trend. That's because a model-based approach can be applied more easily in cloud environments where deployment conditions will vary depending on where you put things in the cloud. However, you'll want to look very carefully at Puppet tools to ensure you like the framework your vendor supports. Both Chef and Puppet are part of separate suites of related applications, and the total mix can be dazzling or intimidating.

Generalizations in the area of DevOps tools are always risky. Typically, Chef is more flexible but also more difficult to learn. For simple deployment and operations tasks, Puppet may be a better choice.

It's possible to use both Chef and Puppet in the cloud, but cloud deployment and operations has its own set of tools. If your applications divide cleanly into portions that are cloud-hosted and portions that are data-center-hosted, it might be best to use a cloud-based tool for deployment and operations of the cloud portion. Amazon's OpsWorks is the most widely used cloud deployment and operations tool. It's based on Chef, which means it is more easily integrated with Chef to manage deployments that involve both the public cloud and the data center.

If you want something more cloud-centric, an emerging option is a standard from the Organization for the Advancement of Structured Information Standards (OASIS) called TOSCA (Topology and Orchestration Specification for Cloud Applications). TOSCA is a combination of a script and model approach that has great potential for both cloud and data center deployment and operations, but it's very new. The leading TOSCA product is IBM's Cloud Orchestrator. If you're an IBM account, Cloud Orchestrator is an exceptionally strong solution, but it would be difficult for a non-IBM company to adopt it.

One vendor, at least, believes that the future lies in a broad and dynamic total-automation toolkit. Automic offers a comprehensive business integration and automation product. They offer workload, service and release automation for a variety of platforms that include most of the data center and cloud resources a company is likely to be using or considering. As a full-spectrum solution to enterprise application integration, they may be unparalleled, but they are also likely to be the most difficult to integrate with current applications, tools and practices.

Ensure that future and current needs are met

At the leading edge of "application development," applications are ad-hoc compositions built through automated deployment tools and employing agile workflow steering. The traditional notion of static applications is already becoming obsolete, and so what you need to build applications and link them into business processes is converging on a single set of tools. Deployment in the data center and in the cloud is converging on another set. Over all of this, there are early signs of a more business-centric integration vision that accommodates agile components and agile resources.

That's the future your enterprise application integration must target to be valuable to you in the long term. IT is changing faster than ever before, so it's important to be sure that your future needs as well as your current ones are considered, and your vendors' future directions are assessed as carefully as their current products. No matter what your business needs dictate, the best options are the ones you can live with the longest.