One constant issue of Services and the scientific investigation of Services is the lack of of publicly available Services. In discussions with people in the Service community, this is a constant lament. On a closer look, this is very interesting, since there ARE literally millions of them. The question is simply what to look for.
If you ask people in the Service community to define the term Service you get… well, a lot of different opinions. However, if you insist that SOAP Web Services ARE Services, you get answers like:
That’s true. But, let’s do not stick to a particular technology. Services are in principle technology agnostic. They are not bound to a certain technology.
By following this reasoning we have ourselves already found a lot of Services. Why is that so? Because, if technology does not count, EVERY resource on the Web IS a Service. At least an information Service. I’m talking about restful Services, which use HTTP methods (e.g., POST, GET, PUT or DELETE) explicitly. Want to see an example? Well, if you read this, you already use the ikangai Blog information Service (IBIS). If you would like to comment, you can do this by invoking the ikangai Blog comment Service (IBCS).
I suspect that in all these discussions with Service people, there is an unexpressed assumption when you hear the “there are no public Services” argument. It’s that Services ARE SOAP Services in their minds. They are composed with BPEL. They have a WSDL interface description. And yes, public SOAP Services are scarce and hard to find.
After all, the “there are no Services” argument is contradictorily: if Services ARE technology agnostic then we have millions of them (and they can easily be found). If not, then Services ARE SOAP Services and NOT technology agnostic.
your ikangai science teamRest++, Services, SOA, SOAP