Clemens is breaking down FABRIQ

posted Wednesday, June 23, 2004 3:19 PM
Clemens has started to break down the elements that make up FABRIQ.  If you interested in SOA and a real world implementation I'd recommend subscribing to Clemens feed to get the latest scoop.  It's interesting to see the similarities and differences between FABRIQ and Microsoft's Enterprise Development Reference Architecture (EDRA) aka Shadowfax.  I'll definitely be looking forward to the code drop of FABRIQ!
7 Comments

# re: Clemens is breaking down FABRIQ

Tuesday, July 06, 2004 1:22 AM by Arvindra Sehmi    
Hmmm... FABRIQ is quite, quite different in purpose and design from EDRA. FABRIQ is a one way only messaging network leveraging WS-Address 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 business action target endpoints in EDRA. The fact that FABRIQ uses the pipeline architecture design pattern as does EDRA is one cause of confusion between EDRA and FABRIQ.

Hope that helps a little. :-)

# re: Clemens is breaking down FABRIQ

Tuesday, July 06, 2004 1:26 AM by Steve    
I think its pretty obvious to anyone who's looked at the code that they are quite different. You seem to infer from my post that I think they are the same thing, which isn't quite right. They are solving similar problems, which is essentially how to design service oriented frameworks/architectures. The approach they take, as you mention, are quite different. If they were the same it wouldn't be all the interesting to compare them would it?

# re: Clemens is breaking down FABRIQ

Tuesday, July 06, 2004 4:38 AM by Arvindra Sehmi    
You'd be surprised what people try to compare together ... a constant problem for us in Microsoft, which is why how we position things 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 ludicrous.

As I've released the source code, one if free to do what ever one likes, but I (speaking for Microsoft and newtelligence) reserve the right to state how FABRIQ was designed and what are recommendations for its "intended" use in building solutions.

There is no limit to Man's imagination, but we are NOT positioning FABRIQ as an SOA framework. In fact I would not recommend it to be used this way unless you really want "pure" one-way async messaging.

Naturally FABRIQ can be used within a service-oriented environment - probably best as the implementation of a "Service" and most likely fronted by a Web service facade (or a proxy that can be autogenerated, if you're keen, from the meta data in FABRIQ config).

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

# re: Clemens is breaking down FABRIQ

Tuesday, July 06, 2004 5:01 AM by Steve    
Arvindra, Perhaps I should just shut up and listen to what your saying since your the co-lead of FABRIQ ;-) My undertsanding, mostly from reading Clemens' posts on FABRIQ as well as a couple of the presentations I saw was that it was a SOA framework which is why I compared it to Shadowfax. I knew that they were addressing things in different ways but my perception was that they were more similar then perhaps they are. So FABRIQ is more of a messaging framework then a services framework?

# re: Clemens is breaking down FABRIQ

Tuesday, July 06, 2004 5:11 AM by Arvindra Sehmi    
Correct, BUT... the messaging occurs at the application level and not down in the bowels of the infrastructure. Your business logic (custom handler in FABRIQ) has access to the inbound messages "very soon" after they arrive in the FABRIQ runtime.

Keep it coming... we need to have our assumptions tested.

Thanks.

# re: Clemens is breaking down FABRIQ

Tuesday, July 06, 2004 6:56 AM by Steve    
Ok, so FABRIQ provides the plumbing for the routing of messages, unlike other frameworks that hide all kinds of messaging plumbing and processing within the framework FABRIQ allows application developers to access the messages via custom handlers, thus allowing more flexibility in how, when, why messages are processed?

So where FABRIQ really shines is in message oriented systems that process messages asynchronously. In your comment above you mention one way messaging, is FABRIQ only a one way messaging system? If so how are the senders of the messages notified of the "status" of the message? Is that where WS-Addressing comes in? Basically how are the endpoints within FABRIQ notified of the message status, or is that something that isn't really required in the types of systems FABRIQ is designed for? I really need to set aside some time to dig into the code don't I :-)

# Arvindra Sehmi is talking about FABRIQ

Thursday, July 08, 2004 2:41 AM by Steve Eichert    
Arvindra Sehmi is talking about FABRIQ

Post a Comment

 
 
Prove you're not a spammer: 
7 + 7 =