Every hockey team has passing patterns for a power play. A baseball team has several defensive plays when runners are on 1st and 3rd. Soccer teams design corner kicks depending on the opponent. Success in key situations is more likely with a playbook, and Splice has developed its own. We call it the Integrators Playbook, and we offer it as a primer to system and application integrations. This is part one, but we've already released part two which covers user emulation and adaptors.
There is no innovation without integration, and we know how to deliver the integration that makes Splice’s ability to automate and control workflows so powerful. While certain methods and technologies are changing the integration landscape, many applications compel businesses and organizations to use multiple integration types across its information ecosystem. That creates a level of complexity that Splice can simplify.
Splice designs, controls, and automates workflows to make data interoperable across systems. Like splicing rope, we weave disconnected applications together to make operations stronger and more resilient.
Over the coming weeks, we will dig into an integration methodology and provide insight into how and why we apply it within Splice. In this edition, we focus on web services.
Integrating with Web Services
If you are trying to integrate with a source application, a web service is what you are looking for. Also referred to as an application programming interface (API), a web service allows you to access a system’s services over the web.
Web services come in a variety of forms. The best-of-breed have a standard, version controlled, and well-documented format. Some systems even include a sandbox environment to test your integrations before connecting to a live production environment. There are several different web service formats, and we cover a few of the most common.
Remote Procedure Call (RPC)
Remote Procedure Call, or RPC, allows one system to remotely call functionality on another system over the web. One of the earlier forms of web services, RPC often requires the integrating systems to match a few key elements. It must be developed in the same version of the same programming language, and must implement some special programming language-specific protocols.
Abandoned for newer protocols, RPC has largely fallen out of use. However, in recent years there have been newer protocols developed that allow RPC between systems of different languages and origins. RPC does not hold much market share in the world of web services, but you may still encounter these services.
Markup Language (XML) and Simple Object Access Protocol (SOAP)
While technically these are two separate technologies, XML and SOAP are frequently lumped together when discussing web services. A metaphor for this form of service is sending a form letter in the mail. In this example, SOAP would be the envelope with the address information, and XML would be the form letter within.
XML, by design, is a fully defined and documented structured message format. There are companion documents for an XML-based web service which define how the service functions, like an XML schema document (XSD) and a web services description language (WSDL). From these documents, you write your client to access the service interface.
These web services were a huge step forward for interoperability because systems of all types could communicate without any language-specific restrictions. The main complaint about these services is their complexity; translation to or from XML has a high technical cost. There is also an added layer of abstraction that developers find cumbersome.
The current top dog in the API world, JSON is the preferred format for web service APIs. JSON is faster than XML, and developers find it easier to work with. The structure of the JSON message is defined by the service itself and is backed by the representational state transfer (REST) protocol standard.
While XML and SOAP leverage REST as well, you will most frequently see REST referenced for JSON web APIs. While not as explicitly defined as an XML web service, JSON services are now preferred for their simplicity and ease of development for both the client and service provider.
JSON web services should be stateless, meaning each API call should be independent from one another. They should also be versioned. Public APIs should not change, and an updated version of the service should be published in parallel.
Web services are at the front edge of integration development, but other integration methods remain relevant and much needed. If you're interested in other approaches, check out our recent update to the Integrator's Playbook that covers user emulation and adaptors.