Understanding Web Services Specifications

Let’s start with a general idea of ​​what web services are and why they are important to software development.

After all, what is the problem?

If you hadn’t tired of hearing all kinds of information about Service Oriented Architecture (SOA) and web services, you wouldn’t be here, so the question is why so much trouble with this? The answer is that this is something important because it is a paradigm shift in the way applications communicate with each other. SOAs have been around for a very long time. Initially, these were mostly middleware applications where a single type of middleware owns at least both ends of the cable. On the other hand, web services, they are made up of a group of standards that try to make it possible for various systems to communicate, without the need for a particular middleware, programming language, or even an operating system. Let’s look at the progression from where we started to now.

Traditional applications

At first, it was computers. And it was a good thing. Computers did seemingly miraculous tasks, automating many things that people did by hand, from complex calculations, to finance, too many other tasks.

But traditional applications are “silos.” The human resources application could not speak to the finance application, which, in turn, could not speak to the distribution application. All of these applications had their own home on their own computers, and while useful, it was not a good way to share data between them. One had the option to write batch processes to pass data from one system to the other, but that was not a substitute for real-time integration.

Distributed computing

The next step in our chain of evolution is distributed computing. Distributed computing allowed different applications to communicate with each other, even when on different computers. CORBA, NTS, and Enterprise Java Beans (EJB) technologies provided a system that included a style registry so that applications could find components they wanted to interact with, and then call them as if they were located on the local machine.

These systems were supported by middleware, or more specifically, by message-oriented middleware, which provided both requirements. Applications can now be created in such a way that they can access resources on other systems, even if they are in different geographic locations.

But there was still a problem. Although applications could communicate anywhere within the system, it was still a closed system. At a minimum, your client application must use the same technology as the server application. Also, as a general rule, systems were not designed to be accessed outside of the individual organization that created them.

Extended web services specifications

Of the dozens of WS-* specifications that are hanging around, several stand out as particularly useful to the business. And they are:

  • WS-Security (Security for web services): This specification handles encryption and digital signatures, which will allow you to create an application so that messages cannot be ‘spied on’ and where non-rejection is impossible. Part four of this series deals with WS-Security.
  • WS-Policy: This specification is an extension of WS-Security, which will allow you to more specifically detail how and who can use a web service. Part five of this series deals with WS-Policy.
  • WS-I: Although web services are supposed to be designed to have interoperability, there is actually quite a bit of flexibility in the specifications that interpretations between different implementations can cause problems. WS-I provides a set of standards and practices to prevent such problems, as well as standardized tests to verify problems. WS-I is the subject of part six of this series.
  • WS-BPEL (Business Process Execution Language for Web Services) – A single service is fine, but in most cases, it is not an application. At a minimum, enterprise-level computing requires you to create multiple services within a general system, and WS-BPEL provides you with the means to specify interactions such as forked and coincident processing necessary to create those systems. Part seven of this series deals with WS-BPEL.

Other specifications, which play an important role in web services, are not included in this series and include WS-Reliable Messaging, which allows you to be sure that one, and only one, copy of a message has been received, and that it has been definitively received; WSRF, the Web Services Resource Framework, allows you to use states in an environment that basically does not save preceding states; and Web Services Distributed Management (WSDM), which addresses the issue of managing and using web services.

Related posts