Well, if you don't mind undermining the marketability of your own book...
I'm getting the impression that quite a few Java developers are being thrown at Web services somewhat unprepared, and its human nature to try solve the problem with what you know - rather than embarking on a long in depth study of yet another set of technologies. This ultimately explains the popularity of the "web services pixie dust". So there is very much the situation that most of the time it is hard to design web services the "proper way". Unfortunately, I haven't seen a tool along the same lines as
WSCF - Web Services Contract First in the Java domain. However even with a tool some basic understanding of XML/XML Schema/WSDL/SOAP is required. So a
XML/XML Schema/WSDL/SOAP distilled for Java developers (the 20% that you use 80% of the times explained in terms that are familiar to a Java developer) would be a great asset for getting people on the right path.
Addressing the RPC vs Document-Oriented issue. Again coming from a Java programming background dealing with objects and methods, developers would gravitate towards the RPC style. In the Axis 1.x days this was exacerbated as RPC
SOAP Section 5 encoding (shudder) was its default mode of operation (I don't know what the current SOAP stacks prefer). So a short discussion why document-oriented is actually better in many cases might be helpful; maybe some tips on bridging the object-hierarchical impedance mismatch and how to adopt message-based thinking with web services architectures.
Interoperability. Because of all the hype around web services the management level often believes that it is "simple" for any platform that supports web services clients to talk to any other platform that supports web services. So some tips on which toolkit features to avoid and which ones to prefer may prevent the neophyte developer from backing her/himself into a corner by creating web services that can only communicate with a narrow set of client toolkits/platforms.
It also seems to come as a surprise to some that a standard web service cannot initiate communication with a web services client. The existence of the WSDL One way, Request-Response, Solicit-Response, Notification message
exchange patterns (MEP) seems to create the expectation that SOAP over HTTP can actually support all of them. So some introductory material before directing developers to articles like
Asynchronous operations and Web services, Part 2 could be useful.
Versioning and Interface evolution. This can become a problem. There is the issue of versioning the WSDL, especially if you are trying to reduce duplication by using imports and includes. Then there is the of updating of endpoints. What modifications, if any, can one get away with, without breaking older clients, what modifications will require new endpoints. Pros and cons of RPC vs. Document in this context.
Message based security. This is almost inline with SOAP Sessions. Its ok to use transport layer security, however Enterprise SOA will require message level security.
Basic SOA versus Enterprise SOA. I like the notion of Basic vs. Enterprise SOA that you presented in
Guidance for context management in SOA JWS? and I think it deserves to be developed further. The main hurdle to the adoption of Basic SOA that I can see is that it basically precludes later extension to Enterprise SOA. However I seem to recall that Amazon at one point claimed that they had a 80% POX/HTTP + 20% SOAP/HTTP mix in their web services architecture and that a 100% SOAP/HTTP commitment would place a significant additional strain on their infrastructure while not giving them any additional business value. So a development of a
REST where you can, SOAP only when necessary Hybrid SOA could present an attractive alternative (
Playing Together Nicely: Getting REST and SOAP to Share Each Other's Toys).
Service Design. Ultimately web services are all about interfacing - and that by itself, as complicated as it may be, is pretty useless without the
service application. How are service applications different from other types of applications, what unique challenges do they face and what are the tactics to deal with these challenges.
Granularity. Is functionality XYZ a good candidate to become a web service application? What makes a good candidate, what makes a bad candidate. Just because Java EE lets you turn an SLSB into a web service endpoint doesn't mean every SLSB is a good candidate (the majority probably isn't).
[ June 01, 2007: Message edited by: Peer Reynders ]
