14.6 Advanced Concept Development

   

---

In this section we will discuss advanced concept development.

14.6.1 The Research Approach

As components move to new environments, the underlying network on which they had previously been used often changes. Different networks offer different types of reliability and quality of service (QoS), and they are managed and controlled in different ways. This heterogeneity is a source of complexity for software architects and designers of distributed applications, especially as the variety of network types and QoS options increases.

Part of the challenge in developing adapter interface technology is reducing the complexity of communication control and providing access to QoS support for distributed applications. Research is conducted into developing adapter communication auto-configuration techniques and "drill-down" methods. Auto-configuration allows adapters to run over different types of networks without having to rewrite communication management code (Huitema 1996). Drill-down methods expose to the adapter different network and transport layer QoS options (NSF 1997). Research in auto-configuration and QoS drill-down is conducted within the framework of a new type of adapter configuration language design.

In addition to the ability to easily move applications across environments, it is also important to be able to construct these applications out of reused components and to be able to easily change the application components. This means that an adapter configuration language must also be powerful enough to describe the properties of the software components and the interactions between software components in a way to make it possible to find and reason about potential mismatches in these interactions (Astley and Agha 1998; Braden et al. 1998; Yellin and Strom 1997). These mismatches include not only parameter or data mismatches, but control-oriented mismatches as well.

The requirements of any configuration language are that it should be easy to use and should be interoperable with existing and evolving standards for information representational languages. There should be a way to associate properties with the components and the connectors of the application, as well as describe how these basic elements will fit together. For communication control, it should be able to express the full range of QoS requirements on connectors for different types of real-time applications and networks. Finally, it is desirable that a full range of GUI tools exist to edit the representational language, and that these tools run on multiple platforms.

The eXtensible Markup Language (XML) is currently a language that meets many of these requirements. It is used for structured document interchange on the Web, as a way of providing application metadata, and as a syntactical basis for a variety of application languages. Examples of these languages include MATHML for mathematical expressions, SMIL for synchronized multimedia, and a schema representation language. As part of our approach, we investigate the development of an XML-compliant representational language in order to fulfill the requirements of our adapter configuration language.

The next section of this paper provides the technical details of our approach. An example of an XML-compliant representational language for adapter auto-configuration called SWWACXML is presented. Because it provides a way to describe component interactions and connector properties, the XML-compliant language we describe primarily facilitates component reuse. It will be necessary to see how higher-level architecture description languages can be used to describe systems and can be mapped down to this type of language (Allen and Garlan 1997; Luckham et al. 1995). This part of the research addresses the issue of providing ways to reuse software architectures.

14.6.2 The Research Tasks

The major focus of the research efforts is toward the development of a language that can be used to describe both the QoS aspects of integration as well as the interaction requirements of the components. We are currently designing an XML-compliant language, SWWACXML, which meets these requirements. Extending a runtime QoS communication control system for use with SWWACXML is investigated in this paper.

Interaction Support for Adapter Communication

Our approach to adding interaction support for adapter-based applications has several primary parts. The first part, described in the sections "Research Approach: Configuration Language" and "Architecture Description Languages (ADLs)," addresses languages that can be used to drive the integration process. The task of using this information to generate adapters is discussed in the section "Building the Adapters with Generated Mapping Code." Finally, we are interested in exploring the utility of a new interaction style based on the way Web-based servers have been interacting with clients. This part of the interaction support research is described in the section "QoS-aware Configuration Language."

Research Approach: Configuration Language

In this section, we focus on the aspects of SWWACXML that allow us to address the task of generating adapters to support component interactions, even in the face of mismatches. The language we describe can be considered a rudimentary architecture description language (ADL). Just as with emerging high-level ADLs (Allen and Garlan 1997; Luckham et al. 1995), we define the base elements of a software system to be components and connectors. Components are the self-contained computational units of the application, consisting of code and state. Connectors capture the interaction (and communication) aspects of the application. The components and connectors have some relationships that define the application as a whole.

