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.
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.
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?
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.
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.
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.
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.
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.