Web Server ArcGIS Server Web Service SOAP Controller ADF Connection SOC Process COM Utility JSON Not surprisingly, there are simply some tasks the developer cannot accomplish via the REST API. Geodevelopers frequently need an alternative solution that will keep their RESTful architecture intact while still allowing them to meet system functional requirements. Figure 3: An alternative solution to the developer's functional problem that remains RESTful to the consuming client In addition, while RESTful architectures are definitely high performing (usually), all this chatter on the wire suffers from latency— latency in transfer and latency in serialization/ deserialization at the endpoints. There is a better way. Getting Your REST, and Still Getting Something Done Consider the diagram in Figure 3. It shows an alternative solution to the developer's functional problem previously described while remaining RESTful to the consuming client. Let's take a closer look at what's going on. 1. In this architecture, the user map click initiates a call to a well-known resource URI (http://mysamplewebsite/roadInfo/get or http://mywebsite/lineclipper, etc.) on the Web server. 2. Microsoft IIS hands off the map coordinates (x,y) to ASP.NET MVC. The Routing engine within MVC in turn directs the request to the GET method on the RoadPoints controller. (By the way, an MVC www.esri.com ASP.NET MVC App. IIS Controller method is just a convenient and cogent example; any REST resource will do; Windows Communication Foundation [WCF] provides another option. The point is to make this first hop look RESTful to a client application.) 3. The MVC Controller class uses SOAP to call a traditional WS-* Web service on the ArcGIS Server box. The Web service on the ArcGIS Server box uses an Application Developer Framework (ADF) 4 connection to access a COM utility or server object extension (SOE) running inside an ArcGIS Server server object container (SOC) process. 4. The custom COM utility or SOE does all the buffering, reprojecting, and intersecting (all the GIS "stuff" we're hiding from the user) using ArcObjects. 5. The result is returned to the Web server, converted to JavaScript Object Notation (JSON) by the Controller class, and sent back over the wire as JSON for rendering in the client. What It Gets You In short, the six-step GIS process described at the beginning of this article has been abridged to "Here's a point, hand me a road segment and a mile marker." The architecture has transferred what would have been client workload into an MVC Controller class and a Web service on the server side, reducing chatter on the wire and increasing performance. GIS operations have been turned over to custom ArcObjects code (read: fast). In addition, two other important things have been achieved through this architecture: n It encapsulated business logic where it belongs. n It increased the testability of the application by keeping complex functionality out of the client. Continued on page 38 ArcUser Summer 2009 37