The application protocol should include how the data is returned. This is not necessarily connected to the implementation. One should be able specify what is required through the interface without specifying the implementation. Certainly, the interface put constraints on the implementation but shouldn't indicate specifics of the implementation. The whole issue seems to me as to how one specifies the interface and how one "discovers" what the interface is. There are many paths to this "discovery", but nonetheless, without a discoverable interface specification, it would be difficult to use a service and even harder to get interoperability. The latter requires more widespread use of an interface. An independence of the implementation from the interface is critical in this regard. For example, we don't care how the DNS server gets a mapping of a name to an IP address, but just that it returns one. We don't care how the LDAP server returns a id match, just that it does so if it can. The server may have to go ask another server if it knows, but the client doesn't have to know this or how it is done. The same should apply to other network services without my having to know anything about their implementations. Amazon provides access to their system through a WSDL, but this gives one only a one-to-one partnership. One should be able to have a client application that could be used with any service of a similar type that could discover the capabilities and requirements and adapt to it. There are many ways this could be done in a variety of protocols. It is the variety that gets in the way of interoperability.
Dave Gregg Wonderly wrote: > Mark Baker wrote: > > On Sat, Sep 17, 2005 at 06:42:33PM -0600, David Forslund wrote: > > > If one only as PUT and POST one is severely limited on the type of > > > application semantics > > > that one can express. Sending all communications over these type of > > > "method" calls is > > > pretty limiting or requires one to add the application semantics > to the > > > messages. > > > > Not at all. Consider that the single method "GET" replaces the need > > for all "get*" semantics such as getStockQuote, getInvoice, getName, > > getAge, etc ... > > > > Nothing prevents the *implementation* from varying, it's just the > > interface that stays the same, just as getStockQuote can return > > both real-time and delayed stock quotes. > > But, the way that results are returned, as well as the formatting of > those results will create dependencies within your > client software. There is no independence from the *implementation* > here. The protocol and all of its limitations are > embedded in the applications protocol. > > Gregg Wonderly > > ------------------------ Yahoo! Groups Sponsor --------------------~--> Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life. http://us.click.yahoo.com/A77XvD/vlQLAA/TtwFAA/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/