Since the goal is to be XML compliant, SWWACXML is composed of <tag attribute> . . . <\tag> pairs, as can be seen in the listings in this section. In SWWACXML, connectors and components of an application are listed explicitly in the <SWWACXML-elements> . . . </SWWACXML-elements> section of the specification. The properties of components that we are interested in are the services provided by a component (exported interfaces) and the services that the component expects to use (imported interfaces). Exposing both the services provided and services needed allows us not only to more easily determine what adapters are needed, but also provides us with information for performing a static check on the intended connections in the application. For example, it is possible to determine from an SWWACXML specification whether any services are missing.

The connectors in the application are explicitly defined and may have properties as well; these are used along with general application communication properties in establishing efficient network connections. These aspects of the language are described in the section "QoS-aware Configuration Language," and a network runtime communication control system is described in the section "Runtime Network Control System." In the SWWACXML specification of this section, we assume connectors are one-way, from a source to a destination. Extending this to a static set of connector types is straightforward and is part of the initial planned language development.

In Listing 14.7, we focus on the MT and MG interactions associated with putting a link into service.

Listing 14.7 MT and MG Interactions

<SWWACXML-elements>
  <Component name=MT>
      <export-interface name="Inservice-result">
        <param name="result" type=INT>
      </export-interface>
      <import-interface name="Inservice">
        <param name="link" type=SHORT>
        <param name="time" type=LONG>
      </import-interface>
      . . .
   </component>
   <Component name=MG>
      <export-interface name="In-service">
        <param name="time" type=FLOAT>
        <param name="link" type=LONG>
      </export-interface>
      <import-interface name="In-service-result">
        <param name="result" type=INT>
      </import-interface>
      . . .
  </component>
  <Connector name=C1>
      . . .
  </connector>
  <Connector name=C2>
      . . .
  </connector>
</SWWACXML-elements>

One thing to notice is that the automatically generated adapters need to occur at the boundary between components and connectors. The components and connectors described in the first part are composed in the <SWWACXML-build> . . . </SWWACXML-build> part of the specification (see Listing 14.8). Given the types of connectors we are initially considering, setting up a connection means providing a source and destination for each connector, and then describing what adapters are needed at sources and destinations. Multiple interactions between the given source and destination components may occur across a single connection. The adapter is where the binding between the names of the imported and exported interfaces is done, as well as the mapping (if needed) between the parameters. In this preliminary version of SWWACXML, the mapping notation is similar to the Nimble notation described in the introduction. The formal and actual parameters in the individual component interfaces; in the adapter, parameter maps can be defined. In these specifications, multiple adapters are described. These descriptions are merged into a single runtime adapter for the component.

Listing 14.8 SWWACXML-build

<SWWACXML-build>
  <client-server connector=C1 source=MT dest=MG>
    <adapter source-name="Inservice" dest-name="In-service">
      <param-map="MG.time = FLOAT(MT.time)">
      <param-map="MG.link = LONG(MT.link)">
      . . .
    </adapter>
      . . .
  <client-server connector=C2 source=MG dest=MT>
    <adapter source-name="In-service-result" dest-name="Inservice-result">
      . . .
    </adapter>
      . . .
</SWWACXML-build>

One important problem to be addressed during the development of SWWACXML is how to formalize the notation used to describe the adapters. Obviously this language needs to be straightforward both to write and to place in the adapters. In addition, it is important that the mapping language have a well-defined definition of what it means to be well formed. The Nimble notation could be the basis of such a language; however, it does not provide a way to express some of the types of mismatch we are interested in handling. For example, in the introduction, we describe a simple control mismatch that could be handled by the adapters. A way to provide for this mismatch and its solution to be specified as part of the adapter specification is necessary.

Generating adapters requires the ability to extract the relevant information from a given specification; for this reason, an obvious first step is to build a tool that can parse SWWACXML specifications. This tool will be the front end of the adapter generator, as well as other tools in the overall system. SWWACXML as described previously is relatively simple, and generating adapters to do the appropriate mapping for the interactions is a straightforward task. We expect this task to become more interesting as the language evolves.

