As computing moves from mainframe systems to the world of Web-based distributed, networked systems, components play an crucial role in integrating and aggregating parts of an enterprise system -- particularly when sending and receiving transactions between wired systems and wireless ones, those with limited memory and small display size.
The most important promise offered by components is that they're reusable. This allows designers to save time and reduce errors when they're creating new systems or modifying existing ones. Designers can reuse, mix, and match components as the business requirements in heterogeneous systems change.
Other promises that the integration of components offers to the world of wireless include component middleware, building block frameworks, component-based software engineering, and Web engineering. Naturally, there is a down side.
Component technology has also brought with it such problems as its inability to pass through firewalls effectively, the unavailability of desired components, a high rate of project failures, and the inadequate or missing risk-analysis capabilities of component-based enterprise systems.
Before I elaborate on the promises and problems that integrating components carry, let's define a component for the purposes of this article.
Let's first take a look at two approaches of component integration: The top-down and bottom-up methods:
- The top-down approach: The software engineering world defines a component as "one of the parts that make up a system...and may be divided into other components" (from the Elucidata Services glossary listed in Resources).
- The bottom-up approach: This approach, on the other hand, defines the basic component as the foundation that the designers can use as a building block for a system of more complex components and its relationships among them.
With either approach, you can consider components at both object and abstraction levels. A component at the object level is a collection or group of objects that are related to each other in some way. Components correlate to building, testing, implementing, or deploying applications and providing application, interface, environmental, or system services. Each component interfaces, integrates, and interoperates with other components in a predefined architecture that can either hide or show implementation details. When the life cycle of a component of objects reaches its end, it can repeat itself in a certain number of loops, proceed to the next component for implementation, or be aggregated with other components as a published service in a directory or as wireless portals of Web services.
A component at an abstraction level is a "potentially standardizable or reusable exposed interface" (from the Component Software Glossary in Resources). At a lower level of abstraction, you can look at object services designed as reusable components, while at a higher level you can consider different software modules, each one identified as a component to implement an object or exposed service.
Let's examine more closely the promises that component technology offers to the wireless world.
Component technology offers the following benefits to the wireless arena:
- Component integration at various levels
- Component middleware
- Building-block frameworks
- Component-based software engineering
- Web engineering
- Web services
In turn, let's look closer at these features.
Component integration at various levels
At macro- and micro-levels, component integration can be accomplished through contracts between clients and servers at both these levels. Integration at various levels is important to designers who need to understand how each level is related to, associated with, or linked to another from an enterprise standpoint.
Examples of micro-component integration include such tools as SOAP (Simple Object Access Protocol) and HTTP (Hypertext Transport Protocol), used to transport Web services. An example of macro-component integration is the VeriSign Payment Services Payflow Pro commerce component integration that adds online payment to the IBM WebSphere Commerce Suite through the IBM WebSphere Payment Manager. This feature allows merchants to add new payment types and switch banking relationships without installing new software.
Enterprise Application Integration (EAI), Enterprise System Integration, e-commerce, and e-business are other examples of macro-component integration.
Another important part for building enterprise applications is component middleware. The middleware provides request brokers and passes internal messages among components about the next actions a component takes or responses it receives.
Examples of component middleware include entities of which you are probably already aware, such as:
- Common Object Request Broker Architecture (CORBA)
- Java 2, Enterprise Edition (J2EE)
- Microsoft .NET
- Sun ONE
- IBM WebSphere MQ family (formerly MQseries)
- IBM Component Broker Connector (CBConnector)
The CBConnector is part of the IBM Transaction Series product that supports distributed object application environment for integration with back-end databases and transactional systems. The CBConnector Bank User Guide is among the International Technical Support Organization's (ITSO) IBM CBConnector Cookbook Collection. (See Resources for more information on this.)
Enterprise JavaBeans (EJB) and Microsoft .NET are both good examples of component-based frameworks. Each consists of components with specific relationships, including interfaces, and are built on a common architectural framework, such as Enterprise Component Framework (find more information in Resources). You can represent each of these frameworks as reusable mechanisms in both the design and deployment stages in a life cycle.
In addition to components, design patterns are associated with frameworks for use in the design and the documentations of frameworks. They can be used in any application that the framework uses to run in its own application domain (such as, the design results may nearly look the same regardless of the framework type).
Component-based software engineering
The field of component-based software engineering, or CBSE, is designed to address the concerns of component technology in software development. CBSE concerns itself with three main topics -- component specification, component implementation, and component deployment.
Component specification focuses on two function types -- interface functions and extrafunctional properties. Interface functions of a component are used to communicate with its environment through interfaces, say, within a framework, while extrafunctional properties define the overall behavior of a component, such as time properties (latency), reliability, and availability.
CBSE focuses on frameworks (and patterns), highlighting the important role they play in implementing and deploying components. CBSE is Web engineering's counterpart.
Web engineering is specifically targeted at the design, analysis, implementation, and deployment of large, complex Web-based systems.
Software engineering began in the age of "tightly coupled" IT systems and evolved over the years to cover systems defined as "loosely coupled" components of objects that call or wait to be called by others in a framework. Web engineering emerges as a special form of software engineering for building and implementing loosely coupled Web services or other types of Web-based systems.
These loosely coupled components are associated with various messaging services among component-based systems -- IT, Web-based, and Web services. An example of this type of messaging service is the IBM WebSphere MQ family.
Service directories are the most important feature of Web services. They allow information and services to be consumed by any device, regardless of place or time. Business users across the Internet can register, provide, discover, and consume services regardless of the technologies used to transmit information and services. They can externalize Web services with business processes standards, giving them a common view of how business transactions should be processed over the Internet.
Of course, these benefits don't just fit into the proper place with no effort. Let's look at some of the stumbling blocks to providing these component-integration benefits to the wireless world.
Problems to providing these component-integration benefits to the wireless world include:
- Firewalls
- The high rate of project failures
- Non-availability of desired components
- Inadequate or missing risk analysis
Each of these problems adds risk to integrating components in both the micro- and macro-levels of enterprise systems.
The use of HTTP for transport of SOAP-based Web services and component-based systems can traverse firewalls in a heterogeneous environment. Other transport possibilities are Remote Method Invocation/Internet Inter-Orb Protocol (RMI/IIOP) for CORBA, Instant Messaging, and the IBM WebSphere MQ family.
The problem is that while firewalls provide secure wireless Web services and multicast, they can make user interaction and collaboration more difficult since users are spread across networks. This is also particularly true for users that need to access different component-based application domains.
Another problem with firewalls is that they can block certain tagged HTML elements needed for communication with such mechanisms as CORBA or DCOM.
The high rate of project failures
In spite of promises by component-based enterprise integration to reduce costs and save time by integrating similar functionalities into back-end Enterprise Resource Planning (ERP) systems, many projects failed. This also applies to integration efforts for Supply Chain Management (SCM) and Customer Relationship Management (CRM) systems as front-office functions to wirelessly manage customer data and automate supply chain.
An ERP system is "any software system designed to support and automate the business processes of medium and large businesses" (from SearchEBusiness, listed in Resources). Mary Sumner defines SCM as the "oversight of materials, information, and finances as they move in a process from supplier to manufacturer to wholesaler to retailer to consumer...involves coordinating and integrating these flows both within and among companies" (from her article listed in Resources). A CRM system is an enterprise-wide system "that allows companies to manage every aspect of their relationship with a customer" (from SearchEBusiness, listed in Resources).
Among the many reasons for project failures, Sumner lists risk factors in enterprise-wide projects in seven areas:
- Organizational fit (failure to redesign business processes)
- Skill mix
- Management structure and strategy
- Software systems design
- User involvement and training
- Technology planning
- Project management (failure to recognize the risk of time and cost scope expansion)
Other reasons include poor training strategy, lack of or inadequate risk management program, and a non-existent project management office. The project management office allows the implementation of various processes in a three- to five-year plan, such as starting with life-cycle and cost management, and ending with risk and enterprise management.
Reusing components and objects to build a service or system is always faster and costs much less; however, these components are often not available.
While public directories (such as UDDI) are used as a repository of Web services, this idea has not been extended to other parts of the world of component technology. While Web services are considered beyond computing, this technology has not yet reached full maturity point. This means components that could be mixed and matched for a Web service may not available for public discovery and consumption.
Inadequate or missing risk analysis
When risks to wireless component-based systems are not mitigated to more tolerable levels, risk analysis is inadequate. This means assets and their valuations, tangible and intangible, are improperly or inadequately identified.
This also holds true for vulnerabilities -- the weaknesses or defects in systems that could be exploited by hackers to attack the systems. In fact, not analyzing and managing risks related to vulnerabilities is even more important than properly identifying assets. It is more prohibitively expensive not to implement a cost-effective disaster recovery plan than to spend the time, money, and effort to put one in place.
No matter the evolving, emerging, or break-through promises that component technology brings, dormant problems will surface if not quickly and properly handled in a fast-changing networked wireless world. Problems such as:
- Firewalls that block certain tagged HTML elements needed for communication with such mechanisms as CORBA or DCOM
- Firewalls that can make user interaction and collaboration difficult when users are spread across networks
- Nine specific risk factors at cause for failures in enterprise-wide projects, including getting the wrong organizational and skills mix
- Necessary components that are unavailable
- Inadequate or missing risk analysis
The challenge is to provide components in such a way that you can reuse and re-integrate them across frameworks, application domains, and enterprise systems over the Internet. In this way, components can offer such benefits as:
- Allowing users to add new features and switch interaction relationships without installing new software
- Easier enterprise-application crafting through component middleware that provides request brokers for horizontal infrastructure services and connector mechanisms
- Frameworks that can be represented as reusable mechanisms in both the design and deployment stages in a life cycle
- Component-based software engineering (CBSE) to address the concerns of component specification, implementation, and deployment
- Web engineering, specifically targeted at the design, analysis, implementation, and deployment of large, complex Web-based systems
- Service directories (a feature of Web services) that allow information and services to be consumed by any device, regardless of place or time
Whatever component technology you use for integration into systems, delivering projects on time and within budget while mitigating risks at more tolerable levels is important.
- For more on commerce component integration, check out the VeriSign Payment Services Payflow Pro commerce component for IBM WebSphere Payment Manager.
- Familiarize yourself with the IBM WebSphere MQ family, middleware that integrates more than 35 platforms, provides the base messaging functions for servers and clients, and assures once-only message delivery.
- IBM Redbooks introduces you to Component Broker Connector (CBConnector), a member of the IBM Transaction Series product family. CBConnector supports a distributed object application environment that integrates business objects with back-end databases and transactional systems.
- And here is a Redbook user guide for installing and running the CBConnector Bank, a sample bank application developed for Component Broker Connector 1.2.
- The author offers a developerWorks series on "Human-facing Web services":
- "An introduction to Web Services Experience Language" covers the development of two specifications on human-facing interactive applications -- Web Services Experience Language (WSXL) and Web Services Remote Portals (WSRP) (September 2002)
- "Building applications"covers leveraging reusable components, workflows, and business processes (October 2002)
- "Build portals with WSRP" covers extending the functionalities of the WSXL component services (January 2003)
- A good paper on components and frameworks is Cris Kobryn's "Modeling components and frameworks with UML," Communications of the ACM, Vol. 43, No. 10, October 2000 (a subscription is required for full-text access).
- For more on defining and deploying components, read Ivica Crnkovic's (et al.) paper, "Specification, Implementation, and Deployment of Components," Communications of the ACM, Vol. 45, No. 10, October 2002 (a subscription is required for full-text access).
- Other related papers from the Communications of the ACM include: Michael Stal's "Web Services: Beyond component-based computing"; Paul Fremantle, Sanjiva Weerawarana, and Rania Khalaf's "Enterprise services"; Jeff Sutherland and Willem-Jan van den Heuvel's "Enterprise application integration and complex adaptive systems"; and Upkar Varshney's "Multicast over wireless networks."
- For more on SCM, read Mary Sumner's "Risk Factors in Enterprise Information Systems Projects," Proceedings of the 2000 ACM SIGCPR Conference on Computer Personnel Research, Special Interest Group on Computer Personnel Research Annual Conference, ACM Press, 2000 (citation and abstract only; full text requires subscription).
- Janet Wilson's, "Turning Work into Measurable Results" (Financial Executive Online, June 2001), explains the necessity of establishing a project management office.
- IBM and developerWorks offers a multitude of articles on component integration throughout its technology topic zones.
- I used the following references for industry definitions and integration case studies: Elucidata Services; the Component Software Glossary; the Free Online Dictionary of Computing; and SearchEBusiness.com.
Judith M. Myerson is a systems architect and engineer and a freelance writer. Her areas of interest include middleware technologies, enterprise-wide systems, database technologies, application development, network management, distributed systems, component-based technologies, and project management. You can contact her at jmyerson@bellatlantic.net.
Comments (Undergoing maintenance)
Table of contents
Local resources
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
