Here are a few general middleware-related considerations an architect should keep in mind when designing e-Commerce solutions.
Sophisticated e-Commerce solutions often end-up consisting of many different (and sometimes incompatible) pieces of technology. Middlewarevacts as:

1. The glue that enables architects to pull together the solution
2. A bridge enabling architects to get disparate architectures to interoperate

Middleware often comes with arcane user interfaces for the programmers and professionals who apply the product. Recently, many middleware vendors have taken steps to embed their products into major development tools. This situation allows middleware products to take on the look and feel of the hosting tool.
Check with your tools vendor to see if they, or third-party add-on companies, offer wizards and other easy-to-implement tools that bind together the development tool and the middleware.
Nonetheless, not all middleware products have taken this path. The vendors that have taken this path still require significant training to grasp the functionality of middleware. Assume that any new middleware choice will require a steep learning curve.

Middleware is a software layer that allows multiple processes running on multiple machines to interact across a network.
Although middleware can run on stand-alone computers that are not connected to a network, the subject of middleware is interesting because it represents an extremely powerful way to develop fully distributed software systems and applications. As distributed systems evolve into essential information utilities with global reach, the role of middleware becomes even more important, because it is the software glue that allows business, government, and personal systems to communicate and interoperate. In the context of this module, the word interoperate means that two or more computer systems running different software or operating systems can exchange information or applications. The development of large-scale middleware systems was motivated by many technological and economic factors. Three of those factors are described below:

1. the growth of client-server computing ,
2. the need for enterprise-wide integrated computing solutions
3. and the birth of e-commerce.

This module describes how these developments motivated the design and introduction of increasingly powerful middleware models and implementations. Although the term client-server computing initially referred to the use of personal computers (PCs) on a local area network (LAN), a more general model emerged during the 1980s. This development was spurred by the migration of mainframe applications to a more flexible and cost-effective client-server environment. A client is a computer or software process that requests services, and a server is a computer or software processes that provides those services. An example of a service is a database server, a file sharing system, or a Web server. The client-server model represented a break from the older mainframe model, where dumb terminals directly connected to intelligent central servers or mainframes

Not all middleware comes with its own management functions. Additionally, not all middleware fits into standard applications, networks, and systems management product suites (e.g., OpenView from Hewlett-Packard, ZenWorks from Netware, CA's Unicenter). Consequently, middleware can make QA and debugging tasks more complex.

Unlike major database and development tools, many middleware packages are not updated in predictable cycles. Another problem with middleware vendors is that they often consolidate or disappear. The result is that maintenance of EAI-based integration code can carry maintenance risks. All of these issues contribute to the following possible maintenance headaches: