Talking about Fabric, I would like to jump in and ask for comments:
To use fabric from the client side, someone gotta use the fabric API to take advantage of the binding to dynamic end points. It is not “transparant”.
However, this is completely anti-SOA because it creates a strong dependancy between WebService requestors (client side) and a specific WS infrastructure implementation. Fabric binding technique is not a standard and not interchangeable with other WS infrastructure tools.
SOA as it is described on many reports and articles focuses a lot on decoupling entities by using WS standards. Even middlewares are bound to support native WS interfaces (for instance with WS-Notification).
So I am surprised Fabric is presented as a SOA enabler even if it helps somewhat decouple. But for me, decoupling means: no platform, no hardware, no vendor, no language dependancy.
My article demonstrates how to use Fabric’s location transparency and failover capabilities from webMethods Developer without using the Fabric API. The getting started guide shows how to do the same thing from a .Net client for which there is not yet a Fabric API.
Specifically which WS infrastructure tools are you referring to? We’re all waiting to see which WS standards emerge to help address these issues.
Actually, what I was refering to was to take advantage of the Fabric (UDP) based discovery of fabric nodes… dynamically.
In fact, I should have created another discussion thread, I was not comenting on the document, sorry for any misunderstanding.
In the scenario you described, the fabric server (port 8006) is the point of failure, and if it is down, there is no automatic failover. So we improve failover on front of the WS servers but we create another point of failure.
My understanding of UDP discovery is that it ensures that even if a Fabric node is down, another node can pick up. This option requires Fabric API, and this is why I was talking about WS non-standard dependancy.
If I still want to not use the API and have guaranteed failover with option 1, I can of course use a redundant load balancer to overcome the single poinf of failure, but in this case, I can very well use it to failover between WS servers directly, not fabric servers. Good LBs can also do message routing based on XML content (put aside the issues related to price).
Regarding WS infrastructure, of course, there is no such “out of the box” thing at this time, and not all the WS specs are implemented or even approved. But it is still possible to incrementaly build a service oriented architecture, such as new components can be added later when the product offering evolves or becomes mature. In such architecture, it should be possible to replace component without important change on the infrastructure or recoding. And all the WS standards to come will hopefully help doing this (this is may be an utopia, time will tell).
It is still pretty vague how this can be done at this time, but it will hard to achieve anyway if part of the architecture is dependant on non-standard (regarding interoperability only), for instance the UDP discovery of WS end-points.
To end my post; I would rather see Fabric as a distributed UDDI server, with possibly other stuff (WS-Policy, WS-Security, etc), that’s something any SOA thing will need anyway.
I agree that using the URL approach outlined in my article does create a single point of failure. That’s one reason I spent the time to learn how to deploy a Fabric server in Integration Server’s embedded Tomcat instance. I suggest in my second article that good systems management practices will lead companies to deploy Fabric nodes in robust, carefully managed servers.
Since you can already use the UDDI API to access Fabric’s distributed registry database, I think what’s missing from your wish list is for the WS-* standards to mature a bit to see which will be worth building product around.
You still have to have a way to discover the distributed registry servers (Fabric or UDDI). UDP broadcast via an API seems to be a pretty reasonable approach for java or .Net clients. Load balancers with or without message routing capabilities seem like a reasonable approach for HTTP clients.
Finally, while I agree that it is possible to build your own services-oriented architecture and that doing so for a handful of clients is not terribly complex, you need to ask yourself, and more importantly your business sponsors, whether doing so is the best use of talented IT folks. Do I spend my scarce IT developer and architect resources on building plumbing and infrastructure or on building functionality that differentiates my business from its competitors?