GEO 583 Internet Mapping and Distributed GIServices
Unit EIGHT (Session One):
Distributed Component Technology for Internet Mapping
Group Project Progress Report:
Group 1: The SD Camping Guide
Team members: Jesus A. Tamayo, Caleb Bombaci, Richard Caslow.
Group 2: Pups Who Brunch - San Diego
Team member: Melanie Lopez (Coordinator), Haihong Huang, Fali Field
1. What is the Distributed Component Technology?
Distributed component technology can provide extensive capabilities and flexible services for the next generation of GIS. DCOM/.NET, CORBA and Java platform are three major technical frameworks for distributed GIServices.
Under a general definition, a distributed component is "a ready-to-run package of code that gets dynamically loaded into your system to extend its functionality" (Pountain, 1997).
For example, a JAVA applet, an ActiveX control, or a plug-in function for the Web browser can be called a distributed component. In principle, the features of distributed components should include plug-and-play, interoperable, portable and reusable, self-describing and self-managing, and being able to be freely combined in use (Orfali at al, 1996; Pountain, 1997).In practice, distributed components are LEGO-like pieces of binary code. The LEGO metaphor refers to the well-known children’s toy blocks that can be interlocked and stacked. Similar to LEGO blocks, the idea is to create software modules (GIS processes) that stack and interlock to form a dynamic GIS package. The LEGO architecture may persist only briefly for completion of a single GIS task. Then the LEGO modules are broken down, rearranged and restacked to form a new architecture for a new GIS task. LEGO-like components can be moved, combined and used in distributed network environments.
One important advantage of distributed components is the independence from different operating systems, hardware, network environments, vendors, and applications.
The same component can be copied, moved, and executed in different machines with different configurations. Distributed components will interact with each other or be combined together to provide integrated services to users. The development of the distributed component shifts the software paradigm from a monolithic, feature-heavy approach to a flexible, modularized, and plug-and-play approach. This modularized, reusable software framework can improve the cycles of program development and efficiency of software engineering.The following figure shows an example of a LEGO-like module including a map display component which can be used, for example, in a word processing application or a GIS package. The word processing application is combined with several distributed components, including a graphic user interface component, a spell checker, and so on. The map display component is independent to the extent that it can be easily plugged into other packages when users need a map display function. Moreover, the component strategy is hierarchical. Here, the map component is made up of sub-components, including (in this case) a projection control and a vector display control. Alternative sub-components can be added into a map display component to extend its display functions, such as adding a symbol display control.
LEGO-like Distributed Components.
Another advantage of distributed component technology is the independent operation from different software environments, database servers, or computer platforms.
Distributed component technology allows a program (component) to operate on different computer platforms and access heterogeneous database servers via a standardized protocol. For example, a JAVA applet (component) can be downloaded into different computer platforms (Mac or Windows) and can access different types of databases, such as Microsoft SQL servers or Oracle database servers via the channel of Java Database Connectivity (JDBC).
The independent operations from software environments and computer platforms.
Alternative Name: Web Services
IBM's article about web service architectures
http://www-106.ibm.com/developerworks/webservices/library/w-ovr/?dwzone=webservices
[Service Provider] --- [Service Broker] -- [ Service requester]
W3C's Web service Activity
"Web services provide a standard means of interoperating between different software applications, running on a variety of platforms and/or frameworks. Web services are characterized by their great interoperability and extensibility, as well as their machine-processable descriptions thanks to the use of XML. They can be combined in a loosely coupled way in order to achieve complex operations. Programs providing simple services can interact with each other in order to deliver sophisticated added-value services." (quoted from http://www.w3.org/2002/ws/Activity )
"The W3C Web Services Activity is designing the infrastructure, defining the architecture and creating the core technologies for Web services. The SOAP 1.2 XML-based messaging framework became a W3C Recommendation in June 2003 and the SOAP Message Transmission Optimization Mechanism (MTOM) in January 2005." (quoted from http://www.w3.org/2002/ws/Activity )
SOAP: Simple Object Access Protocol (operations)
WSDL: Web Service Definition Language (functions)
UDDI: Universal Discovery, Description, and Integration (addresses and pointers)
Examples: GeoCoding Web Services: (Converting Street Addresses into Lat/Long):
Google Map API (Mash-up), https://developers.google.com/maps/
MapQuest OpenAPI http://developer.mapquest.com/
Yahoo Map API: https://developer.yahoo.com/maps/
ESRI Web Services (NOT FREE ???) (No longer available, replaced by ArcGIS Server web services and ArcGIS Online Services)
http://www.esri.com/software/arcwebservices/index.html
The following Web services are available to Web developers building applications with ArcWeb Services:
 | Account Info—Lets you use a SOAP interface to access your account information such as usage statistics. |
| Address Finder—Determines the latitude and longitude coordinates for street addresses. |
| Address Manager—Allows users to batch geocode addresses either through SOAP or a Web page interface. |
| Content Finder—Search and view information (metadata) about data files, layers, and services. |
| Data Manager—Upload and maintain points, lines, polygons, and metadata. |
| Map Image—Provides access to a wide variety of dynamic maps. |
| Place Finder—Ranks a candidate list of place names and associated latitude/longitude coordinates for a given input place name. |
| Spatial Query—Lets you perform spatial queries and proximity searches. Spatial Query supports all features of Proximity and Query and in addition, it supports point-in-polygon searches based on an arbitrary polygon or a map extent. |
| Route Finder—Returns textual multilingual driving directions for a multipoint user-defined route. |
| Report Service—Makes ESRI demographic and site reports available through SOAP. |
| Utility Service—Allows you to change the projection of your map image. |
| Wireless Location—Locates a registered cellular phone on a network. |
(Good overview paper: http://www.esri.com/news/arcuser/0403/webservices.html )
ESRI:
ArcGIS Web APIs: https://developers.arcgis.com/web-api/
ArcGIS APIs for JavaScript https://developers.arcgis.com/javascript/
ArcGIS Server 9.3
http://resources.arcgis.com/content/arcgisserver/9.3/gis-services
(Require your own ArcGIS Server to create these services).
ArcGIS Online Services:
http://www.esri.com/software/arcgis/arcgisonline/features/index.html
(free, available on the ESRI servers).
http://www.esri.com/getting-started/developers/index.html
NOTE: ESRI is no longer supporting the FLEX APIs and Silverlight APIs (due to the requirement of "Plug-Ins")
(Recommendation: ArcGIS API for JavaScript)
http://help.arcgis.com/en/webapi/javascript/arcgis/help/jshelp_start.htm
Grid technologies have been rapidly evolving since the mid 1990s. They are primarily concerned with the issues of integrating large-scale computational resources and services [6]. The increasing diversity of computational and human resources created a Grid problem which requires new mechanisms for sharing resources dynamically [4].
There are two types of Grid technologies,Data Grid and Computational Grid.
Data Grid [7] can offer a basic architecture for managing geo-spatial data with coordinated data storage, data access, metadata and security services. Data Grids can provide various downloadable GIS data and on-line mapping services via its metadata search engine. Computational Grid [8] will primarily be concerned about related issues for building the infrastructure which is supposed to meet the requirements for high-performance computational needs.
Both data Grid and computational Grid are emerging to provide effective computing resources sharing and integration. Currently, researchers in computer science community have been focusing on the low-level Grid infrastructure construction. One famous example is the Globus Toolkit [9]. The Globus Toolkit can provide a standard Grid framework and coordination functions. Many ongoing Grid projects around the world are based on the Globus Toolkit. The newest release of Globus Toolkit is version 3.2.1 which is based on OGSA (Open Grid Services Architecture) standards. OGSA can extend the capability of Web Services into the Grid computing framework. With the solid technical foundations laid by Globus Toolkit and other computational/data Grid architecture, many application services could be created to solve problems in many disciplines.
Since most GIServices require intensive computation as well as a large amount of geo-spatial data, both computational Grid and data Grid techniques will be required to help GIServices run smoothly. So far considerable progresses have been made in addressing software, hardware and system integration issues for building the Grid infrastructure [9] [10] [16]. GIServices, which usually demand intensive computing (e.g. spatial analysis, Geovisualization, simulation), could be greatly enhanced if deployed under the framework of computational Grid and data Grid.
The grid computing architecture, which has powerful computing capacity, large amounts of storage space, and high-speed networks, appears to be an ideal solution to address the performance problem of GIServices and geoprocessing tasks.
Grid computing technologies have evolved rapidly since the mid 1990s, with a focus on the integration of large-scale computational resources and services via networks
(Baker
et al. 2002). An ideal grid framework will integrate distributed and dynamic computing resources. Therefore, service-oriented architecture (SOA) (Foster et al. 2002) can offer an improved platform for integrating grid computing resources. The Globus ToolkitTM (Foster and Kesselman 1997), developed by the Globus Alliance, provides a good set of middleware for grid computing.
Cloud Computing: See lecture note Unit-2 for details.
2. The Development of Distributed Computer Systems
Along with the rapid progress of network technology, distributed systems have been widely used in the computer industry. The development of distributed systems can be characterized in four major stages. The following paragraphs discuss the four stages by their definitions, network features and system structures.
|
Feature |
Major stages |
Major functions |
Network Topology |
|
Closed |
Stand Alone File Servers (UNIX NFS, Netware, Window NT Shared Directory) |
Files and disk space sharing |
Many (clients)-to-One (server) with restricted access |
|
| | |
Generic Database Servers (Oracle, MS Access) |
Query database and get results from servers |
Many(clients)-to-One (server) with dynamic access |
|
| | | |
Distributed Database Servers ( Oracle) and Distributed File Servers (Windows 2000) |
Query database or file sharing from an integrated server group |
Many(clients)-to-One (integrated server group) Homogenous servers |
|
| ¯ Open |
Distributed Component Technology (CORBA, Java, DCOM) |
Distributed component objects manipulation by sending requests |
Many(clients)-to-Many (distributed servers) Heterogeneous servers |
A. Stand Alone File Servers (1982-). A file server is a device which delivers files to everyone on a local area network (LAN). It allows everyone on the network to get to files in a central storage space, on one computer. A file server directs movement of files and data on a multi-user communication network. Users can store information and access application software on the file server (Newton, 1996). From a network management perspective, file servers usually handle a huge amount of transactions, which usually becomes a significant bottleneck in a local area network. The system structure of file servers is fixed in both clients and servers. Different file servers have their own protocol and file format, which may not be compatible with others.
B. Generic Database Servers (1986-). A generic database server is a standalone computer that sends out database data to users on a LAN the way a file server sends out files. With a database server, the server does the picking, sending only the requested part of database to user’s workstations. Thus, a database server incurs less network traffic than a file server, in a multi-user database system. It also provides better data integrity, since one computer handles all the record and file locking (Newton, 1996). Database servers are more flexible than file server systems, especially on the client side. Multiple users can easily establish new client-side applications to access the same database server. However, the server-side applications are fixed in most cases. It is impossible to access multiple databases at one time or integrate heterogeneous databases under a single server architecture.
C. Distributed Database Servers and File Servers (1992-). A distributed database server appears to a user as a single logical database, but is in fact a set of databases stored on multiple computers. The data on several computers can be simultaneously accessed and modified using a network. Basically, the main functions and capabilities of distributed database servers mimic generic database servers, but the physical locations of databases are distributed across a network. Similar to the architecture of distributed databases, distributed file servers appear to a user as a single logical file server, but physically are distributed in different places. However, distributed file servers are designed for file sharing instead of database access. Distributed file servers can provide users with a virtual integration of distributed file servers on a local area network. An example of this is the active services functionality in the architecture of Microsoft Windows 2000. Both generic and distributed database/file server systems basically follow the traditional client/server architecture, that is restricted to specific internal communications and processing capabilities. There are several problems with the traditional client/server architecture for GIS requests and processes, because it can not provide rich transaction processing and rich data management, or handle overly complex queries or operations. For example, if a traditional database server receives requests from 500 client-side applications at the same time, the server’s operating system may hang. Without a transaction control function, traditional database architecture is not appropriate for complex GIS applications. In some case, transaction processing monitors (TP monitors) have been used to assist major enterprise databases with their transaction services (Orfali, et al., 1996).
D. Distributed Component Technology (1995-). Distributed component technology is an advanced client/server framework, which can handle complex transactions and request from heterogeneous systems. Distributed component technology adopts the concepts of object-oriented modeling (OOM) and distributed computing environment (DCE). Currently, both academic and industrial studies of distributed systems are focusing on distributed components in open environments which can provide new capabilities for the next generation client/server architecture (Montgomery, 1997). Common Object Request Broker Architecture (CORBA) developed by the Object Management Group and Distributed Component Object Model (DCOM) developed by Microsoft Corporation are two examples of distributed component framework (Orfali and Harkey, 1997). Comparing the distributed database/file servers, the main advantage of distributed component object servers is the interoperability, reusability, and flexibility for cross-platform applications. A detailed description of distributed components will be addressed in Section 2.4.
3. Microsoft COM/DCOM Example.
Microsoft COM/DCOM framework is one of the early example of distributed component technology. The original idea of COM/DCOM technology comes from the clipboard function created by Apple Computer in the late 70’s. The COPY, CUT, and PASTE tools provided users a friendly way to share documents between different programs. In 1990, the release of Microsoft Windows 3 extended the clipboard idea and the publish-and-subscribe concepts developed by Apple, then introduced Microsoft’s own way to exchange data between applications, called Dynamic Data Exchange (DDE). DDE allowed different Windows applications to communicate with each other via a message-based protocol.
An example of compound documents in Microsoft Word97.
In 1991, Microsoft released OLE (Object Linking and Embedding) 1.0, which modified the major functions of DDE and added an Application Programming Interface (API) on top of the DDE messages. The major improvement of OLE 1.0 is the ability to link and embed documents within applications.
OLE is a technology that enables an application to create compound documents that contain information from a number of different sources. For example, a document in an OLE-enabled word processor can accept an embedded spreadsheet object. Unlike traditional cut and paste methods where the receiving application changes the format of the pasted information, embedded documents retain all their original properties. If the user decides to edit the embedded data, Windows activates the originating application and loads the embedded document (Microsoft, 1996, p1.).
The linking function of OLE allowed applications with embedded documents to be linked together dynamically. If the original data were changed, the embedded contents would automatically be updated and vice versa. The previous picture shows an example of compound documents, which includes graphics, pictures, sound clips, and an embedded Excel document.
The Component Object Model (COM) was originally designed in 1993 to specify interface interactions and communication protocols between OLE 2.0 components. COM provides the underlying support for OLE components to communicate with other OLE components (Brockschmidt, 1994). "A straightforward way to think about COM is as a packaging technology, a group of conventions and supporting libraries that allows interaction between different pieces of software in a consistent, object-oriented way. COM objects can be written in all sorts of languages, including C++, Java, Visual Basic, and more, and they can be implemented in DLLs or in their own executable, running as distinct processes" (Chappell and Linthicum, 1997, p. 58). COM’s language-independent feature means that components written in different languages can inter-operate via standard binary interfaces.
ActiveX developed in 1996 is the next generation of OLE and extends the use of COM/DCOM to Web applications. ActiveX is a lean, stripped-down version of OLE, optimized for size and speed so it can execute in browser space. Actually, ActiveX loosely defines a group of Microsoft technologies, including ActiveX control, ActiveX scripting, ActiveX documents, ActiveX containers and so on. The name, ActiveX, was coined in December, 1995 by Microsoft (Grimes, 1997). Based on marketing considerations, Microsoft decided to re-package the related OLE technology and sell it as ActiveX technology, targeting future markets of Internet applications and becoming a major competitor to Java technology. ActiveX allows COM architecture to execute on a Web browser as buttons, list boxes, pull-down menus, and animated graphics. Currently, ActiveX technology has been widely used by corporate management information system (MIS) and independent software vendors (Knapik and Johnson, 1998).
The release of Distributed Component Object Model (DCOM) technology was packaged with Windows NT 4.0 in mid-1996. The original design of COM assumed that components and their clients were running on the same machine. DCOM extends the COM technology to communicate between different computers on a local area network (LAN), a wide area network (WAN), or even the Internet (Microsoft, 1998). DCOM also includes a distributed security mechanism, providing authentication and data encryption (Chappell and Linthicum, 1997).
The relationships between OLE, ActiveX, COM, and DCOM
This figure illustrates the relationships between OLE, ActiveX, COM, and DCOM. In general, COM and DCOM represent low-level technology (interface negotiation, licensing, and event management) that allows components to interact, whereas OLE and ActiveX represent high-level application services (linking and embedding, automation, compound documents) that are built on the top of COM/DCOM technology.
The architecture of COM/DCOM specifies the communication mechanism and object management between clients and servers. The actual operations and executions of DCOM objects are accomplished by using the software interfaces between COM objects. A COM interface is a collection of function calls and defined as a binary-type API based on a table of pointers, called a virtual table or vtable. An interface of DCOM will be given a name starting with a captial "I", such as IUnkown, IClassFactory, and IDispatch. Each DCOM interface has a unique interface identifier, called interface ID (IID), which is automatically generated by DCOM. The following figure illustrates an example of DCOM object, MapObject, with three basic interface, IUnKown, IDisplay, and IZoomIn.
The interface example in a map object under a COM/DCOM framework
Microsoft .NET Framework
.NET is a next generation distributed component framework developed by Microsoft, which can enable software developers to build “blocks” applications and to exchange data and services across heterogeneous platforms and environments (Scott Mauvails, 2001). Different from DCOM technology, .NET provides a very comprehensive (and complicated) cross-platform framework where different component applications can interoperate with one another through the Internet. (Pleas, 2000, PC Magazine, December 5, IP01-IP08)
The framework of .NET is a collection of many different component technologies, programming languages, and communication protocols together.
SOAP: Simple Object Access Protocol
WSDL: Web Service Definition Language
UDDI: Universal Discovery, Description, and Integration
Resource:
|
.NET framework |
4. Java Platform Example
In contrast to COM/DCOM development, the original development of the Java platform is as a programming language instead of in support of distributed object frameworks. However, with the rapid growth of Java applications, the Java language has developed its own component framework, called JavaBean, with the architecture specifications for distributed computing. Currently, many Java-related technologies are already beyond the scope of programming language. Its original developer, Sun Microsystems, Inc. called all related Java technologies and specifications an integrated Java Platform. "The Java programming language platform provides a portable, interpreted, high-performance, simple, object-oriented programming language and supporting runtime environment" (Gosling and McGilton, 1996, p. 11).
The original goal of Java is to meet the challenges of application development in the context of heterogeneous, network-based distributed environments (Gosling and McGilton, 1996). The key to Java’s power is its "write once, run anywhere" software model. The Java runtime environment translates Java byte-codes into a virtual machine that runs on any supported platform (Hamilton, 1996). With its powerful cross-platform capability, many software vendors and organizations have launched their projects to explore the potential of the Java language and on-line applications (Halfhill, 1997). The following paragraphs introduce the briefly history of Java language development and the Java platform.
Java Development HistoryThe Java language was developed at Sun Microsystems in 1990 by James Gosling as part of a research project to develop software for consumer electronics devices (Anuff, 1996; Lemay and Perkins, 1996; Harmon and Watson, 1998). The original name of the new language was called Oak. The purpose of Oak was to provide an object-oriented programming language and a software platform for smart consumer electronics, such as cable boxes, video game controls, and so on. In 1991, a team called Green Project from Sun Microsystems began to work on Oak. Sun renamed the Oak language as Java and introduced it to the public in 1995. Java technology has become one of the most important developments in Internet history.
In 1997, Sun released Java 1.1 which includes many important new feature and functions for distributed computing, including Java Beans, Internationalization, New Event Model, Jar Files, Object Serialization, Reflection, Security, JDBC, and RMI. One of the most important new features of Java 1.1 is the Java Bean for creating reusable, embeddable software components, which are similar to the Microsoft’s ActiveX model. Two other significant features in Java 1.1 for distributed computing are the Remote Method Invocation (RMI) API and Java Database connectivity (JDBC), which allow a Java program to invoke methods of remote Java objects or communicate with remote database management systems (DBMS) directly (Weber, 1997).
In late 1998, the Java 2 Platform was released and provided more advanced network-centered functions and APIs. The new content included the Java-version of ORB for the integration of CORBA, Java 2D APIs, Java Foundation Classes, and Java servlets for enterprise server-side applications (Horstmann and Cornell, 1998; Flanagan, 1999)
Java Language and Architecture
The Java language is a pure object-oriented language, designed to enable the development of secure, high performance, and highly robust applications on multiple platforms in heterogeneous, distributed networks (Gosling and McGilton, 1996). From the computer programming perspective, Java looks like C and C++ while discarding the overwhelming complexities of those languages, such as typedefs, defines, preprocessor, unions, pointers, and multiple inheritance (Gosling and McGilton, 1996)
The design of Java language draws on the best concepts and features of previous object-oriented languages, primarily from Eiffel, SmallTalk, Objective C, and C++. Java also incorporates garbage collection and dynamic links from Lisp and Smalltalk, interface concepts from Objective C and OMG’s Interface Definition Languages (IDL), packages from Modula, concurrency from Mesa, and exceptions from Modula-3 (Harmon and Watson, 1998, p. 62).
The architecture of Java platform is illustrated in the Figure 2-9. There are two procedures for the implementation of Java applications, a Compile-time environment (server-side) and a Run-time environment (client-side). The Compile-time environment can be constructed by using the Java Development Kit (JDK) provided by Sun, includes a Java compiler (javac.exe), a Java interpreter (java.exe), a Java debugger (jdb.exe), and several standardized Java libraries. Programmers can use the Java compiler to generate a Java class from a text-based Java source code to a Java byte-codes format and put the class on the server-side machine. Then, the Java class is ready for download by client machines.
The Java Platform architecture
The Run-time environment is comprised of three components, Class loader, Java class Library, and Java Virtual Machine. When a client requests a Java class, the client-side Virtual Machine will download the Java class via the Class loader and combine it with other required Java class from the library. Then, the Java class will be interpreted or compiled into the actual machine codes in the Run-time system, which can be executed under the client-side operating system and hardware environment.
Beside the mobile class download functions, the Java platform also supports remote method invocations on object across different Java Virtual machines by using the Remote Method Invocation (RMI). By using RMI, Java programmers can create a remote Java class with object serialization and create client stub and server skeleton for the communication between clients and servers. The implementation of RMI is very similar to the procedure of CORBA object implementation (Orfali and Harkey, 1997).
Three types of Java programs: Java application, Java applets, and Java servlets.
Java applications are stand-alone programs. They don’t need to be embedded inside a HTML file, or use any Web browser to execute the programs. Java applications can provide full access to the entire local machine resources, such as writing files and changing database contents. Also, Java applications run faster than Java applets because the applications do not need to deal with browsers and have full control of the local client environment.
Example: ArcIMS Author/Designer (Standalone version)
A Java applet is a specific kind of application that can only run from within a Web browser which contains the Java Virtual Machine. In contrast to a Java application, Java applets must be included as part of a Web page in HTML format. Java applets are designed for WWW and can be dynamically downloaded via the Internet. In order to protect the Web users and prevent possible damage to the local machines, Java applets execute within a closed, secure Web browser environment and have only limited access to the memory, data, and files on the local machine.
Exmple: ArcIMS Java Viewer
Java servlets are server-side Java programs. Recently, Java servlets become more and more important for distributed computing environment and the Internet. Java servlets can let a user upload an executable program to the network or server. These servlets can actually be linked into the server and extend the capabilities of the server. By interacting with server-side applications, a Java servlet can share the loads between servers and clients. The results will reduce server load and provide the balance of functionality on server and client machines.
Example: ArcIMS Manager
Most programmers and technology consultants are very optimistic about the future development of Java technology. The main reason is that Java language is truly designed for the distributed network environment, such as the Internet and Intranet. In the future, Java technology will embrace more new functions and APIs in order to cope with the rapid development of network technology.
In 2001, Sun Microsoft created three different editions of Java Platforms, Java 2 Micro Edition (J2ME), Java 2 Standard Edition (J2SE), and Java 2 Enterprise Edition (J2EE) (Figure 3-26).
Resource: http://java.sun.com/java2
Currently, there are three levels of JAVA technologies in the JAVA 2 Platform: Java 2 Micro Edition (J2ME), Java 2 Standard Edition (J2SE), and Java 2 Enterprise Edition (J2EE).
The Java 2 Standard Edition focuses on general, personal, client-side applications. J2SE is the original edition of Java 2 platform. Many useful APIs developed in J2SE are closely related to the applications of Internet GIS and on-line mapping, such as Java Advanced Imaging APIs, Java 2D APIs, and Java 3D APIs.
The Java 2 Enterprise Edition focuses on the server-side, business, IT-based applications. Software programmers can use J2EE Enterprise JavaBean architecture to create re-usable distributed components for different Web Services applications and B2B applications. Several key technologies of the Enterprise Edition include the integration of Java and XML, the Java Servlets Technologies, and Enterprise JavaBean.
The Java 2 Micro Edition focuses on applications of small/wireless devices, such as cellular phones, pagers, smart cards, and personal assistant devices (PDAs). For example, the Java Card technology can allow very tiny Java programs to run on smart cards and other handhold devices with very limited memory size (between 128K to 512K). The Micro Edition can also allow different Java applications to specify their own “profiles”, which are the minimum sets of APIs for particular devices or applications. By utilizing the profiles, the size of Java virtual machines and programs could become very small and be able to be embedded inside a small device. Moreover, J2ME also provide Mobile Information Device Profile (MIDP) to create and specify APIs for wireless communications and mobile devices (Sun Microsystems, 2000).
The following is the J2ME code example for the Wireless GIS viewer.
import Javax.microedition.midlet.MIDlet;
import Javax.microedition.lcdui.*;
public class GIS extends MIDlet implements CommandListener {
boolean firstTime = true;
Viewer view;
protected void startApp() {
if(firstTime){
view = new Viewer();
firstTime = false;
}
display.setCurrent(view);
}
protected void destroyApp(boolean unconditional) {
notifyDestroyed();
}
protected void pauseApp() {
}
}
Unit EIGHT (Session Two):
ESRI ArcIMS (OLD) and ArcGIS Online Introduction
On-line Forum Discussion
Blackboard URL: https://blackboard.sdsu.edu/
HTTP://geoinfo.sdsu.edu/583student
1. ArcIMS Software Architecture (source: ESRI, (2000) Using ArcIMS)
ArcIMS is the first software package for Internet Map Servers developed by ESRI. (ESRI's previous products include ArcViewIMS and MapObjectIMS.) ArcIMS provides the foundation for disseminating high-end geographic information systems (GIS) and mapping services via the Internet. Based on ESRI proven Internet map publishing technology and ongoing research and development, ArcIMS was developed to meet these challenges:
| Ease of use at a variety of skill levels |
| Out-of-the-box usability, while providing a highly customizable environment |
| A comprehensive suite of administration tools |
| Open and scalable architecture |
ArcIMS establishes a common platform for the exchange of Web-enabled GIS data and services. ArcIMS is more than just an Internet mapping solution—it's a framework for distributing GIS capabilities via the Internet. As a publishing technology, ArcIMS features unique capabilities for supporting a wide variety of ESRI clients. As a serving technology, ArcIMS includes a wide variety of ESRI serverside technologies and provides unique opportunities for data integration potential.
(source: ESRI book, (2000) Using ArcIMS)
2. ArcIMS Components (Clients and Servers)
(source: ESRI book, (2000) Using ArcIMS)
Client-side components
ArcIMS provides two clientside viewers:
| ArcIMS Java Viewer |
| ArcIMS HTML Viewer |
The ArcIMS Viewers determine the functionality and graphical look of your Web site. The viewer is what appears in the Web browser when someone accesses your Web site. Users can customize templates to add their own corporate logo, graphics, colors, and functions.
HTML Viewer:
Java Viewer:
Choosing a Viewer
During the process of designing a Web site, along with choosing the tools users want, users are asked to choose a Viewer. ArcIMS provides both HTML and Java Viewers. The HTML Viewer employs JavaScript and Dynamic HTML (DHTML) to enhance its capabilities. The Java Viewer is only compatible with Web browsers that support Java plug-in functionality. It requires a onetime Web download to a user's computer.
There are several considerations when determining to use either the HTML or Java Viewer. The questions below will help the user make the choice:
The HTML Viewer is used effectively when:
| Users are supporting a variety of browsers. |
| Plug-ins aren't allowed. |
| Users want less client-side processing. |
| Only view and query are needed. |
ArcIMS version 3 --> 3.1 --> 4 --> 9.0.1 - > 9.1 --> 9.2 --> 9.3 -- ArcGIS Server 10.3
Online HELP: http://webhelp.esri.com/arcims/9.3/General/arcims_help.htm
ArcGIS Server
Developers can build Web applications that end users access through Web browsers. Again, the developer accesses one or more GIS resources on the GIS server and incorporates their functionality into the Web application.
Unlike Web applications, Web services are consumed not by people but by software applications. Thus, Web services don't have any user interface; it's up to the application that uses the Web service to provide the interface. Usually, the fact that an application uses a Web service is completely hidden to any user of the application. ArcGIS Server Web services are no different. They provide GIS functionality to applications that need it, with the expectation that those applications will provide the necessary user experience that exposes the functionality.
The services you create with ArcGIS Server are enabled for access over the Web. You can create map, geocode, globe, geodata, geoprocessing, mobile data, and network analysis Web services. You can also create OGC WMS, Web Feature Services (WFS) and Web Coverage Services (WCS), as well as Keyhole Markup Language (KML) services.
Mobile applications are used in a connected environment, allowing users to experience the richness and robustness of a Windows application while taking advantage of the deployment and manageability that's similar to Web applications. Developers typically write mobile applications to support users with specific and well-defined workflows. Users of mobile applications frequently work in a disconnected mode on a variety of platforms (for example, in the field on laptops or Pocket PCs) without losing access to the application logic and spatial data provided by ArcGIS Server.
Developers can build desktop applications that work with the GIS server in a client/server mode. These applications can be built using the ArcGIS Engine Developer Kit.
(cited from http://webhelp.esri.com/arcgisserver/9.3/dotNet/_
ArcGIS Server Manager (Web-based):
(create new services directly from ArcMAP (mxd file)
(create Web applications - webpages)
ArcGIS Server Code Gallery
http://resources.esri.com/arcgisserver/adf/java/index.cfm?fa=codeGallery
On-line Forum Discussion
Blackboard URL: https://blackboard.sdsu.edu/
