One of the benefits of a SOA style of architecture is reuse of services. It is also one of the more challenging benefits to realize. A lot of people found early on that simply slapping a Web Service out there and calling it a service along with opening the flood gates to use it was not such a good idea. Because of ill defined definitions, wrong service granularity and lack of governance, a big mess was created. Agility and reuse went out the door.
Here are a few thoughts on service design that have helped me achieve a fair amount of effective reuse and agility.
Coarse grain versus fine grain is the basic decision point. The more coarse grain the service, in other words the more stuff it does, the less likely reuse will occur. What I have found to be effective is to start with a lot of "medium" grain services. These services do something beyond the basic add two numbers together but stop short of containing a lot of business rules. They tend to lend themselves to orchestration by multiple business processes.
These services also make up the core of the composite services. The benefit here is these services can appear both in the higher level composite services as well as be accessed directly.
Data type conversion among the platforms is challenging. Simple guideline here is keep it simple. Go here for more detail but I would recommend keeping it even simpler when you can. Remember string is king.
Along with the thought on data binding comes exotic WSDL. Same kind of mindset applies here as well. Just because you can put it into a WSDL doesn't mean you should. The more stuff that you put into a WSDL the less likely its going to be compatible with everything that needs to consume it. Agility can take a hit here too.
Key point here is WSDL is just a definition of an interface not the implementation or the consuming service. It's up to physical implementation to actually provide the concrete stuff. That's were things can go astray. Chances are you have a lot of stuff in your enterprise. The chances that each thing you have will support the wide variety of stuff that can be stuffed into an interfaces definition is remote at best.
The other issue is that to much stuff in the definition can create a brittle interface instead of a robust one. Agility suffers and reuse is difficult. I would in most cases steer clear of putting strict business rules in the WSDL.
Some level of governance is required to managed this entire approach to designing systems. It doesn't have to be overly complicated but should include things like: code reviews, interface design reviews, testing polices and change policies. Sometimes when governance is put in place it's at to high of a level. Governance in the SOA world has to be very active and down in the trenches.
Reuse is possible in SOA. But you have to take care not to over engineer your interfaces. If you do that then reuse can be achieved and agility will also magically appear.