Logo GISdevelopment.net

GISdevelopment > Proceedings > GITA > 2001

GITA 2002 | GITA 2001 | GITA 2000 | GITA 1999 | GITA 1998 | GITA 1997 |  
Sessions

A tangled web of pure opportunity

Directions for data

Forging the future

How they did it - and what's next

Integrating work management

Mobile solutions- taking it to the streets

Operations support

People make the difference

Systems architecture

The local government perspective

Tying IT all together

Vertical applications
GITA 2001

System Architecture


Using middleware for GIS integration and factors for evaluating technologies


  1. Reliability

    2. Reliability refers to how well the code behaves as expected. Mission critical systems, such as missile defense, will have higher reliability requirements than other systems, such as customer service inquiries into the status of a repair request. The highest reliability requires exponentially more development expense and effort; generally speaking, reliability and development ease are inversely related.

    RPC/DCE should be the most reliable, given enough programming time, testing, and expense, since it is the only solution that allows developers complete control over all aspects of an application. (However, this does not account for the complexity of the final product, which may be impossible to manage at such low levels of coding.) CORBA could be next in line for reliability, depending on the quality of the components that it connects. Java RMI and DCOM are generally considered among the most reliable of these solutions, though this matter is open to debate.

    MQS theoretically provides the highest possible reliability, but this is only for the message container (the queue manager and its queues) and for transmission of messages between queue managers - not for assuring the transmission of messages from applications to the queue managers or for assuring that the messages are processed once retrieved by an application. It's up to the MQS application logic - using APIs provided by IBM - to confirm completion of these tasks, so MQS cannot have its reliability compared to these other products.*

  2. Scalability

    3. The scalability of a product refers to how well it will likely support existing and future systems with little additional work.

    CORBA is the most scalable. Indeed, its reason for existence is scalability. It uses a supporting language called the Interface Definition Language (IDL), which allows a component written in any language (for which an IDL exists) to be connected with any other such language. MQS also offers extraordinary scalability, as it is supported on almost any platform. Note that writing MQS applications still requires facility in languages that have MQS APIs (including C, C++, Java, and COBOL, among others). Java virtual machines come standard with all modern web browsers, and Java RMI is simply another class with its own methods for making remote calls. However, applets are typically regarded as lightweight components, not enterprise-sized components. Direct RPC implementations are the least scalable of all middleware options, providing no inherent future growth capabilities beyond those provided by the developer's customcreated interfaces. XML is a special case concerning the scalability factor: once all the tags and rules for well-formedness and validity have been defined, it can be used anywhere by any organization in the same vertical market. Many standard XML specifications have already been developed, including a Geography Markup Language (GML [Lake et al., 1999]).

  3. Reusability

    4. Highly reusable code does not need to be rewritten for implementation in other projects. Generally the later the binding occurs between components (i.e., the looser components are integrated during runtime and compile time) the more reusable the components. RPC code, generally speaking, is not reusable; everything is tightly bound at compile time. DCOM objects, although not bound at run time, are almost as proprietary as RPC, since the objects are typically not generic enough for reuse, and they can't be inherited unless the source code is available (and it usually is not). Java RMI has no compile-time bindings; it is highly reusable. Java reusability is also significantly enhanced by "introspection" (the capability to probe into a component and discover the interface and its methods). In addition, Java supports inheritance, so additional classes can be based on existing classes. CORBA systems are only as reusable as their individual components; if one "component" is an Outage Management System (OMS) for an electric utility, developers may be able to connect and disconnect it from other components in the same * Paradoxically, reliability order in the above hierarchy (RPC/DCE, then CORBA, then Java and DCOM) would be inverted if it were possible to give the "same amount of development time" to each solution; Java and DCOM would be the most reliable, followed by CORBA, then RPC.

    company but not in other companies (due to proprietary data models). On the other hand, an OMS graphic user interface may transpose to other companies. Like CORBA, MQS also does not fit into the "reusable" hierarchy, but for a different reason: it is an independently operating product that works in isolation from all meaningful system components. The MQS applications themselves, which put and get messages from queues, are highly specific to the components they connect (much as an IDL interface is specific to a CORBA component). XML is infinitely reusable to the extent that the organization anticipated all the tags needed by the components being added or changed. Thus tag creation and production rules should focus on generic business processes rather than component interface needs, while still fulfilling the latter.

  4. Synchronous vs. Asynchronous

    5. Asynchronous systems are those which do not require real-time interfaces between components. For example, in an outage management system, it is not required that all SCADA events be immediately communicated to trigger dispatched crews and GIS GUI imagery; delay is acceptable due to such factors as network latency or a rebooting server, for example. Similarly, if a customer service unit of a company wishes to generate a mailing list of all customers connected to a certain substation's circuit breaker, this can be done on a CPU time-available basis rather than in real time. Message passing systems such as MQS are, by definition, asynchronous. Although synchronicity can be enforced in MQS to some extent, it is not the intended purpose of the product.* All other technologies mentioned in this article are synchronous to the extent that they are single threaded. A particular CORBA implementation, for example, typically has more than one thread running on a different process, and to that extent it could be called "asynchronous."

  5. Open vs. Proprietary

    6. Proprietary products cost money and tend to support fewer platforms (with some notable exceptions, such as MQS). The code is not released to the public, so it is generally only supported and extended by the company that designed it. Open products are usually free, support more platforms, have the code released publicly, and are supported by many user groups and other organizations. Some open products have published standards emerging from a single, recognized authority.

    * The Message Passing Interface (MPI) is also an asynchronous messaging system, but efficient MPI programs pass messages with "puts" and "gets" timed so closely - with blocking commands to force synchronization - that synchronicity is assured. The world's first teraflop "supercomputer" (trillions of floating point operations per second) was not a single computer at all, but a collection of 4,536 dual-processor personal computers connected together to form a parallel computer. This computer completed a large matrix calculation using MPI API calls. Note also that this message passing system used special network hardware (in December, 1996) to enable node-to-node bidirectional communication of 800MB/sec. Thus "remote" nodes seemed a lot less remote! Java is a classic example of an open middleware product. Java development environments and tutorials can be downloaded for free (see java.sun.com). The CORBA standards can also be downloaded for free (www.omg.org), although specific ORBs (Object Request Brokers) to implement the CORBA standards must be purchased. XML and XML parsers for various languages are freely available for download (www.xml.com). In contrast, MQSeries is a good example of a proprietary product. A typical license for a large enterprise will easily cost over $100K (or $1 million for several systems). IBM has MQS professionals available to help companies implement the technology, while no such official support exists for open source products.

  6. Factors Not Included

    7. Security, fault tolerance, and load balancing deserve a discussion of their own. Security refers to encryption, authentication, and verification. Fault tolerant systems gracefully handle failures in components, networks, or servers. Systems capable of load balancing will dynamically shift processing load to less-active computers. These are important factors for some enterprise systems and require implementing multiple technologies to affect a complete solution.
Conclusion
An ideal middleware solution will achieve a balance among all of the above factors given real-world constraints such as legacy systems, available platforms, development talent, and budgetary resources. The hardest question to answer in any large development project is, "How much money should we spend to save money in the future?" Realistically, middleware is often used to cobble together new and old technologies in order to service immediate needs as cheaply as possible. Perhaps the best implementation one can hope for fills these obligations while also investing just a little more time and money to build systems that will be scalable to the company's future needs.

Future competitiveness of GIS-consulting companies and their supporting business partners may depend on the facility with which their products can be componentized and connected to legacy systems. Equally important is the capacity of such businesses to suggest appropriate middleware technologies that enable these connections while anticipating inevitable component changes and additions.

References
Page 3 of 3
| Previous |
Applications | Technology | Policy | History | News | Tenders | Events | Interviews | Career | Companies | Country Pages | Books | Publications | Education | Glossary | Tutorials | Downloads | Site Map | Subscribe | GIS@development Magazine | Updates | Guest Book