One question that arises is whether or not adapters need to be generated, compiled, and then turned into executables, or whether it would be better for an adapter to interpret these specifications. There are obvious design trade-offs between these choices. In particular, generating and compiling an adapter may be more efficient in terms of runtime performance. However, if we are addressing applications that might move between architectures, either statically (at configuration time) or dynamically (at runtime), interpreting the specification may prove to be the more flexible approach to adapter generation. Part of this research is to study the trade-offs between these approaches in different situations.

The configuration language, as described previously, focuses on techniques to make components more reusable and does little to address reuse of the architectures themselves. One problem is that the language is by necessity low level in order to drive the integration process. We believe that higher-level architecture description languages, discussed in the section "Architecture Description Languages (ADLs)," later in this chapter, must also be part of any advances toward software architecture reusability.

Building the Adapters with Generated Mapping Code

Once the components have been identified, this information is input into our application (product) compiler (assembler). The compiler develops all of the necessary generated mapping codes for each of the previously incompletely represented adapters. The compiled result produces completely represented adapters that can now communicate with each other on behalf of corresponding components' services having now been introduced. And the numerous syntactical mismatches between client and server signatures have been resolved, while maintaining the semantic requirements of each client.

Now a component sending a request for a service provided by another component uses generated adapter-level code to map its request's parameters to the service signature performing the request. The adapter-level generated code maps the request and solves the syntactic interface mismatch (service name, and its parameters order, names, and types) between the request and the syntax of the signature performing the request, while maintaining the semantics required of a client. The generated mapping code is included in the requesting component's associated adapter at compile or interpretation time.

Architecture Description Languages (ADLs)

Applications are often described using a high-level specification of the application (e.g., a MIL- [Prieto-diaz and Neighbors 1986] or an ADL-like approach), which describes components and connectors abstractly. This allows us to deal separately with issues of programming in the large versus the small. Architecture description languages (ADLs) such as Wright (Allen and Garlan 1997) and Rapide (Luckham et al. 1995) provide ways to describe interactions themselves and could potentially be used to describe dependencies between interactions, which are capabilities not provided by SWWACXML. These higher-level ADLs also often provide modeling- or theorem-proving capabilities to allow a designer to reason about the architectureof an application. Despite their strengths, they are generally too abstract to be used for integration purposes.

The SWWACXML notation is a lower-level approach to describing the structure and properties of the components and connectors of an application. Part of this is driven by the need to be able to describe some basic network information. In this notation, connectors may have network-level properties, but the interactions are limited to a static set of low-level primitives. This allows us to reason about how to generate adapters and how to integrate the components of the application into its architecture.

We are interested in developing ADLs that can be used to drive the integration process. This builds on previous work in using high-level specifications to generate and integrate interface software (White 1995; White and Purtilo 1992). However, rather than generating interface code directly as we have done in the past, we intend to extract the relevant interaction information and use it to generate the interaction part of SWWACXML specifications automatically. One of the difficulties in this part of the research is to determine how to decompose connector interactions into adapters. By their very nature, ADLs capture interactions as a single entity; however, at runtime the code implementing an interaction is by necessity spread across more than one runtime element. A general solution to this problem may be unsolvable; however, we hope to be able to find solutions for some classes of interactions.

Web-Based Interconnection

Using XML-like notations also introduces some interesting possibilities for potential interactions. Consider the way SMIL, an XML-compliant language, is used to allow real-time interactions. When it connects to a server, a client receives an SMIL specification. Based on the client's properties, the SMIL specification is translated at the client to HTTP calls that implement one of the protocols expected by the server. In this framework, the client does not have to be tailored in advance to the server; this tailoring is done at connection time.

