11.3 Quality Attributes

Quality attributes are desired system qualities against which a system can be measured. There are two broad categories of quality attributes [Bass 98]:

• Observable via execution. Examples include performance, security, availability, and data integrity.

• Not observable via execution. Examples include modifiability, portability, reusability, and integrability.

In addition to the qualities that apply directly to a system, business goals, such as time to market, cost, projected system lifetime, targeted market, rollout schedule, and legacy systems use, also influence a system's architecture.

The following sections consider system qualities inherent in both the transactional approach represented by the J2EE architecture and the nontransactional approach represented by the B2B architecture. In most cases, we use the quality attribute definitions provided by Bass, Clements, and Kazman [Bass 98].

Performance

Performance refers to the responsiveness of the system: the time required to respond to stimuli, or events, or the number of events processed in a specified interval of time. The level and type of communication between components in a system is important because communication latencies can often affect system performance.

Scenario

RSS requires completing most transactions in fewer than 2 seconds. Some lengthy transactions, such as those requiring reports , are exempted from this requirement but are nonetheless expected to perform quickly. RSS currently handles 2,000 transactions a minute. The modernized system must accommodate a 50 percent growth in the user base, increasing this number to 3,000 transactions a minute.

To evaluate performance in each architecture, you must consider the number of interactions required to support a particular use case. Ideally , you would know the percentages of each use case making up the anticipated 3,000 transactions per minute. If you do not have this information, you might evaluate this scenario based on an average number of interactions per use case and then based on a worst-case number of interactions per use case. You will also want to evaluate each of these situations for both success and failure conditions.

B2B

There are several performance concerns in the B2B architecture:

• The amount of message traffic between business objects

• The time that it takes to complete an end-user transaction

• The amount of resources that must be locked at any given time

The amount of message traffic is of particular concern in a low-bandwidth network. Here, available communication bandwidth can be quickly consumed, causing contention , retries, and unpredictable response times. It might make sense to evaluate the scenarios against several possible deployments. These include having all the business objects on the same machine, all the business objects on the same 100MB network, and all the business objects distributed across the lowest -bandwidth connection envisioned in the system. Rough performance calculations could be performed on a sheet of paper. Additional precision may require prototyping and measurement or running simulations.

Given the 2-second requirement, time to complete end user transactions is an issue. Moving from a network database to a relational database, from COBOL to Java, and adding additional levels of security all lead to performance concerns in the RSS target system. Therefore, there is a concern whether any user transactions could complete in 2 seconds, even with relatively low-level loads on the system.

Another concern is the amount of resources that need to be locked in the system at any given point in time. There is likely to be a breaking point at which resource contention will lead to deadlock, causing system performance to rapidly degrade.

For example, the order placement scenario for B2B, shown in Figure 11-2, requires several OAGIS BODs to be transferred between business objects. The exact number can vary considerably. If stock and funds are available, it is 6 BSRs. If stock is not available but funds are available, it is 10. If you must reverse the order because funds are not available, it is 12 plus additional processing. Depending on the company's policy, you might also want to cancel the requisition , although not all companies do so if the items might be needed in the future. An additional BSR must also be accounted for if the order is placed from another system. In the worst case, a transaction updating n records may require 2n BSRs. ^[3]

^[3] High coupling between business objects could also mean that they are not well architected.

To evaluate the effects of BSR-based communication on the network, you must determine the average size of the BODs being sent. In no case are BODs smaller than 2K, including headers and data. Ideally, the actual size of the BODs should be used in the calculations, although a rough number may suffice. The next step is to multiply the average size of the messages by the number of messages per second ”or other time unit ”to determine whether sufficient bandwidth exists for the anticipated message traffic without reaching contention.

Estimating the duration of an end-to-end user transaction is more difficult, as you must estimate data access performance, the number of times data will be accessed, as well as processing and communication time. As B2B technologies are designed for business-to-business integration, the parsing, construction, and communication using BSRs can add considerable overhead in an application such as RSS, for example.

