Web Services : Take 2

We have always been a doubter about some of the more ambitious Web Service proposals and standards. We have tended to urge caution because of three major factors:
1)The complexity of n-tier heterogeneous systems even without Web Services is not well optimized if even understood. We have been arguing that at all three layers of the classic n-tier model – Presentation layer, Transport layer, and Storage/Persistence layer there are fundamental design trade-offs that are just being encountered – and the rules of the road, the optimizing trade-offs are just not well undestood. We have been emphasizing in this weblog some of the difficulties resolving the 6As issues at the Presentation layer and the whole new world of long duration transactions and what that means to persistence and reconciliation.
2)The many different standards for transport, messaging, and transaction processing in Web Services are overlapping and/or incomplete. Even worse many have not been stress tested for security, reliability and ease of development. Finally, they will surely have to be revised for performance, development and availability/reliability issues. These issues arise even in relatively simple messaging and transaction processing schemes – often because of the need for provision for extensible roles.
3)Refinement of Web Services as effective means for delivering integrated and agile n-tier applications is the last frontier in computing. All the major players realize this and so not a few are not immune to tilting the standards playing field to their technologys advantage. We have discussed this issue already here. So right now there are overlapping and conflicting standards which are designed in some cases as much for vendors needs and advantage as for the markets requirements. Also there are tough issues to be reconciled with existing OS, database, application server and middleware offerings.
In sum, the tough transaction processing and workflow/collaboration/messaging side of Web Services is rearing its ugly head and biting back at the best of intentions.

So it is not a big surprise when Paul Krill at InfoWorld, reporting on the SDForums Interoperability Theme, seems to confirm our worst fears. Web services technology is now becoming so complex it makes even the experts heads spin. And our point (3), vendors trying to tilt the Web Service standards to their advantage, seems to be endemic. The picture is not pretty at the bleeding edge. But remember, move off far enough from the DMZ of Web Services development and there are some opportunities.

So here is our two senses worth of advice on how to approach Web Services. First go with the read primarily and intranet apps. Make Simple SOA work internally where there is less risk exposure but still some very attractive ROIs. Especially attractive are integrating legacy systems into effective portals. These allow loose coupling so new sources of info can be added and the transactions processing with devilish reconciliations and other elaborate steps, are kept to a minimum. Second, for workflow and business process management, seriously consider bypassing the Web Services edifice including ESB. The workflow, BPM, and EAI-Enterprise Application Integration vendors are coming up with server based solutions which are reliable and performant while allowing in most cases for them to adapt to a future SOA or Web Services framework.

Finally, put your best analysts on the issues of security, identity management, and system control. This will be the make or break feature in many Web Services , SOA and ESB solutions. Right now the standards are still either partly baked or mostly conflicting with the existing hodge podge that is the real world. Staying on top of this arena – again even before Web Services are incurred is a daunting challenge. Plan accordingly.

(c)JBSurveyer 2006