During this research, we explored the use of a similar approach for client/server interaction for non-Web-based applications. Interactions in general software applications would work as follows. The server has an XML-compliant specification for its protocol or protocols. When a client's adapter first connects, the server's adapter reacts by sending this specification to the new client adapter. When the client receives this specification, it is used to direct the client's interaction with the server. This "use" could either be an interpretation of the specification, or the specification could be compiled into an executable. How the specification is instantiated (i.e., what the adapter looks like) is based both on the client's needs and on the underlying environment (network).

This approach has several advantages that we are interested in exploring. First, the client and server do not have to be tailored to each other, although they still can be if desired. Instead, the client needs only the ability to use this high-level description. Another advantage of this approach is that the protocols do not have to be defined in advance, and new protocols can be added at runtime, which is a style of dynamic reconfiguration that has not been studied. If at runtime a client needs to be changed to interact with a different server that uses a different protocol, the client's adapter could change at runtime based on the protocol exported by the new server. Part of the initial efforts involves both assessing the utility of this novel approach to interconnection and building an integration system capable of allowing this interaction.

It may also be the case that other dynamic reconfiguration (Chowdhary et al. 1997; Hofmeister et al. 1993) styles could be described and facilitated with an approach like this. Recent work in building applications that can dynamically reconfigure themselves has focused on putting as much of the work into the connectors (i.e., the interaction) as possible (Oreizy and Taylor 1998). Making the adapters aware of how to react to situations that potentially require a dynamic change to the application would be a useful step in this direction.

Quality of Service Support for Adapter Communication

It is necessary to develop a platform-neutral QoS-aware language introduced in the previous section for adapter configuration and communication control, along with runtime control mechanisms for network management and QoS control. We will illustrate the generality of our configuration and drill-down approach by demonstrating its use through Web-based applications running over multiple network types.

The major benefit of making adapters QoS aware is the ability to take advantage of different QoS options, to increase the maintainability and portability of adapter communication code, and to allow client/server code to operate over entirely different network architectures without having to rewrite or recompile component code. Our approach is to develop, within the framework of the SWWACXML language described earlier, QoS-aware techniques for adapter configuration. The adapter configuration methods will interact with local environment communication runtime systems for network control. As adapters move to different environments, the adapter communication language specifies the range of options suitable for component communication. The local communication runtime system interacts with the adapter to establish connections.

Our goal is to allow client and server component code to migrate to different platforms and to be properly configured through system architectural levels by simply loading SWWACXML configuration pages. We will focus on three basic issues. First, we will develop QoS-aware configuration languages, which are accessible through and compatible with World Wide Web technology. Second, we will develop runtime communication control systems based on multimedia call modeling. We focus on multimedia connection control systems because they have already been shown to be capable of managing a wide range of QoS options and data types. Finally, conducting performance studies via empirical measurements and the development of analytical models are required.

QoS-Aware Configuration Language

Each SWWACXML specification consists of several sections for network auto-configuration and QoS drill down. One of the sections is a <meta-head> section, providing meta-level information such as application name, security, and so on. Another section is <SWWACXML-info>, containing information pertaining to general, application-level QoS options, and information for QoS drill down. Examples include compiler option information and network QoS information such as desired network service type and end-to-end message delivery delay. This information can be used by the local compiler and by the local communication management system. An additional section of SWWACXML is <SWWACXML-connector>. This section describes how connectors communicate and includes auto-configuration information and different QoS options in the case of multistream connectors (e.g., audio and video).

An example of the QoS portions of SWWACXML is shown in Listing 14.9. This example extends the SS7 tool. It shows how the tool can be automatically configured to run on a single machine or across a network with different QoS options.

The <meta-head> section contains the application name and description. The <SWWACXML-info> section contains information about targeted message delivery delay and a priority ordering of the network service desired, if the application is distributed. In our example, the desired component-to-component message delivery delay is 150ms. The <SWWACXML-connector> section describes either a shared memory location or a network connection. These identifiers may be resolvable at runtime, if required. Listing 14.9 includes network QoS information, including requested bandwidth and a network policing interval. The policing interval is an application-specified traffic characterization used in establishing QoS over ATM or future-generation Internet networks.