• BSRs have no return value. If necessary, BSRs respond with another BSR (the GET ITEM BSR responds with a SHOW ITEM BSR), or a CONFIRM BOD BSR is returned if the confirmation option is selected in the BOD control area.

• BSRs must be assembled according to a predefined BOD.

• BSR communication requires interaction with an XML parser.

The selection of the communication infrastructure also affects the performance of message-based systems. The selection of a messaging product greatly influences both performance and QoS. Messaging products can offer different qualities of service, depending on the importance of guaranteed message delivery and processing. Messaging products can offer increased performance when acknowledgments are not required, a slower but more reliable service when an eventual acknowledgment is required, or a transactional capability that ensures complete delivery or failure of messages. ^[4]

^[4] For a list of basic MOM products, see http://www.sei.cmu.edu/cbs/mls/links.html#middleware.

J2EE

Performance in J2EE applications is a widely discussed topic in the Java enterprise community because performance is driven by multiple factors. ^[5] However, these factors are a function primarily of application server configuration and application design.

^[5] For a list of more than 100 practices for improved J2EE performance, see http://www.sei.cmu.edu/cbs/mls/links.html#precisejava.

Given the large number of user interactions that a typical J2EE application must support, finite server-side resources must be optimally shared. Such resources may include databases, message queues, directories, and enterprise systems, each of which is accessed by an application using a connection object that acts as a resource entry point. Managing access to those shared resources is essential for meeting high-performance requirements for J2EE applications.

The most difficult part is choosing the best J2EE platform from the large number of options and configurations available. The application server is a critical resource; its implementation must be efficient and must ensure that scalability allows performance to grow in an effective manner.

Application design is also critical in J2EE performance. For EJB, the design of session beans and entity beans, as well as the mapping of entity beans to database tables, can impact performance. For example, implementing an entity bean per table in a database schema will affect performance because a large number of entity beans would be created each time data is needed from tables that have a one-to-many relationship between them.

Evaluation

The B2B architecture and the J2EE architecture have significantly different objectives. The goal of the B2B architecture is integration between business objects. The goal of the J2EE architecture is Web-based application development based on enterprise beans. When these architectures are used for something other than their intended purposes ”for example, using J2EE for B2B integration ”the performance implications must be carefully examined.

Applications based on the B2B architecture do not perform well if the business objects have a high degree of interaction. Therefore, implementing components as business objects is inadvisable if the component requires a high degree of external interactions to perform a task. Also, in the B2B architecture, rollbacks are handled using a compensating transaction or a saga (see Section 8.3). As a result, performance in these systems can degrade rapidly if transactions commonly fail. This is especially true if compensating transactions may also fail.

As a rule, distributed-method invocation adds overhead when communication can be handled effectively asynchronously. ^[6] For example, you may not need to wait for a logging or audit trail method to complete, provided that the infrastructure can provide guaranteed message delivery. A more serious problem is that synchronous, distributed transactions over the Internet or other wide area network (WAN) require locking data records and other resources for the duration of the invocation. Unfortunately, these durations are indeterminate because of unpredictable WAN latencies.

^[6] For asynchronous communication in J2EE, one possibility is to use CORBA, which supports deferred synchronous communication. A deferred synchronous request/response allows an application to make a request to a CORBA object. An empty result is immediately returned. The application can then perform other operations and later poll the ORB to see whether the result has been made available. Other, more sophisticated asynchronous communication can be achieved only by developing an architecture on top of the lowest levels of CORBA.

Security

Security is a measure of the system's ability to resist unauthorized attempts at usage and denial of service while still providing its services to legitimate users. Not all threats can or need to be eliminated. In many circumstances, exposure can be reduced to an acceptable level, using authentication, authorization, signing, encryption, and auditing. For an explanation of these terms and an overview of enterprise information system security, see [Kassem 00].

Scenario

The retailer in our case study has a large number of systems that users must access. Currently, each system requires its own password and implements a widely disparate set of security mechanisms. As these disparate, separate systems evolve to a set of Web-enabled business objects, it is necessary to establish an overall security solution for the enterprise. In particular, end user access must be through a single retail portal that will provide identification and authorization for the entire system of systems. The user's security context must then be associated with all interactions with business objects so that proper authorization and auditing can take place.

