REST, SOAP, Microservices, Monitoring and Management
There are different aspects of the “outside in” approach, specifically Representational State Transfer (REST) and Simple Object Access Protocol (SOAP).
This is the fifth post in this series on application modernization. The focus here is on different aspects of the “outside in” approach, specifically Representational State Transfer (REST) and Simple Object Access Protocol (SOAP). I’ll also discuss base programs with Java and other languages, and other layers of software and organization like microservices, monitoring and management control.
Why These 2 Interface Types?
Java with REST and SOAP are building blocks for a nondisruptive way of harvesting data and application functionality without actually changing the application. The ideas and practices about nontraditional approaches are dominated with discussions of REST and SOAP, but both ways of interacting as services aren’t new.
Both protocols were developed roughly 20 years ago, with SOAP emerging in 1998 (it was deployed as XML-RPC) and REST coming along in 2000 (Roy Fielding’s Ph.D. dissertation). In the modernization discussion, the use of REST and SOAP involves programs that “sit on top of” or “outside of” the application being used. Java often plays a role in this as the module that invokes the REST and SOAP API calls. However, other languages besides Java are used.
REST and SOAP Seem Like Opposites
The reason that REST and SOAP are written about in the same way is that suppliers of interfaces to their web-aware applications provide both options. However, REST and SOAP are quite different. REST has a smaller learning curve than SOAP. REST requires HTTP whereas SOAP is language-, platform- and transport-independent. REST runs quickly whereas SOAP processing has a longer path length during execution. SOAP has built-in error handling while REST leaves it up to the programmer. REST uses small message formats while SOAP uses XML for all messages. Additionally, REST has a flexible set of conventions while SOAP is pretty formal in its use.
The phrase “RESTful web services” is more descriptive than just “REST” because it puts this way of proving interoperability clearly in the context of the web as a service—a way to get what you want using resources on the web. RESTful web services support interoperability between devices running software like browsers and web pages on the internet. REST is an architectural style, a flexible way of doing things on the web, not a strict standard. REST is mindful of important characteristics including performance, scalability, simplicity, changeability and reliability. In many ways, REST reminds me of the pseudo-conversational style of writing CICS transactions.
SOAP is more likely to be preferred by financial and business applications, but it’s not that black and white. A financial company might prefer SOAP because it has a capability, through Web Services Atomic Transactions, to support two-phase commit transactions. Two-phase commit is the industry-accepted way to handle many types of financial updates because this feature enables databases to be returned to the pretransaction state if some error condition occurs during update processing.
Microservices
Microservices are showing up more and more in modernization efforts. Microservices are part of an architectural style that structures an application as a collection of services that are maintainable and easy to test. They are loosely joined, independently deployable and typically organized around business capabilities. Microservices are a good fit for modern applications because the architecture supports the desire for continuous delivery and deployment of large, complex applications.
Microservices are a useful way to organize and deploy the “outside in” applications that work with currently operational applications. In a way, they represent a way to create applications that sit on top of other applications that may not be so easy to enhance. Microservices should be part of a multi-aspect modernization strategy.
Monitoring and Management
Once you start organizing the programs that drive the REST and SOAP and other interfaces into the operational applications you’re running, the microservices applications (APIs) need monitoring and management. That makes total sense. You’re using them to make decisions, so they need to be there when you need them. Microservices deployments give rise to discussions about server-side discovery (how does the server know there is a new service?), client-side discovery (how does your service know how to find and contact another service) and service registry (where is the service list and how do I access it?). Fortunately, there are many open-source projects that have created the elements you need for an API monitoring and management solution. You can assemble and use them on your own or use a commercial product that has already integrated some of the best of the open-source tool distributions in support of API monitoring and management.
What’s Next?
In the next post, I’ll finish up this series with a discussion of the business, organizational, personnel and skills aspects of application modernization. This is a good way to bring the topic exploration to close and move on to another subject. As I plan to move on to a new topic, I am mindful that modernization of applications never stops.