You are here

Web GIS and Service-Oriented Architecture – Accelerating Change

Service Oriented Architecture Esri had steadily advanced and extended their service-oriented architecture (SOA) offerings; coined the term “Web GIS” and accelerated GIS offerings like ArcGIS Enterprise, ArcGIS for Server, and services (e.g., geocoding, printing). Now, on the doorstep of the first release of Esri’s utility network model in January 2018, we will see perhaps one of the boldest steps yet toward services solutions: a utility network model and framework implemented entirely through web services which work exclusively with a services-enabled geodatabase. 

In speaking with business and technology stakeholders, there is evidence many are not completely appreciative of what a leap in technology SOA is. With this capability comes great capability, but also the requirement to reexamine existing assets and solutions, and look at how they fit into this new paradigm and view existing and even future solutions through a new lens. A deeper understanding, or at the very least, an acknowledgment that is approaching solutions differently to be effective is quintessential to make a successful and smooth transition.

History of Service-Oriented Architecture

Giants in the software industry fully embraced SOA decades ago. Probably the first and most prominent company to make a move to SOA was that of Amazon. In this letter to Amazonians[i], it was laid out in no uncertain terms that SOA architecture and design was the future. The then modern age of client-server software architecture, design and development had come to an end: 

1.     All teams will henceforth expose their data and functionality through service interfaces.

2.     Teams must communicate with each other through these interfaces.

3.     There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.

4.     It doesn’t matter what technology they use. HTTP, Corba, Pubsub, custom protocols – doesn’t matter.

5.     All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say; the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.

6.     Anyone who doesn’t do this will be fired.

In June of 2005, Google released their Google Maps services[1], Twitter their social media services. In 2008, Microsoft announced the release of its cloud platform, Azure, the backbone of which would be entirely accessible via services. Microsoft continues to build out functionality in Azure, first exposed through services; then releasing language-specific SDKs (JavaScript, Ruby, C#). This delivery and support model we see repeated by others, and one we see repeated with Esri’s Web GIS today.

So, where does that leave you, the stakeholder? The business leader, partner, end-user, developer, architect? How can you best harness the power and capability of an SOA in your organization? What challenges and opportunities will these bring to you? How can you maximize returns and capabilities and minimize costs as you ride out this technological tidal wave?

Become familiar with the rising and dominant technology, REST services

Depending on your role in the organization, your required familiarity and depth of knowledge of REST services will vary, at the very least understand that the underpinnings of a modern services architecture are REST services.

REST is the modern approach to services design. SOAP services, though still present in many systems today, have become a shrinking percentage of services technology overall, a Google Trends[2]

Service Oriented Architecture

At a high level, development teams should have a solid understanding of the principles of REST. Defining REST resources and knowing how to apply properly and use HTTP verbs are key. Poor design choices early can cripple or at the very least overly-complicate scalability later on.

If you are a developer and want to get a good handle on building RESTful services you might check out REST in Practice. This building-block, narrative style book I found both insightful and helpful though sometimes dogmatic – but still good.

If you are a seasoned REST services developer or architect you probably have a copy of the RESTful Web Services Cookbook somewhere nearby (or should). This book has solution patterns, and anti-patterns to typical and common issues and obstacles when architecting scalable RESTful systems.

There are other, more recent book titles out there – but the underlying design philosophy has not changed.

Inventory your existing GIS solutions and technologies — where will services help? 

Esri continues to build out the ArcGIS Pro SDK, the Utility Network SDK and a growing litany of samples. These powerful tools and concise snippets handily equip development teams in accelerating customization in ArcGIS Pro. The ArcGIS API for Python is the one-stop shop for crafting and managing GIS solutions and systems both in and outside of ArcGIS Pro. Many of these tools overlay the underlying Web GIS REST-based architecture.

As you inventory your solutions and applications today, map out which of these technologies enable your organization to transition to Web GIS smoothly. In some cases, REST services call to the GIS resources may not only be necessary, but they may also be your only option.

Inventory external systems and technologies — are they service oriented?

Resource management systems, customer information systems, asset management and others – are they “services ready”? The more service-oriented resources your organization, the more easily they are leveraged, integrated. Relational databases can be “service oriented” by applying pre-defined standards such as OData and many off-the-shelf tools to expose data are available to transform formerly proprietary client-server database connections into vendor agnostic service endpoints. Here, a services approach to data access can lift the barrier to changing database vendors later, perhaps. Here at SSP, we have been using freely available PostgreSQL as a suitable replacement.

Going Deeper

As you shift and adapt your business and mindset to SOA, you will find integrations and opportunities that before seemed may have seemed unattainable, unfathomable. SOA is not a magic bullet though, and it can be implemented poorly and has hidden challenges that if not addressed early on can cripple solutions, particularly as they scale out. Careful planning, thoughtful design and a clear expectation of results will help guide organizations to success in the Web GIS and emerging services world.


[1] https://en.wikipedia.org/wiki/Google_Maps#Google_Maps_API

[2] https://trends.google.com/trends/explore?date=all&geo=US&q=rest%20services,soap%20services

Author Information

  • Bill Bott

    Bill Bott has 20+ years’ experience in the field of software development. Bill lead design, architecture and development of many Schneider Electric products in ArcFM Solution for 15 years. Bill also served 5 years as product manager for SaaS B2B product offers – where he gained a deep appreciation and understanding of services-oriented architecture, and the challenges and opportunities therein.

    When Bill is not building game-changing products for SSP, he enjoys time with his wife and three children and works diligently towards his Masters of Business Administration from the University of Illinois Urbana-Champagne.

    See all items created by this author >

    Connect with me on:

Category Tags:

Add new comment