B2B

No security is built into OAGIS, because it is simply an XML content specification. Therefore, the MOM transporting the OAGIS BODs must provide the security infrastructure.

Policy Director for MQSeries, a security solution for MQSeries, provides access control services that restrict which users or applications can get or put messages on specific queues. It also allows MQSeries applications to send data with confidentiality and integrity, using keys associated with the sending and receiving users or applications. These services are provided transparently by MQSeries, meaning that existing applications are supported without change.

Policy Director for MQSeries provides an interceptor process that sits between an MQSeries application and MQSeries itself. This interceptor captures all calls made by the application to MQSeries for services. It determines whether the request for MQSeries services is authorized and whether the data in the transaction should be (1) encrypted and/or digitally signed before it is placed in the queue requested or (2) unencrypted and/or signature verified before it is presented to the requesting application. These interceptors receive policy information from a master policy server ”management server ”that is managed by an administration console. These components are identical to the ones delivered in Tivoli's Web access control product: Tivoli Policy Director.

The use of XML in B2B also introduces security concerns because information is transmitted and stored as plaintext. As more and more companies use XML to transmit structured data across the Web, the security of documents becomes increasingly important. The World Wide Web Consortium (W3C) and the Internet Engineering Task Force (IETF) are defining an XML vocabulary for digital signatures [IETF 01]. The W3C working draft of XML encryption requirements provides requirements for an XML syntax and processing for encrypting digital content, including portions of XML documents and protocol messages [W3C 01].

The two primary requirements in security for XML data are (1) encryption to keep confidential information private and (2) digital signatures to provide authenticity, integrity, and nonrepudiation. The problem with XML is that published schemas contain data about the tags used in specific XML documents, and the tags themselves can be quite long. These tags could be used to provide enough known plaintext for an attack.

J2EE

Security services provided by Web components, such as JSPs, Java servlets, and applets, extend to the J2EE architecture. In the J2EE architecture, a container provides an authentication and authorization boundary between external callers and the components it hosts . A caller to a component inside a container has an associated credential that is compared to the access control rules for the target component. The containers implement the security mechanisms on behalf of the hosted components. J2EE security mechanisms combine the concepts of container hosting and the declarative specification of application security requirements with the availability of security mechanisms embedded in the application.

Remote method invocation in J2EE uses the RMI over IIOP. IIOP allows the security context to be communicated with the request, so that the business object receiving the request will have the security identity of the user. This information can be used for authorizing access to services and resources and for providing an audit trail.

Evaluation

The B2B architecture allows components ”business objects ”to be implemented on any platform, but they must rely on the MOM infrastructure to provide secure communications, as well as additional layers inside the business objects to handle security. The J2EE architecture provides almost transparent security mechanisms, as long as all components are compliant with the J2EE architecture. But regardless of the architecture, security technologies should be used in conjunction with appropriate logging, auditing, and recovery procedures.

Availability

Availability measures the proportion of time the system is up and running. Availability is measured by the length of time between failures, as well as by how quickly the system is able to resume operation in the event of failure.

Scenario

Availability requirements in RSS vary, depending on the operations. For example, when a customer purchases an item at the point of sale, the business object that verifies customer funds must be available so that the transaction can be completed. This introduces a requirement for high or continuous availability, especially if stores are open 7/24. These transactions typically require 99.999 percent or higher availability.

On the other hand, transactions such as requisitions from suppliers require a different type of availability. These transactions require the business object to be eventually available to process the request. This allows the originating system to send the requisition and then forget about it. This type of transaction assumes an infrequent failure rate of, say, less than 2 percent. When the transaction cannot be processed, a message must be returned to the system originating the request, and the originating system must be designed to handle these notifications.

B2B

Availability in the B2B architecture depends greatly on the communication infrastructure. MQSeries, for example, provides guaranteed message delivery that supports the RSS requirement of sending certain classes of messages, such as requisitions, and then forgetting about them. Also available are tools that can be used with MQSeries or other MOM products to provide high availability through backup systems, automatic switchover, monitors , tuning, and logging systems.

