What does it take to implement services? (as in SOA)

I been thinking on what exactly has changed in the way we develop applications in 2000 and today especially in relation all this noise about a new Web services standards. WS-Crap and WS-GoodForNone are being released almost every day.

Well, in certain ways this necessary for our own understanding (as in IT providers) to evolve and mature. Finally when the dust settles we will have something which is the basic minimal set of standards which are necessary to standardize and understand.

Specifically, I have suddenly heard java component developers using the word services more frequently and less appropriately for their component contracts. Well a client who uses your component can definitely treat the component as a service provider but that is definitely not what SOA is about.

In fact, SOA is about services that provide some common properties which we will see shortly and at the same time do not specify the language or component model actually providing that service. In fact you can even use simple and effective scripting tools like PHP and Python to implement SOA? I need to emphasize that you do not need Object Oriented languages even.

What then, qualifies to be called a service? In my understanding three constituents are vital.

1. A Service Contract that clearly specifies what data is expected to invoke the service and what you can expect in the response. This is the XML Document Schema in Web services.

2. A Network Endpoint or Port and binding in WS terminology that specifies the protocol and network address to send an XML document (instance of the contract) to. Remember it does not have to HTTP - in fact you can still use SNA LU 6.2 :-)

3. A Service Processor or software that actually handles the service request and provides the response.

It is important to recognize the intent and role of these three rather than their names as they always appear in internet literature well disguised.

Now for the major thought within the implementation space (Java or .Net) - what really changes between one service and another within an SOA application is mainly the Service Processor which in the java world is mostly either an EJB or an MDB. Yet, during application development are we spending too much time and effort having to write code for parsing the XML document and transforming it into the object/component interfaces within the processor. My premise is that if we can altogether avoid having to write code repeatedly for each service then we can build services faster and with better reliability.
Why reliability - simple - less code more reliable.

Before I post my ideas how to achieve this - I'd like to be sure that I'm seeing the right problem.
Hope to hear from you.

Bye