Share via

Positioning FABRIQ - What? Why? Apple or Orange?

  • Article

Originally Created: 2004-07-06

What is it?

FABRIQ is a light weight, high performance, scalable, one-way only, asynchronous, XML messaging system written in managed code using the .NET Framework, Microsoft Messaging, Enterprise Services and WSE.

It is an instance of a message based architectural style using queues and these kinds of systems have interesting characteristics and I cite the work of J.D. Little; Buzen and Denning; and Connie U. Smith which prove that queuing networks are predictable and controllable which is enough to convince me to pay then some serious attention.

And Shadowfax (EDRA)... what gives?

Shadowfax focuses on the transport/biz-logic decoupling problem. FABRIQ focuses on high performance and scalability to be credible in the high volume transaction processing space. We have worked in the Securities settlement industry and Investment Banking back office operations for many years and specifically have studied and worked on trading exchange solutions which used queuing nets with great success.

We were also interested in exploring ideas that had first surfaced when we built the original Q.NET prototype (that's old stuff, >1 year old!) particularly the notions of application composability from parts (which is not similar to the now-defunct Oliver Simms NeWI system of the late 90s… did NeWI have composability as a first-class principle in the design of its distributed nodes of Biz Logic components?… anyway that’s likely to be a Red Herring).

What we had in mind for FABRIQ was a grid-like architecture where grid nodes support composable units of functionality. It might appear high-brow to think so, but that’s a key idea behind manufacturing assembly lines and it appeals to us as Architects, and we’re not suggesting for a minute that FABRIQ is related to any emerging thinking around MDA and Software Factories!

If we had used Shadowfax pieces to make FABRIQ, we would’ve had to rip Shadowfax apart quite dramatically to make something that resembled FABRIQ functionality. The way in which FABRIQ dispatches and routes a (SOAP) message is quite different to Shadowfax. It would not have been worth it.

The FABRIQ hosting model is also based on ES – an essential requirement for us, just because we wanted a decent container to better EJB containers; remember many of our enterprise customers already have J2EE so they think "containers". It turns out the choice of ES instead of IIS/ASP which has some weirdoes that make it unsuitable as a long-running runtime host/container thought it is very suitable as a web host.

Our other criterion was to offer a programming model that would sort of resemble what we’d expect to find in Indigo in the long term. So, eventually we’d like to rip out WSE and 50% of FABRIQ and just plug in Indigo. That’s why our message class is similar to Indigo’s.

We use WSE fully and WS-Addressing routing semantics are fundamental to our design. We carry message state only in the message header. And to get a message out of a FABRIQ node you have to create a new message and re-use the (possibly enriched) header.

So, if someone asks you if there’s a “strong” similarity between EDRA and FABRIQ, please say:

FABRIQ is quite, quite different in purpose and design to EDRA. FABRIQ is a one way only messaging network leveraging WS-Addressing for routing. It doesn't have pluggable transports and the notion of service and implementation pipelines. FABRIQ doesn't have business action endpoints as targets. FABRIQ doesn't support request/reply semantics. It doesn't have a context object. All state flows with the message. FABRIQ doesn't deserialize the message at all. It can manage pipeline faults elegantly. It provides "business logic composition" instead of the business action target endpoints of EDRA. The fact that FABRIQ uses the pipeline architecture design pattern like EDRA is one cause of confusion between EDRA and FABRIQ.

Apple or Orange?

You'd be surprised what people try to compare together ... a constant problem for us in Microsoft, and why positioning is so critical. And for me, as co-lead on FABRIQ, I am keen that we really position FABRIQ and EDRA, amongst others, in their right place. Some people have told me that they can use FABRIQ to do what BizTalk does. That's just ludicrous!

As we’ve released the source code on GDN for all to download and use, one is free to do what ever one likes with it, but we (Microsoft and newtelligence) reserve the right to state how FABRIQ was designed and what the recommendations are for its "intended" use in building solutions.

And what about FABRIQ and SOA?

There is no limit to man's imagination – God gave us brains! But as the creators of FABRIQ we are NOT positioning FABRIQ as an SOA framework per se. In fact, we would not recommend it to be used this way unless one really wants "pure" one-way only asynchronous messaging.

Naturally, FABRIQ can be used within a service-oriented environment – and probably best as the implementation of a "Service" and most likely fronted by a Web service facade (or a proxy that can be auto-generated, if you're keen, from the metadata in FABRIQ’s config file). This is how we talked about FABRIQ and SOA in our Architect Forum and Tech-Ed presentations.

FABRIQ was designed primarily to address performance and scalability for one-way asynchronous message-based transaction processing systems. And as we’ve seen already good example of such a system is a Stock Exchange's securities settlement system.

Now, as far as I can tell EDRA is not positioned today as an SOA framework. It is an SOA-enabling framework.

There’s so much more to SOA than our small but very intriguing frameworks!

Comments