Hey, On 1/22/06, Eric Newcomer <[EMAIL PROTECTED]> wrote: > Hi Mark, > > Yes, we had a lot of good discussions then. I also > recall a pretty good write up, now that you remind me, > of SOA in that document: > > http://www.w3.org/TR/ws-arch/#service_oriented_architecture > > Regarding the question about WSDL, yes, in Web > services it's possible to have various types of > connectors since WSDL is basically just an interface > description, and does not include the definition of a > particular execution environment. I would argue > however that whether you have a single connector type > per WSDL or multiple is something that can vary by > implementation.
You mean multiple connectors per WSDL document? I reckon that's true. But I also reckon that's a bad thing, not good (even in the one connector per WSDL document case). Each deployed connector requires separate development, optimization, and maintenance. The fewer you can get away with, the more evolvable, maintainable, and performant (not to mention *simple*) your system will be. And that requires generic, reusable connectors; http://www.coactus.com/blog/2005/11/on-interface-and-implementation-and-reuse/ > At least from the logical point of > view - as you know WSDL is defined in reusable parts, > and it is entirely possible to reuse the same logical > service description with multiple physical bindings. > > On the subject of the registry/respository, yes, it is > an important aspect of SOA but I believe the > particular text you quote was intending to describe > runtime behavior rather than design or deployment time > behaviors. At runtime it's important for on service > to be able to find the services it needs to contact. > You might call that address caching or something, but > a good SOA implementation doesn't depend upon a > centralized control at runtime. You are right of > course that there needs to be address lookup available > at some point, and this would be a centralized > function. I think that last point you refer to was Jan's, not mine. Practically, today, we're stuck with DNS for historical reasons but decentralized naming systems are possible, for example; http://wiki.java.net/bin/view/Jxta/DisDNS Or more simply, one could imagine a URI scheme whose authority component (where the DNS name currently resides in many schemes) consists of a suitably-encoded public key. Anyhow, I think "registries" (ala UDDI, ebXML) suffer from a far more easily remedied form of centralization problem, and so should therefore not be part of SOA (even by your definition). As I mentioned before, if the Web services architecture simply supported the ability to get service metadata from the services themselves, then the need for registries would vanish, without any loss in functionality. > I'm sorry but I am not familiar with EBI and a quick > Google search didn't help. "Event Based Integration", as in a typical pub/sub configuration where publisher and subscriber are unaware of the identity of the other... what I used to call "ESB", before that name lost all meaning. Cheers, Mark. 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/
