An enterprise SOA service is not just any old web service. There are specific requirements that it must meet. These are not optional, yet I have not been able to find many resources on the web describing these requirements. (Reasons = different post).
In general, if you are developing a service that you want other folks to consume, you must follow these high level principles.
- Your service must be simple to call. With a coarse-grained service, there can be a lot of data to pass, and that data may need to be fairly complete. The receiving end may need to perform quite a bit of validation on that data. One tactic that I’ve seen to ‘optimize’ this is to write a DLL that creates the data and calls the service. Then you just ship the DLL to your customers. This is nuts.
- You customers still have a call-level interface. Instead of it being the service, it’s the DLL. Nothing gained.
- EAI components now need an adapter to call your service. Something lost.
- Your service, if called from an external or cross-platform environment, it is not being called by your DLL. In fact, you cannot really be sure that the service is called by your DLL even inside your environment… so you will have to validate the data anyway. This means that the data, when it is called by your DLL, is validated twice. This is a performance hit. Do it once… in the service.
- Heavily nested or embedded XML structures are unweildy in most tools. Therefore, the fact that you can do something in XML, doesn’t mean that you should. Avoid the creation of the “universal message” that can be extended 1,000 different ways. Go ahead and create messages for specific business purposes. Keep the vocabulary of messages from exploding by using optional attributes and structures… that’s fine. But if you create an XSD that refers to 10 other XSD files, you’ve got a structure that no human can understand, much less code to.
- Requiring some non-standard encryption to take place or some special mechanism to ‘encode’ the message, to make sure that it is coming from a known source, forces your EAI tool to use an adapter. It also gets in the way of flexibility. To remain flexible, you need the message to come from anyone without changing the code. It is perfectly appropriate to encrypt the message or to sign the message. There are standards for that. Use them.
Of course, putting requirements like this on Enterprise Services means that not every service can partake. On the other hand, it means that every service in the Enterprise catalog can be verified automatically, and basic information can be collected and reported. You can go further, of course, and place a great deal of stuff in a standard interface, but this is the basic set that I would start with.