The whole world jumped on SOA last year (or maybe it was 2004, AJAX was the ur-buzzword last year). But, it seems fairly evident that SOA is here to stay and is really useful.

I like a product by NextAxiom that lets you build and run web services very quickly.

But it's turning out that creating web services is harder than describing them to non-technical (or even technical) staff. Non-technicals hear "service" and kind of think of phone service or water service, or maybe an amorphous blob of code somewhere. Technicals hear "service" and think of OOP and components.

There's the common definition of a service as a "remotely invokable, discoverable function with validating inputs and outputs". Which is pretty vague. There are SOAP interfaces, but SOAP can come over HTTP, SMTP, JMS, anything really. But the benefit of services sort of sinks in the first time a service is reused from across the world with only a few minutes of looking it up and adding it to your flow/service.

At that point, businessies and techies spark up and want to use services.

That convoluted introduction brings me to my point: how can you categorize services? There is a pretty common term: "business service"- which is a coarse grained, well defined service that represents a business process. Business services aren't just CRUD, they represent the process from a business standpoint and the underlying technology is completely transparent.

But then what do you call those prevalent CRUD services that aren't pretty but get the job done? They are still valid, have a WSDL file out there somewhere and can be called over any protocols by any service consumers. But what do you call them? I'm at a loss because the distinction is important to service developers. Business services are perfect and can go into the UDDI (or whatever registry you favor), but these other ones are getting the job done but might have nasty interfaces that you don't really want your trading partners to know about.

So, any suggestions?