An Introduction to Services From This Coder's Perspective


W3C defines a web service as:




The practical question is: how do we use them?

To use a service we compose the message we want to send the object in the format it understands, and then pass it to the object using whatever networking protocol that service employs.  We either accept the response (under a procedural framework), or accept messages of our own if we want to receive a response under an Actor model.  To write a service we accept certain messages, documented in either or both human and machine-readable frameworks, and fulfill the promised responsibilities, replying or sending messages of our own as appropriate.
Currently the most common technologies are Simple Object Access Protocol (SOAP web services) and REpresentative State Transfer (RESTful web services), but the details will depend on what service you are talking to anyway, so you might as well look them up when it become relevant.  Who knows how long these will remain the dominate technologies anyway; network-location agnostic objects are likely to outlast any specific encoding mechanism we are using today.

Finally, when should we be writing services?

This is rather more complicated, as it will depend on the performance implications of current technologies and other business concerns.  However, since good service design is primarily just good object-oriented design and it is always possible to use API-mediated object communication without actually deploying things as services, I think the answer is "whenever there isn't a clear rationel not to."  Writing services enforces loose coupling (because passing data is expensive), makes reuse trivial and rewards tight cohesion.  Of course, we're all doing all of that anyway *cough*, but it can't hurt to have a little extra incentive.  If we write components as services in the first place, it then becomes trivial to deploy things as web services whenever we find we want location-independent messaging, easy caching or other advantages.

So, that’s pretty easy right?  Services are simply a new application of an age-old mechanism for handling complexity: split a very complex problems into smaller pieces, each of which is solve-able without understanding the mechanisms, actors or locations that solve the others. I might wish that we'd found a word that wasn't quite so over-used, but the idea is sound.

[2] "OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.”

[3] Perhaps the one non-obvious implication of this definition is that any program that engages in two-way communicates with a web service is also a service, whether it believes itself to be or not.