J2EE

Achieving high levels of availability requires such capabilities as

• Failover. This capability automatically switches to a standby system if the primary system fails or is temporarily shut down for servicing .

• Support for field- replaceable units ( FRU ). This capability allows a component to be replaced in an operational system.

• Support for on-line upgrades. The capability allows upgrading an application and its software to a new version without disrupting the service offered by the application.

• Logging. This feature allows tracing a running application to diagnose the cause of abnormal behavior.

The J2EE platform does not provide API support for these functions. Hence, availability in the J2EE architecture depends on the particular application server. Many J2EE implementations support such features as transparent failover and clustering; tier duplication; real-time scalability, including load balancing, efficient connection pooling, and caching; addition of CPUs (central processing units); and reconfiguration or redeployment of the network architecture.

Evaluation

Availability requirements for different RSS transactions requiring different qualities of service differ significantly. The B2B architecture can adequately support "available sometime" availability. The J2EE architecture is better suited for continuous availability, although the exact capabilities are vendor specific.

Data Integrity

Data integrity refers to the validity of data: a measure of the trust that users have in the data that is delivered by the system. Data integrity is a major requirement for all systems that incorporate databases, particularly distributed databases. Data-integrity issues include two-phase commit, replication, and support for long transactions.

Data integrity can be compromised by human errors entering data, errors transmitting data from one computer to another, software bugs or viruses, hardware malfunctions, and natural disasters. Assuming that these problems can be managed, data integrity depends on conservation of the ACID properties (see Section 8.3) during transaction processing.

Scenario

The classic data-integrity scenario is a money transfer: Money is subtracted from one account and added to another account. If the two account balances are stored in separate database tables, a power outage occurs, and the software crashes between steps, what will happen to the account balances ?

B2B

The B2B architecture commonly describes scenarios that have been designed to eliminate the need for transactions ”in most cases. For example, in an order scenario, an item is reserved until it is determined that the funds are available for purchase, after which the item is purchased and removed from inventory, assigned to an order, or released because funds were unavailable. This process requires additional steps but eliminates the need for transactions in a distributed environment.

OAGIS also provides scenarios that require data redundancy. In this instance, the data required by a business object can be accessed without sending a BSR to a remote business object and waiting for a response. Guidelines for data synchronization, as well as a set of SYNC BODs to support cases of data replication, are also provided by OAGIS. The actual synchronization procedures need to be defined by the organization. In effect, the B2B architecture transfers the responsibility for maintaining data integrity from the infrastructure to the application layer.

J2EE

J2EE provides built-in transaction management. The J2EE platform supports both programmatic and declarative transaction demarcation. The component provider can use the Java Transaction API (JTA) to programmatically demarcate transactions in the component code. Declarative transaction demarcation is supported in EJBs, where transactions can be started and committed by the EJB container. In both cases, the J2EE server manages the necessary interactions between the transaction manager and the database and propagation of the transaction context.

Evaluation

For transactional systems, the J2EE architecture is a better option because it fully supports transaction management. Implementing transactions with the B2B architecture requires the application to maintain data integrity.

Modifiability

Modifiability, the ability to make modifications quickly and cost-effectively, is largely a function of the locality of the change. Modifications include extending or changing capabilities, deleting unwanted capabilities, adapting to new operating environments, and restructuring.

Scenario

The retailer in our case study plans to replace existing systems with a set of distributed business objects. As systems are modernized, already completed business objects will need to be upgraded or replaced with newer , better implementations. Completed systems will need to be modified to use the new business objects.

B2B

Using a messaging system for communication permits dynamic and flexible systems to be built. This allows business objects to be modified, replaced, or added without affecting the rest of the system. However, questions about the sufficiency of the standards that define the interface to the business object remain a major issue.

• How successful is the standard in the marketplace ? That is, how many vendors are supporting the standard?

• Is the standard still evolving? Are competing standards in the marketplace? Is this standard likely to become the predominant one? If not, is there room in the marketplace for more than one standard?

