> > On registries, I've yet to see a compelling use case for UDDI. ... > AFAIKS a web page-based human-readable and > searchable directory of services would be more effective than UDDI > without requiring any special interfaces. I'm hoping someone can point > out something I'm missing here. I don't think you're missing anything here. I came to a similar conclusion some time ago, and I think the vendors did as well. That's why all the products are now registry/repositories. What has been good is that the products have all evolved to add value both in the design/development-time space and the run-time space. The common thread is the metadata. Metadata about services form the basis of policies and service contracts, which can be leveraged by run-time infrastructure. Likewise, metadata about services represents the information necessary for real people to find services and make determinations whether they'll meet their needs or not. Anne's panel discussion at Catalyst in San Francisco was representative of this where she had two vendors that began in the UDDI space (Systinet, Infravio) and two vendors that began in the reusable asset repository (i.e. design time) space (LogicLibrary, Flashline) all discussing SOA Governance as competitors in a single market space. > > * virtualization of endpoints (enabling dynamic location, binding, > routing, versioning, etc) > > Dynamic location is certainly useful - our recent off-list discussion > was on the topic of why the web services stacks don't include support > for automatic redirection handling, which would allow light-weight > dynamic location support. I have a harder time seeing the > usefulness of > binding/routing/versioning support in the context of smaller > organizations, though. Dynamic location goes hand-in-hand with routing. While routing could be done through a traditional TCP/IP load balancer, it does become problematic. My experience has shown that these products like to deal with things at a host/port level. This becomes a contextual mismatch when I'm trying to define things at a service level. While two services may share the same set of application servers, I may want the load balancer to perform individual health checks on each service, instead of on each application server. As for versioning, even small organizations may need to deal with things like slow rolls and backwards compatibility.
> > * transformations > > I'd think transformations should ideally only be necessary when > communicating with external services. If an organization needs > transformations just as a matter of basic support it means to me that > they haven't done the work to standardize their data representations - > and they're not building a SOA, they're building a bunch of > disconnected > web services without much planning and coordination. I tend to agree on this one except when used for versioning purposes. Transformations can be applied to maintain backward compatibility. Transformations are right on the edge of the grey area of things that should stay in code versus things that should be externalized. > > * security mediation and enforcement of security policies > > This is an interesting aspect. In smaller organizations I'd think that > services should generally set their own security policies. External > enforcement of security policies seems to me to be something that's > only > appropriate when you get to large scale enterprises. I realize this > approach doesn't fit well with the widespread idea that SOA is all > about > governance. On this one, I'll have to disagree. I think the externalization of policies (with security being the most common example) is a best practice regardless of the organization's size. Just my opinions on all this. I do think every organization will have their own little nuances that may move toward particular technologies whether ESBs, XML Gateways, or SOA Management products. -tb ------------------------ 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/
