Category: 1 - Authoring and Editing Subcategory: 3 - Special Purpose Software Tools and Components
Old Category: Middleware - Interapplication Programming Interface
Vision | ||||
Retirement | Containment | Current | Tactical | Strategic |
---|---|---|---|---|
Standards | |
Industry Usage | SC Usage |
---|---|
Performance MetricsWidespread standardization and interoperability; large supply of components; component reliability. |
Usage and DependenciesIndustry Usage: Microsoft COM+/DCOM and Enterprise Java Beans (EJB) are the two dominant technologies currently. CORBA (Common Object Request Broker Architecture), although an earlier leader in this space, has not achieved wide usage and is declining. CORBA is giving way to XML/HTTP-based cross-platform delivery mechanisms like SAX and SOAP (Simple Object Access Protocol). Distributed COM (or DCOM) is a Microsoft-based standard that is well established in the development community. It includes COM+, the Windows 2000 successor to COM, which now incorporates MTS, Microsoft Transaction Services. CORBA is supported by IBM and Sun and is also widely accepted, although it remains incomplete. Sun also promotes Enterprise JavaBeans (EJB) to support Java environments. Both CORBA and EJB would cost roughly ten times as much as COM for any given installation, a significant factor for the small- to mid-size enterprise. Architecturally a Windows environment should focus primarily on a COM middleware foundation. COM-CORBA bridging allows application development to exploit benefits of both environments. Borland offers a middleware environment that supports both COM and CORBA components. The growth of e-business is forcing many enterprises to adopt multitier, Web-enabled architectures that encourage the use of server-based business components. This, in turn, leads to further adoption of EJB and COM+ as server component models, driving new demand and encouraging a new supply of core components. Enterprises requiring robust support for applications should design them in a component-based fashion. Applications servers also function in this arena, and they require the right combination flexibility, scalability, fault tolerance, and support for the underlying communications technologies. Please see the TPS for Application Servers for more information. SC Usage: A two-tier approach remains valid for small, workgroup-oriented DBMSes within SC. OLE must be retained to support certain legacy systems. An N-tier approach with a middleware layer is essential for the expanded SC services planned for the tactical and strategy time frames. This approach includes tools that support COM services at each of the N-tier levels. SC Application Impacts: SC’s 32-bit applications are to be built primarily on component-based specifications. IMSC uses a multi-tier MTS/COM-based architecture. Plans for ad hoc query and reporting with IMSC and for the SC Information Portal (SCIP) also mandate a robust and secure middleware layer. The eventual replacement of OLE with a COM-based architecture is a natural progression and will not require a technology project in order to be implemented. | ||
Last Update: | Valid Until: | |
---|---|---|
3/26/2001 | 4/26/2001 |
References- |