• How well defined is the standard? Are data semantics, as well as syntax, adequately defined? Are compliance tests available? To what degree are vendors allowed to deviate from the standard? In summary, how easy will it be to replace a business object with a different implementation from a different vendor or development team?

Many of these questions are germane in evaluating OAGIS. Several standards potentially compete with OAGIS, including BizTalk, RosettaNet, and ebXML. OAG, the promoter and maintainer of OAGIS, has more than 60 members supporting the OAGIS effort. Supporters include users, software vendors, and solution providers. The ebXML standard, on the other hand, is jointly sponsored by the United Nations Center for Trade Facilitation and Electronic Business (UN/CEFACT) and the Organization for the Advancement of Structured Information Standards (OASIS). Both of these groups cite broad industry support for ebXML.

One ”admittedly nonscientific ”way to get a feel for a standard's pervasiveness is to perform a Web search. For example, Figure 11-3 shows sample searches using AltaVista for RosettaNet, ebXML, and OAGIS. AltaVista found 9,117 results for RosettaNet, 32,311 results for ebXML and 665 results for OAGIS, with the first of these a false positive. As a result, we must consider the viability of OAGIS carefully. A limited number of results can be reasonable if the technology has a well-defined niche.

Figure 11-3. Sample search results for RosettaNet, ebXML, and OAGIS

The stability of the standard is also an issue. If the standard does what you need, you will not want it to change. If the standard does not yet support your requirements, your issue may be how likely it is to evolve. In general, industry standards evolve more rapidly than standards approved by national and international standards bodies.

OAGIS, for example, has the following release history. ^[7]

^[7] See http://www.sei.cmu.edu/cbs/mls/links.html#openapplications-2.

• July 1995: OAG published a white paper describing the approach.

• Jan. 1996: Release 1 specifications for financial transactions are approved.

• June 1996: Release 2 of OAGIS Specifications are released, containing more APIs approved by OAG membership.

• Sep. 1996: Release 3 of OAGIS brings total to 24 APIs approved and committed to by OAG membership.

• Nov. 1996: Release 4 of OAGIS brings the number of APIs to 42 approved by Open Applications Group .

• June 1997: Release 5 of OAGIS completes most of the major ERP-to-ERP integration content required.

• Aug. 1997: The first version of the OAG Middleware API Specifications (OAMAS) is released for comment.

• Feb. 1998: XML is adopted as a metadata language.

• June 1998: Release 6 of OAGIS adds functionality for supply chain integration.

• Oct. 2000: Release 7.0 of OAGIS includes 170 XML transactions.

• Feb. 2001: Release 7.1 of OAGIS published with 182 XML transactions.

• Apr. 2002: OAGIS Release 8.0 announced.

A cursory examination of the history suggests that, although the evolution of the standard has slowed down since 1996, the standard is still evolving rapidly. This may be a concern if stability of the standard is an issue.

Finally, how well defined is the standard? In the case of OAGIS, the syntax for data structures is well defined. However, the specific semantics of the data are left largely to the business objects to interpret. This is true for XML content standards in general. Also, the BOD set is basic. It is based on common business operations, or horizontal requirements, that can be extended by the business object developer, or vertical requirements. Any BODs defined by the developer would, of course, be outside the standard unless these BODs were eventually incorporated into the standard.

J2EE

The J2EE architecture is similar to the B2B architecture, relying on standards to support component replacement [Seacord 02]. When standard business object interfaces are defined, replacement should be relatively simple. When standard business object interfaces are undefined, extensive code modifications would be needed to replace a business object. In our scenario, no generally accepted interface standards are available for an enterprise bean implementation of the required business objects, so modifiability is likely to be a problem.

There may be another problem in supporting the scenario. Although enterprise beans could easily be moved to other application servers on other platforms, performance could be a problem when these business objects are widely distributed across a WAN, as discussed in the section on performance.

Evaluation

Because it promotes loose coupling, the B2B architecture is a better option when modifying or replacing business objects is a concern. An issue arises when the B2B architecture is used to integrate transactional-based applications. This is why nontransactional applications are often limited to transient data exchange and messaging across organizational boundaries.