Listing 14.9 SWWACXML QoS Example

<SWWACXML>
  <meta-head>
    <meta app="SS7-monitoring"/>
    <meta name="Configuration" content="Adapter Config"/>
  </meta-head>
  <SWWACXML-info>
    <target-message-delay delay=150ms>
    <ordered-switch>
      <target-network-service service="guaranteed">
      <target-network-service service="best-effort">
    </ordered-switch>
  </SWWACXML-info>
  <SWWACXML-connector>
    <client-server-com source=MT dest=MG>
    <switch>
      <local connection-id="100">
      <networked connection-id="channel" bandwidth=10kbps policing-interval=50ms>
    </switch>
    <client-server-com source=MG dest=MT>
    <switch>
      <local connection-id="200">
      <networked connection-id="channel" bandwidth=10kbps policing-interval=50ms>
    </switch>
  </SWWACXML-connector>   *
                          *
                          *
                          *
                          *
</SWWACXML>

Runtime Network Control System

Part of our research focus is to design SWWACXML to enable it to run on different types of platforms and across different networks. We will design runtime communication control systems capable of this level of heterogeneous control. To accomplish this goal, we will extend an integrated multimedia communication tool we have designed and implemented, called the Distributed Interprocess Communication System (DIPCS) (Simon, Znati 1995; Simon 1996). DIPCS is a distributed multimedia call management tool targeted towards running over both best-effort and real-time networks. It consists of a high-level call model for managing heterogeneous multimedia devices and a set of integrated best-effort and ISN-based network-level algorithms. It is specifically designed to provide a lightweight communication control mechanism for applications using heterogeneous platforms and networks.

Real-time applications use DIPCS by interacting with a connection manager. The connection manager provides primitives for specifying communication endpoints, QoS requirements, and communication control. The connection manager interacts with local network control modules and QoS options. Within DIPCS, actual communication management and control is specified by using network- and platform-independent objects, called DEVICEs and STREAMs. The advantage of DIPCS over other distributed call models such as CORBA 2.x and Java RMI is that DIPCS explicitly supports a wide range of QoS connection options, which are described in (Simon 1997) and (Simon and Sood 1997). CORBA and Java RMI have limited QoS support (Schmidt et al. 1999).

DEVICEs are defined as objects that represent communication endpoints. DEVICEs can be used to represent, from the point of view of the network, all objects that produce and consume data. DEVICEs manage system heterogeneity; each DEVICE may be a buffer in computer memory, an instrumentation device directly connected to the network, a local area network as represented by a bridge or router, and so on. Communication occurs directly between DEVICEs after an appropriate channel is established in the network.

STREAMs represent instances of a DEVICE's communication requirements. A STREAM inherits the type of media (e.g., video) and the direction of media (e.g., source or sink) from the DEVICE it represents. The STREAM encapsulates the QoS requirements of a connection between DEVICEs and is used to derive the characteristics of a supporting network communication channel. Matching a source STREAM and a sink STREAM of the same type forms a network connection. Multiple source STREAMs may be connected to a single sink STREAM, if the DEVICE associated with the sink STREAM permits mixing. One example is an audio output device, such as a speaker, which can receive data from multiple audio input devices, such as microphones.

Separating STREAMs from DEVICEs allows a single-source DEVICE to be shared simultaneously by several sink DEVICEs, each with different QoS requirements. For instance, one STREAM may be a TCP connection, while another STREAM may represent RTP data. This separation of STREAMs from DEVICEs permits better utilization of network resources, since each network connection is supported only at its required QoS level.

