> The failure was all about perceived risk of vendor failure in this
> space. It was recognised that the technology was very good and so it
> was considered but the commercial risk assessment meant that we also
> had to score it based on our ability to rip and replace should the
> need arise...
How does this compare to making a similar commitment to other vendor
SOAP-based infrastructure? It seems to me in either case to get
functionality beyond a simple SOAP request/reply interface, one has to
sink a certain amount of cost into a vendor choice.
An alternative is an open source ESB, but again that solution will be
proprietary. I am beginning to wonder whether a Jini/Javaspaces
approach is viable *because* it has an open API.
Either way these can be integrated with SOAP services when that is the
right or necessary thing to do. I think the SOA community is dancing
around the vendor commitment issues.
-Patrick
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/