Portability

Portability is the ability of the system to run in different computing environments.

Scenario

RSS business objects are implemented on the Sun Solaris platform. Microsoft acquires Sun Microsystems and forces users to migrate to a Windows NT platform.

B2B

B2B does not place any restrictions on the implementation of business objects. The portability of these objects depends on their implementations. Also, B2B does not restrict where business objects are deployed, as long as they share a common understanding of exchanged BODs.

J2EE

J2EE is based on the promise of "write once, run anywhere " [J2EE 02]. J2EE works on any platform with a compliant JVM and a compliant set of platform services, such as an EJB container. J2EE platform specifications are published and reviewed publicly . In addition, numerous vendors offer compliant products and development environments. However, J2EE is a single-language platform. Interactions with objects implemented in other languages can be accomplished through CORBA or the Java Native Interface (JNI).

Portability is accomplished using Java transparency of location provided by RMI. Enterprise JavaBeans are also relatively portable to other EJB servers and hence other hardware platforms [Comella-Dorda 00].

Evaluation

The B2B architecture does not address portability. Additional architectural constraints must be placed on business objects if portability is an issue. The J2EE architecture does address portability at many different levels and is one of the principal drivers of Java-based technologies. As long as business objects are implemented as enterprise beans, portability should not be a major issue. Business objects in the B2B architecture could always be implemented as enterprise beans to address portability.

Reusability

Reusability involves designing a system so that a portion of the system can be reused in other development efforts.

Scenario

Business objects developed for RSS may be used in future modernization of other legacy systems.

B2B

Reusability in the B2B architecture occurs at the business object or application level. Therefore, the B2B style of integration ideally suits this particular reuse scenario but does not provide an advantage when building a new business object.

J2EE

Business objects implemented as enterprise beans in the J2EE architecture provide finer-grained reuse than does the B2B architecture. These components may be reused in developing other business components, but because these components provide substantially less functionality than a complete business object, the overhead of reusing these components may outweigh the benefits of reuse.

Evaluation

B2B and J2EE provide reusability at differing levels of granularity. B2B more closely supports the given reuse scenario, but reuse can be effectively applied at both levels.

Integrability

Integrability is the ability to make separately developed components of the system work correctly together.

Scenario

Different business objects are simultaneously developed by different development teams , at different geographic locations, in different time zones and with different cultures: for example, India and Kansas.

B2B

Integrability in the B2B architecture is accomplished through BODs. BODs are predefined XML specification documents (DTDs or XML schema) that contain the message format for the information being exchanged between business objects. Business objects must agree on the BOD(s) being exchanged before they can be integrated.

OAGIS provides a list of BODs that cover common information exchange operations in B2B communication. The OAG is continually adding BODs to satisfy new business needs and requests from the user community. In reality, though, there is no guarantee that all the BODs needed by an organization are defined. In this case, the creation of BODs is required, especially for A2A communication within the same organization. A process that guarantees that all applications communicate using the same BODs is necessary.

J2EE

Enterprise JavaBeans defines a common mechanism for developing and deploying components into an application server. Enterprise beans are required to provide certain interfaces, but they exist largely to support life-cycle management. The bean provider defines the functional API exported by the enterprise bean. The functionality supported by an enterprise bean is not constrained by the EJB specification and is not restricted by the EJB server.

There exists the possibility that independently developed specifications define APIs for replaceable enterprise beans, but these fall outside the EJB specification. Beyond eliminating the potential for architectural mismatch between enterprise beans and between enterprise beans and EJB servers, the EJB component model does little to support integrability of separately developed business objects.

Evaluation

The B2B architecture goes further than the J2EE architecture in supporting systemwide integration of business objects. The B2B architecture defines messages and BODs that can be shared between business objects. J2EE makes no attempt to identify and define these functional interfaces. This is not meant to imply that integration issues do not exist in a B2B environment: They do. The development team must still be concerned that compatible versions of applicable standards ”OAGIS and XML, for example ”and compatible versions of middleware products are used. Data semantics, error recovery, and other integration issues also need to be managed.