We have successfully implemented DIPCS in a working distributed multimedia system, called Multi-Media MedNet (Simon, Krieger 1995). The primary mission of MedNet is to provide real-time monitoring and multiparty consultation and collaboration during brain surgery. MedNet functions as a real-time medical command, control, and communication system, running in a general-purpose hospital computing environment. MedNet allows continuous surveillance of the patient's condition during surgery and provides a full range of neurophysiological monitoring and diagnostic functions. It is used on a daily basis at seven hospitals and multiple diagnostic and research laboratories at the University of Pittsburgh. As of 1998, MedNet has been used to monitor approximately 1,300 cases per year.

Extending the DEVICE and STREAM model for use with SWWACXML, DEVICEs can represent components and variation points, while STREAMs can represent different types of network QoS. Local connection managers provide the ability to do QoS drill down. We will investigate ways of integrating the DIPCS approach with the adapter technology described earlier. Notice, for instance, that STREAMs can be specified in the <SWWACXML-connector> section. Connection managers can utilize information from the <SWWACXML-info> section. Further, DEVICEs appear to be one potential way to model adapters for network control. Since DIPCS already works with multiple network types, we believe that our approach towards demonstrating runtime support is quite general.

Experiments in Future Distance Education Technologies

Constructing a test bed for our runtime SWWACXML system is another interesting issue. A planned investigation of several application domains is required, and one of our primary areas of interest is distance education technology. We have extensive experience using distance learning applications, including several years of teaching network classes using both synchronous and asynchronous technology (Pullen 1998). The synchronous application uses real-time multimedia technology, including audio, video, and shared whiteboard connections. The asynchronous application uses prerecorded lectures that provided synchronized audio, mouse, and slide presentations over the Internet. Using these experiences in the development of the initial applications within our test bed will be important.

Performance Evaluation

Performance validation and evaluation are critical to the success of future-generation software systems. Developing instrumentation methods for performance monitoring and evaluation of our test bed is required. Three elements affect the end-to-end performance of the system we have described. The first is the overhead caused by our adapter and configuration methods. The second is the amount and type of data generated by the application. The third is how the underlying end-systems and networks behave under different traffic loads. For two different reasons, we are interested in evaluating the first element. First, application data generation and network/system performance are outside the control of the adapter configuration technology. Second, our adapter configuration technology will be successful if it simplifies the problem of reuse and configuration and if it does not become a software bottleneck.

Our approach to evaluating adapter configuration technology is to conduct software-timing measurements via code instrumentation. It will then be necessary to compare different configurations on an end-to-end application sender to application receiver basis. One comparison point will be application and system overhead measurements without the use of adapter configuration methods. This will be achieved by hand configuration of a test case. We will also develop an analytical model for performance prediction and analysis. This model will be based on a queuing model we have developed for performance prediction of rate- and deadline-based network service disciplines (Simon and Znati 2000). We will extend this model to include adapter configuration software delays. We can compare this analytical model against actual performance data obtained from the test bed.

Application-Level Network QoS Control

There has been extensive related research in QoS control at the distributed application layer. Here we cite some relevant related work. Schmidt, Levin, and Cleeland have developed a CORBA extension to deal with QoS issues (Schmidt et al. 1999). Examples of XML-compliant languages incorporating QoS include SMIL, a language for synchronized multimedia presentation. There has also been work in developing application-layer communication architectures incorporating network-level QoS control. The OMEGA endpoint architecture provides end-to-end QoS guarantees through the use of a QoS broker (Nahrstedt and Smith 1996). QoS parameters are translated between the application and the underlying system. Admission control is via end-to-end tests. The Lancaster QoS-A (Quality of Service Architecture) is a layered architecture of services and mechanisms for QoS management and control of continuous media flows (Hutchison et al. 1994). The COMET group at Columbia University is developing XRM (eXtended integrated Reference Model), a framework for controlling multimedia telecommunications networks (Lazar 1997). Our approach differs from these efforts because of our emphasis on cross-layer auto-configuration, in addition to communication specification. Our work will extend the DIPCS control model (Simon, Znati 1995; Simon 1996).

Several research groups have developed performance and analytical models for end-to-end network performance modeling and analysis of client/server and distributed objects. These models include Layered Queuing Networks (Rolia and Sevcik 1995), the DAMSON system, and an analysis of DoD's object-oriented HLA architecture (Srinivasan and Reynolds 1998). Our approach differs from this work because we will develop models targeting QoS-enabled networks, some of which are presented in (Simon and Znati 2000).

---

Top Title TOC Preface P.1 What Is XML? P.2 XML Concepts P.3 XML-Related Technologies P.4 XML Data Management P.5 How This Book Is Organized P.6 Who Should Read This Book P.7 Resources Acknowledgments Chapter 8 Chapter 12 Chapter 13 Chapter 14 Chapter 19 Part I: What Is XML? Chapter 1. Information Modeling with XML 1.1 Introduction 1.2 XML as an Information Domain 1.3 How XML Expresses Information 1.4 Patterns in XML 1.5 Common XML Information-Modeling Pitfalls 1.6 A Very Simple Way to Design XML 1.7 Conclusion Part II: Native XML Databases Chapter 2. Tamino-Software AG's Native XML Server 2.1 Introduction 2.2 Tamino Architecture and APIs 2.3 XML Storage 2.4 Querying XML 2.5 Tools 2.6 Full Database Functionality 2.7 Conclusion Chapter 3. eXist Native XML Database 3.1 Introduction 3.2 Features 3.3 System Architecture Overview 3.4 Getting Started 3.5 Query Language Extensions 3.6 Application Development 3.7 Technical Background 3.8 Conclusion Chapter 4. Embedded XML Databases 4.1 Introduction 4.2 A Primer on Embedded Databases 4.3 Embedded XML Databases 4.4 Building Applications for Embedded XML Databases 4.5 Conclusion Part III: XML and Relational Databases Chapter 5. IBM XML-Enabled Data Management Product Architecture & Technology 5.1 Introduction 5.2 Product and Technology Offering Summaries 5.3 Current Architecture and Technology 5.4 Future Architecture and Technology 5.5 Conclusion Notices Chapter 6. Supporting XML in Oracle9i 6.1 Introduction 6.2 Storing XML as CLOB 6.3 XMLType 6.4 Using XSU for Fine-Grained Storage 6.5 Building XML Documents from Relational Data 6.6 Web Access to the Database 6.7 Special Oracle Features 6.8 Conclusion Chapter 7. XML Support in Microsoft SQL Server 2000 7.1 Introduction 7.2 XML and Relational Data 7.3 XML Access to SQL Server 7.4 Serializing SQL Query Results into XML 7.5 Providing Relational Views over XML 7.6 SQLXML Templates 7.7 Providing XML Views over Relational Data 7.8 Conclusion Chapter 8. A Generic Architecture for Storing XML Documents in a Relational Database 8.1 Introduction 8.2 System Architecture 8.3 The Data Model 8.4 Creating the Database 8.5 Connecting to the Repository 8.6 Uploading XML Documents 8.7 Querying the Repository 8.8 Further Enhancements 8.9 Conclusion Chapter 9. An Object-Relational Approach to Building a High-Performance XML Repository 9.1 Introduction 9.2 Overview of XML Use-Case Scenario 9.3 High-Level System Architecture 9.4 Detailed Design Descriptions 9.5 Conclusion Part IV: Applications of XML Chapter 10. Knowledge Management in Bioinformatics 10.1 Introduction 10.2 A Brief Molecular Biology Background 10.3 Life Sciences Are Turning to XML to Model Their Information 10.4 A Genetic Information Model 10.5 NeoCore XMS* 10.6 Integration of BLAST into NeoCore XMS Conclusion Chapter 11. Case Studies of XML Used with IBM DB2 Universal Database 11.1 Introduction 11.2 Case Study 1: "Our Most Valued Customers Come First" 11.3 Case Study 2: "Improve Cash Flow" 11.4 Conclusion Notices Chapter 12. The Design and Implementation of an Engineering Data Management System Using XML and J2EE 12.1 Introduction 12.2 Background and Requirements 12.3 Overview 12.4 Design Choices 12.5 Future Directions 12.6 Conclusion Chapter 13. Geographical Data Interchange Using XML-Enabled Technology within the GIDB System 13.1 Introduction 13.2 GIDB METOC Data Integration 13.3 GIDB Web Map Service Implementation 13.4 GIDB GML Import and Export 13.5 Conclusion Chapter 14. Space Wide Web by Adapters in Distributed Systems Configuration from Reusable Components 14.1 Introduction 14.2 Advanced Concept Description: The Research Problem 14.3 Integration of Components with Architecture 14.4 Example 14.5 Future Generation NASA Institute for Advanced Concepts, Space Wide Web Research, and Boundaries 14.6 Advanced Concept Development 14.7 Conclusion Chapter 15. XML as a Unifying Framework for Inductive Databases 15.1 Introduction 15.2 Past Work 15.3 The Proposed Data Model: XDM 15.4 Benefits of XDM 15.5 Toward Flexible and Open Systems 15.6 Related Work 15.7 Conclusion Chapter 16. Designing and Managing an XML Warehouse 16.1 Introduction 16.2 Architecture 16.3 Data Warehouse Specification 16.4 Managing the Metadata 16.5 Storage and Management of the Data Warehouse 16.6 DAWAX: A Graphic Tool for the Specification and Management of a Data Warehouse 16.7 Related Work 16.8 Conclusion Part V: Performance and Benchmarks Chapter 17. XML Management System Benchmarks 17.1 Introduction 17.2 Benchmark Specification 17.3 Benchmark Data Set 17.4 Existing Benchmarks for XML 17.5 Conclusion Chapter 18. The Michigan Benchmark: A Micro-Benchmark for XML Query Performance Diagnostics 18.1 Introduction 18.2 Related Work 18.3 Benchmark Data Set 18.4 Benchmark Queries 18.5 Using the Benchmark 18.6 Conclusion Chapter 19. A Comparison of Database Approaches for Storing XML Documents 19.1 Introduction 19.2 Data Models for XML Documents 19.3 Databases for Storing XML Documents 19.4 Benchmarking Specification 19.5 Test Results 19.6 Related Work 19.7 Summary Chapter 20. Performance Analysis between an XML-Enabled Database and a Native XML Database 20.1 Introduction 20.2 Related Work 20.3 Methodology 20.4 Database Design 20.5 Discussion 20.6 Experiment Result 20.7 Conclusion Chapter 21. Conclusion References Contributors Editors Chapter 1: Information Modeling with XML Chapter 2: Tamino-Software AG's Native XML Server Chapter 3: eXist Native XML Database Chapter 4: Embedded XML Databases Chapter 5: IBM XML-Enabled Data Management Product Architecture and Technology Chapter 6: Supporting XML in Oracle9i Chapter 7: XML Support in Microsoft SQL Server 2000 Chapter 8: A Generic Architecture for Storing XML Documents in a Relational Database Chapter 9: An Object-Relational Approach to Building a High-Performance XML Repository Chapter 10: Knowledge Management in Bioinformatics Chapter 11: Case Studies of XML Used with IBM DB2 Universal Database Chapter 12: The Design and Implementation of an Engineering Data Management System Using XML and J2EE Chapter 13: Geographical Data Interchange Using XML-Enabled Technology within the GIDB System Chapter 14: Space Wide Web by Adapters in Distributed Systems Configuration from Reusable Components Chapter 15: XML as a Unifying Framework for Inductive Databases Chapter 16: Designing and Managing an XML Warehouse Chapter 17: XML Management System Benchmarks Chapter 18: The Michigan Benchmark: A Micro-Benchmark for XML Query Performance Diagnostics Chapter 19: A Comparison of Database Approaches for Storing XML Documents Chapter 20: Performance Analysis between an XML-Enabled Database and a Native XML Database Remember the name: eTutorials.org Copyright eTutorials.org 2008-2023. All rights reserved.