Hi Paul, On Nov 25, 2006, at 11:57 AM, Paul Fremantle wrote:
True. But even if I wear my WS-* only hat, the services you get when you simply map existing interfaces to SOAP and WSDL "as is" will usually not conform to your architectural principles. Whether you accept that depends on whether the benefits you gain if you change them are worth the effort. The same is true if you follow REST principles - you'll have to decide each and every time whether it's worth changing a system to conform to them (and often, the decision will likely be "no way").On 11/24/06, Stefan Tilkov <[EMAIL PROTECTED]> wrote: > I agree that using your terminology, I'm advocating ROA instead of > SOA. Using Steve's terminology, I prefer REST as an implementation > architecture for (business) SOA as opposed to WS-*. > > Stefan Stefan That's what I meant about having your cake and eating it. One of the main aims of business SOA is to keep existing legacy services and make them available to the rest of the enterprise as services. POX and SOAP are great ways of doing that because many existing legacy applications have simple transactional interfaces that can be mapped to XML in / XML out.
I agree under the assumption that "using legacy interfaces with minimal changes" belongs in the "business SOA" definition. I gather in your book it does - fine with me. But even when I talk about WS-* to clients (and this is deemed the only reasonable option, most often for political reasons), I strongly advise against exposing most legacy systems "as is".Mapping those APIs into Resources so that you can apply REST is NOT the same thing, and is not what is meant by business SOA.
I don't know e.g. RosettaNet in any depth, so this may well be an exception -- in this case, you have a very valid point and REST may not be worth it.
And if those companies did a POX approach you would be the first to say that it isn't REST :-)
Only if I'm a) asked or b) they claim it's REST :-)
Valid demand :-) In cases where one wants a loosely coupled, open, standardized, simple, easy to implement architecture and we're debating technical merits only, I consider RESTful HTTP (or ROA, if you prefer) superior to technical SOA based on WS-*. Any number of requirements and restrictions, technical and political, may lead to other options, including WS-* (but also JMS, EJB/RMI or CORBA).So what I'm asking is that you be as clear with yourself about what REST is applicable to as you are with everyone else about what REST isn't applicable to!
Stefan -- Stefan Tilkov, http://www.innoq.com/blog/st/
Paul
smime.p7s
Description: S/MIME cryptographic signature
