On 11/09/06, Andrew S. Townley <[EMAIL PROTECTED]> wrote: > > > > > > > > Hi Steve, > > > On Sun, 2006-09-10 at 15:45, Steve Jones wrote: > > On 10/09/06, Steve Jones <[EMAIL PROTECTED]> wrote: > > > On 10/09/06, Gregg Wonderly <[EMAIL PROTECTED]> wrote: > > > > Steve Jones wrote: > > > > > > > > > > > > > > > What do you mean by a polymorphic service? One that can handle > > > > > multiple message types, or one that is polymorphic in terms of the > > > > > contract it offers to consumers. > > > > > > > > > > If its the former then I don't see why not, if the service is > > > > > something like "DataCleansing" and you can pass in multiple different > > > > > data types for cleansing and it returns the cleansed data. > > > > > > > > > > If its the later then I think it might get a little tricky if the > > > > > service changes its behaviour based on what it is passed! > > > > > > > > > > > > Isn't this what REST does? > > > > > > > > > > Oh boy, REST claims polymorphism. I thought REST stressed the > > > importance of the URI? Which was resource specific? This puts it in > > > the first case (which WS can certainly do as well) rather than the > > > later (which WS and REST can both do but I don't think its a bad > > > idea). > > > > Clarification, I do think that this is a bad idea... ooops. > > > I'm not sure I agree with you here. The service interface protocol is > defined by the message sent in rather than the endpoint that receives > it. If you don't do things this way, how can you possibly support > "generic" services like intermediaries or proxies?
But those aren't really polymorphic in terms of the contract they are just polymorphic in terms of the data. An intermediary or proxy is just taking information and passing it on. Its at best polymorphic on data type, but even that is arguable given that the purpose of its contract is to act on that data. What I'm saying is that a service that has a polymorphic contract is a bad idea. One that acts in a polymorphic manner on data but applies the same contract to them is just good design. > > As I mentioned before, it isn't as simple as hard-wiring a SOAP > interface based on the WSDL, but the sender knows what protocol to > expect based on the message type sent to the given endpoint. The > combination of the endpoint (virtual or otherwise) and the message type > together define the protocol the message sender will use. This > distinction isn't that important in synchronous interactions, but it > makes a big difference in asynchronous ones. Why does it make a big difference to async? Hopefully the protocol and endpoint approach are hidden from both the implementation of client and provider. > > > ast > -- > Andrew S. Townley <[EMAIL PROTECTED]> > http://atownley.org > > > > > Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) <*> To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] <*> 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/
