Conventional Web Services
Before we begin looking at a new architecture for our information-driven environments, we should take a brief look at how we have been building similar systems recently and see what might be done better. We have been pitched a dominant vision for Enterprise Architecture for the last (nearly) 10 years that is built around the notion of reusable business services. We need to remind ourselves that Web Services were intended to be a business strategy, a way to enable functionality to be defined in a handful of places, accessed anywhere, from any language, asynchronously. We wanted to be able to upgrade a service without affecting the clients that use it. Unfortunately, the unending and ever-changing technology stack associated with this goal has confused people and not solved the problems we face in real architectures for real organizations. Our goal in this new vision is not simply to be different, but to add value and improve the status of the Service-Oriented Aggravation we have seen.
We have a collection of technologies that comprises our basic understanding of Web Services: SOAP for service invocation, WSDL for contract description, and UDDI for service metadata publishing and discovery. SOAP grew out of different traditions including the remote procedure call (RPC) model and the asynchronous XML messaging model (doc/lit). The first approach is brittle, does not scale, and did not really work out all that well under its previous names of DCOM, RMI, and ...
Get Beautiful Architecture now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.