Steve Jones wrote: > 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. >
No lynching required - I would only add that JavaSpaces provide a means to transport function as well data/state via code downloading. Thus clients can adopt or gain new behaviour over time. 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/
