My sub-atomic particles are always in a mess. You see, they’re actually waves, so you can never be certain where you left them. They’re here and there all at the same time.
Just like software. And I’m not talking about the uncertainty principles that leads to random bugs at unexpected times, usually in the presence of a demo. But the fact that there’s no clear demarcation line, only distributions.
Take Java for example. It’s an object-oriented programming language. But those anonymous classes that access final variables can act like functions and closures. So maybe it’s a functional programming language?
HTML is content, right? And Swing is a UI framework? But can you tell the difference between Yahoo Mail and a Swing app? And what about NetBeans all filled with source code as content?
Here’s another example of wave functions and interference. As Sam Ruby found out , REST can be very much like SOAP and SOAP can be very much like REST. For certain values of “like”. There are just enough points of interference to make that case.
Finding the difference is not a matter of boundaries, but distribution. That’s a tricky part.
The Web, and I’m strictly avoiding the term REST, is based on traversal. You move from one page to another. Every time you make a request, you get pointers to even more resources. The resemblance to functional programming is uncanny.
You have your links, those are functions that return even more functions. And you have your forms, those are functions that include formal arguments, and can tell you whether or not they have side effects. If you spend an idle hour browsing YouTube, you’re just traversing those functions, calling one to get the other.
SOAP takes a different approach. It’s an object access protocol, so you need to know those types in advance, and all the methods on each of those types. You can tell where they exist, but you need to know which function to call. There’s an upper limit, you can only describe so many types with WSDL and can only hold to so many client proxies.
Of course you can avoid WSDL and break past the endpoint barrier, but you wouldn’t be hand coding SOAP without the automagic tools to take care of all the complexity. Not in any practical terms. The mass of the wave distribution is around the well-known, a-priori defined, small set of endpoints.
That’s not a limit, that’s a restriction and it’s a good thing. Go back to the days before HTTP was an acceptable protocol. Back then we didn’t know the Web comes in numbers, but we wanted to punch holes through firewalls. We called those problem B2B, or EAI, depending on whether you’re an innie or an outie. Either way, endpoint management is a pain, so you want to have less of them. And you want each endpoint to do much more, so you really need all those methods.
Today we call it service governance. Proof that old problems don’t go away, they just get renamed in CIO Daily.
Anyway, those wave functions intersect, that’s easy to prove. But proving they intersect doesn’t prove they overlap. Just look at the normal distribution.
One fallacy is to assume it’s all in the wire format, and you can change those like you change socks. You bind the input parameters to a query string, or stuff them in an envelope, and you can invoke either service and none be wiser.
That works with Hello World. Interesting thing Hello World, you can write it in Java or Lisp, and if you take the syntactic sugar they both look the same. Proof that Lisp is object-oriented and Java is functional.
Remember, we’re building an application here, and the Web is one huge application, so we need to review more lines of code. That’s where we start to see wave patterns emerge. On the Web, every time I call one of these functions, I get even more functions.
What would those functions look like? In HTML they would be links, or forms. In other formats, maybe just URLs. What about SOAP?
To begin with, they won’t be functions. They would point to objects you can access, and separately you need to decide which method to call. They may look like URLs, but really they’re just endpoint references. You need to know the endpoint reference so you can resolve the endpoint and the calling mechanism. And if you want to get all fancy and decorate them with WS-Addressing, they become wsa:endpointReference.
Now we revealed two subtle distinctions. The first is that functions tell you everything you need to know to make a call, but objects only tell you who to call after you decide which method to use. So if you have code that expects functions, it gets confused by those objects. And if you have code that expects objects, it doesn’t know what to do with those functions.
Second, we’re passing those around, right? Make a call, get a result, decide who to call next. So we put them in messages, we pick them from messages, we toss them around the code, we store them in the database. In computer science we call it channel passing.
And since they’re part of the message, they’re part of the interface. The interface may have html:form, or xsd:string or wsa:endpointReference, depending on which protocol you decide to use. And it may or may not require an additional method name.
And you can’t automagically convert from one to the other. For anything more trivial than ‘getStockQuote’, the wire-format abstraction leaks like a sieve.
Take any complex Web application, and try to use its REST interface with a SOAP application, or its SOAP interface with a REST application. You’ll soon discover those waves interfere, but don’t overlap.
(Photo by gregmote)