Whoooo hoooo... indents....
On 29/06/06, patrickdlogan <[EMAIL PROTECTED]> wrote: > > > > > > > > > > [SJ] An interface defines the FUNCTION as well as the data. Data > > exchange is only one small part of a service definition. Some > > functions never exchange any data for instance. I might be very > > thick, but when I define a service interface I think in terms of the > > capabilities that it provides, these don't often get reduced to just > > resources and data. > > > In SOAP/WSDL you have the mechanisms to define the interface to any > functions you desire. Your architecture can be a hodge-podge. SOAP/WSDL have nothing to do with architecture definitely, they are just an implementation element. Design choice rather than architecture. > > In HTTP you *should* use the pre-defined methods to transfer data here > and there. Your architecture can be a hodge-podge, but at least not > because you have a zillion and two interfaces. I'm really not seeing this at the architectural level, if I have 30 services which each have 4 capabilities then I have 30 services with 4 capabilities at the architectural level. The implementation technology should be the most appropriate and simple, but the LEAST important question is how to implement the execution context, that is just how the consumer access the service, and in 2006 we should stop pretending that this actually matters. > > Think of the HTTP "functions" along the same lines as the > Linda/Javaspaces "functions". There are just a very small number of > them, and all they do is move things from here to there in a small > number of ways. With these two architectures, you have to understand > the best ways to use them. Javaspaces act (lynch me Dan when I get it wrong) as a co-ordination point for systems, they don't actually provide function themselves but the mechanism for exchange. From a consumer and producer perspective that again is about the execution context which is the piece that provides no actual value in itself. > > With SOAP/WSDL, you have to understand how to define an interface. But > then you also have to understand what your architectural choices are, > and how to implement that. HTTP takes a good bit of that burden off of > you. Really not seeing this. Maybe I'm old school but I'd really quite like people to understand how to define an interface and to understand the architectural impacts of choices that are made. HTTP removes none of that architectural thinking (you still need to know the service has X capabilities and what they do) and just gives you a different way to build the execution context. > > > > [SJ] But is REST that much better than WSDL? I'm not seeing it > > > SOAP/WSDL is not an architecture. It is an interface definition > language with which you can define all kinds of architectures. Just > choosing WSDL doesn't solve the architecture question. Nope, and as above I agree. SOAP/WSDL have nothing to do with architecture, they are design at best, and most probably just implementation. > > REST is an architecture "pattern" if you will. HTTP is an incarnation > of REST. I don't see any way to compare HTTP and SOAP/WSDL. I think > you have to compare HTTP in whole or in part to some other > architecture that you may base in whole or in part on SOAP/WSDL. What > is that other architecture for you? REST is an IMPLEMENTATION pattern, not an architectural pattern. Its part of the Development and Deployment choices not part of the architectural approach. The problem with SOA is that no-one likes to admit when something is just part of SOD. > > -Patrick > > > > ------------------------ Yahoo! Groups Sponsor --------------------~--> Check out the new improvements in Yahoo! Groups email. http://us.click.yahoo.com/6pRQfA/fOaOAA/yQLSAA/NhFolB/TM --------------------------------------------------------------------~-> Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
