Component Technology Today

• 09/04/2000

In terms of the underlying technology, Sun’s Java, JDBC, EJB (Enterprise Java Beans), and J2EE, has been embraced, at least to some extent, by everyone except Microsoft. That means, the underlying scripting language is Java, the relational database access middleware is JDBC, the reusable object model is EJB. For the uninitiated, J2EE defines multi-tier enterprise applications, based on the standards listed above (and then some) plus extension capability for Java Servlets API, JavaServer Pages and XML technology. The J2EE standard includes complete specifications and compliance tests to ensure portability of applications across the wide range of existing enterprise systems capable of supporting J2EE. However, the J2EE standard does not specify enough functionality at this time to create a complete platform to support enterprise component applications. It appears inevitable that vendors who embrace EJB will establish their own extensions and additions that may not exactly be standard.

XML is as fundamental a technology as Java. But there are two sides to XML -- messaging and data formats. Every vendor supports XML for messaging, but will they support the same schemas? Schemas are replacing DTDs (Document Type Definitions) as vocabulary/specifications for data definitions. Microsoft has taken the lead in terms of XML with BizTalk and the BizTalk server and portal, and is busily establishing industry-related content and serving as a clearinghouse for the development of such content. It is quite possible that other vendors may support conflicting schemas.

The good news is that we are close to consensus on the underlying standards, and it is possible to hedge one's bets in several of the environments. One could implement a component solution that could utilize an Object Request Broker, be J2EE compliant and also utilize XML for messaging and for schemas. This combination approach open to several ways to interoperate, would be appropriate for companies and vendors getting into the space today, as it is really unclear which vendor or vendors will predominate and which technology set will provide the greatest benefit.

Planning for a Component Environment

General consensus says that, starting today, it would take a well-run enterprise two years to build an enterprise-scale component application – mostly because of the lack of tools and the lack of skills in the marketplace. Given that, however, it is certainly possible to plan for component development today. Especially as there is a lot to do in terms of determining component boundaries, services, interfaces, and XML messages and the enterprise’s message architecture.

The goal is to plan for a significant amount of reuse and to eliminate redundancy. An approach is to determine the end state, an Enterprise Component Specification. That is, how the enterprise’s application would be broken up in to separate components and then create a plan on how to achieve that goal. In general, no company has a green field; there are a lot of legacy systems to contend with. And no company can sit still and develop the component architecture of the future for several years and not meet time to market business needs, especially the growing demands for e-business and e-commerce applications.

Developing the Enterprise Component Specification is essential. Once that is accomplished a gap analysis can be performed to provide data for a plan. The gap analysis should be performed on a component basis, so that for each piece of the puzzle one can determine what exists, what has to be built from scratch or acquired, and what can be modified to achieve the overall vision. The analysis should also include for each legacy system what additional functionality is included and where that functionality should go in the component world. The gap analysis should also make recommendations on wrapping parts of the legacy code to work in a component environment. The decision to wrap or not will be based on several variables, including the state of the code, the amount of modification required on an ongoing basis, and how close the code is to providing the services specified in the Component Specification.

Following the gap analysis, the plan can be accomplished. The plan should include a timetable, checkpoints, costs, funding source (whether ordinary maintenance could cover the necessary modifications over time), and metrics. Part of the plan would be to determine the technical architecture, and how the specifications would become reality. It will be important to establish an organization to monitor progress and update the plan, as this will probably be a multi-year effort.

Since we are talking about a significant effort, even though the technology choices are not very clear today, it is important to begin planning in order to reap the benefits of componentization tomorrow. In a May 2000, Gartner Monthly Research Review, in an article entitled, “CBD is Becoming the Dominant AD Paradigm”, the author states, “Every IS organization should have a CBD strategy in place and begin to execute it – even if the migration plan is conservative and futuristic.”

Related Editorial: