- Object-Oriented Technology
- Component-Oriented Technology
- Technology Ownership
- Client-Server Technology
- Internet Technology
- Architectural Layers and When to Use Them
- Software Application Experience
- Technology and Application Architecture
- Applying Standards to Application Systems
- Distributed Infrastructures
- Conclusions
- Exercises
This chapter is from the book
This chapter is from the book
This chapter is from the book
3.5 Internet Technology
eXtensible Markup Language (XML)
Few technologies have generated as much confusion in the mainstream press as eXtensible Markup Language (XML). While XML is a fundamental, enabling technology, there is a tendency to combine it with other technological solutions and blur XML's capabilities with other, often proprietary solutions. Here the heart of what XML is and why it is likely to have an exceptionally long technology life cycle will be discussed.
XML was created to put an end to application-specific data interchange problems. Rather than allow two or more applications to decide among themselves what format to use for data interchange and code the logic for reading and writing to the agreed-upon format in each and every application, XML provided the means to describe data in an application-independent manner. The XML file uses tags to include not just the application data but information (tags) to describe the data as well. XML is a World Wide Web Consortium standard and is used by a huge number of other standards.
One of the benefits of XML is that it addresses the fact that prior to its development, coding import and export routines for every application that interacted with a data set was expensive and brittle. Every time the data changed, every application that interacted with the data had to be modified to understand the new data format even if the change had little impact on the data elements used by the various applications. Applications could not extend existing data formats without ensuring that all applications were also upgraded to handle the changes. Essentially, data were modeled in lockstep with the applications responsible for reading and writing the data. This added substantially to the maintenance costs of all applications that shared data, which tended to include most applications in many environments. XML was revolutionary in that it provided a simple means to model data independently of the application(s) that used the data.
XML is ultimately a data format. The original XML 1.0 specification was quite concise and mostly defined a way to use tags to describe data elements. The tags are user-defined and intended to have the following characteristics:
Structured. XML uses tags to describe the data making the data file self-describing. Programs that read and process XML documents can easily determine if a document contains particular data elements. Also, it is easy for a program to determine whether an XML document is cut off or poorly formed.
Flexible. For any collection of data, XML provides several ways to represent the data. As always, flexibility is both good, in that it allows developers to make appropriate choices for how to represent data within an XML file, and bad, in that it also allows developers to make inappropriate and unwise choices regarding data representation.
Validated. A Document Type Description (DTD) or XML Schema lets developers define rules that guide the representation of data. XML parsers are widely available to validate document correctness against the schema.
Adaptable. The applications that produce the XML files, the operating systems, programming languages, and data management systems can all change, and the XML files will still be readable.
Standard. The use of XML requires no license, and no corporation can change it to make it incompatible with other applications.
Readable. An XML file can be edited, modified, and stored as plain text.
As an example, creating an XML document to describe flavors of ice cream is as easy as deciding what is to be described and then documenting the specific instances.
Why is this technology so powerful? Unlike other data formats, even this simple XML document will be understandable twenty, fifty, and maybe hundreds or thousands of years from now. Few data formats in use even ten years ago are understandable by today's applications. And if data are understood, then they can be used/processed. Additionally, with XML parsers and other complementary technologies, much of the conversion process between different XML formats (and other formats) can be automated.
However, there is a tradeoff for this flexibility. XML is a very verbose way of describing data. Few data formats have the space requirements of an XML document when storing or transferring the identical information content. As a result, other data formats are desirable when performance or storage space is a constraint. Of course, with the current pace of advances in hardware processing and transmission speeds, the size of XML files is frequently only a very minor consideration. A larger problem arises in managing large number of XML documents. Searching large number of XML documents is often problematic. However, XML document indexing systems and even XML-specific hardware have helped mitigate issues with searching large numbers of XML documents. Some database vendors are also implementing XML types in their databases to handle storage and searching issues; for example, such enhancements are available for Oracle 9i in their XML database products. A number of other companies have developed XML-specific databases with a number of customizations designed to increase performance in searching and efficiently storing XML content. Finally, be aware that while many of the claimed benefits with XML are indeed possible, they are very seldom automatic. The use of XML itself does not alone accomplish a great deal; rather, considerable thought, planning, and design are required to use XML effectively in conjunction with other technologies.
Sun Microsystems J2EE and Microsoft's .Net
First, the basics about the two major enterprise development platforms in the industry: Sun Microsystems Java 2 Enterprise Edition (J2EE) and Microsoft .Net. J2EE are Java-centric operating environments that strive to be platform neutral. This means that J2EE developers all work with the Java programming language; however, the language itself is portable across all the major hardware environments and software operating systems. In contrast, Microsoft's .Net environment supports multiple programming languages but is currently focused on a development environment that executes on the Microsoft Windows line of operating systems. In addition, J2EE is primarily a set of specifications that are implemented by a number of different vendors. Microsoft .Net is sold as a suite of products based on proprietary Microsoft intellectual property. This basic difference in strategy has resulted in an interesting polarization in most of the software industry. Sun, along with a few major players such as IBM and Oracle, has made a tremendous investment and gathered a majority of vendors in support of the J2EE standards. Most of them have integrated J2EE in their flagship product lines, and many vendors have their own implementation of J2EE. In the other camp, Microsoft with its .Net has leveraged Microsoft's existing vendor relationships to create a rapidly growing sphere of vendors supporting the .Net line of solutions for enterprise software development. They willingly conceded the fundamental .Net set of core services to Microsoft and modeled businesses toward profiting from value-added software based on the core infrastructure.
The J2EE environment requires all components to be written in the Java programming language. The Java Virtual Machine (JVM) compiles programs written in Java into Java-specific byte code, and the JVM executes the compiled byte code at runtime. This contrasts sharply with the .Net approach, which uses its Common Language Runtime (CLR) engine to compile a number of programming languages into a truly language neutral intermediate code. The CLR enables developers to use any of the programming languages supported by the .Net development tools and has defined mechanisms to enable .Net components written in one language to be called from any other supported programming language easily. This allows multiprogramming language development in a manner that had not gained mainstream acceptance before its introduction in .Net. The jury remains out on precisely how desirable this capability will be within the industry, but certainly the appeal of reusing a tremendous body of existing code regardless of its implementation language has an interesting surface appeal.
In terms of maturity, the J2EE environment has a much longer history and greater industry involvement in its development and evolution. J2EE has been successfully deployed in numerous mission-critical applications in some most challenging vertical industries including financial services and telecommunications. Plus, since J2EE solutions are available from many different vendors, there is a greater variety in the available implementations, toolsets, and value-added products. Unfortunately, as a result of dealing with a number of vendor solutions, care must be taken to deal with product interoperability issues, which are less of a problem than with single vendor solutions like .Net.
Overall, J2EE offers an experienced development team many advantages because J2EE provides greater programmer flexibility than .Net and can enable the development of well-performing, highly customized applications. However, this greater flexibility also allows the easier introduction of serious errors in areas such as memory and resource management. It is far easier to get a multi-tier application up and running in .Net initially, but J2EE enables the experienced developer greater freedom to develop more powerful applications. The .Net architecture is more focused on ease of use and thus doesn't provide as much access to lower level state management and caching techniques frequently utilized in J2EE application development.
Web Services
XML is a data format that enables the data exchange between heterogeneous computing environments. Web Services are important because they use the Internet as the data transmission layer to enable the sharing of distributed processes. By using the Internet, these processes are widely available to potentially millions of users and can serve as the building blocks for larger distributed applications. A Web service can be implemented in any language on any computing platform. The service interface is then described in XML using the standard Web Services Description Language (WSDL), a specialized XML schema for Web services. A client to a Web service can invoke WSDL using the standard Simple Object Access Protocol (SOAP) that provides an XML format for representing the interface of a Web service and invoking it over HTTP. Since HTTP is the standard protocol for the Internet, Web services can be deployed and used over the existing Internet infrastructure. The Web service provider can also register their Web services in a Universal Description, Discovery, and Integration (UDDI) registry to enable clients to search, discover, and access their Web service dynamically.
The basic technologies to enable the creation and use of Web services are widely agreed upon industry standards supported by both the Microsoft .Net and Sun J2EE platforms. However, the value-added services relating to security and electronic commerce are still in progress, and the potential of Web services will not be realized until these key technologies are agreed upon by and widely adopted throughout the industry.