patrickdlogan 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. > > 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. >
Seems to me this all comes down to how explicit you want to be about what's going on. The more explicit you are, the less "loosely coupled" you are but you might be easier to predict/understand/document. Is it me or is this is starting to feel a little like the dynamic versus other languages debate where one side says "I get all this flexibility" and the other side says "yeah but I can't understand what the heck is going on"? > 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. > Yep - and I can run JavaSpaces on top of http to cross firewalls and have movable code. And I also have in-built event triggers - hmmmm, have to think about that a some more - interesting line of thought, thanks dude. > 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. Hmmm, didn't you mean that choosing to use HTTP everywhere takes this burden off you? i.e. You're saying you've decided to standardize on one protocol across your organization? > >> [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. > > 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? > Urgh, don't like that word architecture in that last sentence but yeah, I get where you're coming from. > -Patrick > Dan. ------------------------ Yahoo! Groups Sponsor --------------------~--> Yahoo! Groups gets a make over. See the new email design. http://us.click.yahoo.com/XISQkA/lOaOAA/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/
