Paolo Pialorsi - Bridge The Gap!

Living in a Service Oriented World

FABRIQ: Architecture for High Performance, Decentralized, Agent-Oriented, Connected Applications (ARC405)

Good session about FABRIQ, a new framework defined as an "Agent Oriented Architectural Pattern".
The idea is to provide a framework to architect and develop applications  that need:

  • Scalability
  • Processing of incomplete informations
  • Latency of messages
  • Long running operations and/or transactions

Some requirements for architectures that can be handled by FABRIQ are:

  • Elastic processing
  • Quick scalability
  • Break complex tasks into smaller one
  • Maximize throughput

The solution is based on

  • Primitive handlers (routing, mapping, transform, log, encrypt, etc.)
  • Processing units: composition of primitive handlers in a pipeline
  • Networks: composition of processing units, based on routing rules, that move messages through pipelines of processing units (something like and EndpointReference linked list)

Key point: all messages are delivered with a one-way messaging paradigm. Messages move through agents.

Caveat:  "An agent is a self-contained, problem-solving system capable of autonomous, reactive, pro-active, internally motivated, social behaviour". Those agents don't relate to Business Agents mentioned by Don Box yesterday.

From an implementation point of view we have:

  • Message: the class representing a message. Can handle messages of any size, also very big one (like stream of hundreds of MB). Handles the body as an XmlReader. Provides access to Headers as a MessageHeaderCollection of MessageHeader.
  • IMessageHandler: base interface for message handlers. Provides a method: bool Process(Message);
  • We can build chains of Handlers using IChainableMessageHandler implementations.
  • IFabriqMessageHandler is the base interface for transaction message handling. Transaction are based on two phase commit paradigm with Prepare() method and the consequent Commit() or Abort() one based on vote of the handlers.

Key point: FABRIQ is hosted in Enterprise Services, not in IIS/ASP.NET. We can receive messages through ASP.NET using a IHttpHandler implementation (FabriqHttpHandler) that simply enqueues the messages into a MSMQ queue for standard processing by the FABRIQ engine.

A great feature of FABRIQ is the configuration management in case of many nodes in load balancing. In fact Clemens showed us that FABRIQ uses itself to dispatch configuration files and also .NET assemblies, eventually required, to all FABRIQ nodes automatically. Great idea guys!

Key point: from a security point of view FABRIQ is based on WSE2 engine, using OASIS WS-Security and WS-Policy. Internally messages are converted from SoapEnvelopes to FABRIQ messages and back.

Questions for Clemens:

  1. What about asynchronous message handlers? I can't find them. Probably because from a pipeline point of view we can not parallelize the jobs, should we use parallel nodes with routing rules?
  2. Can we cover different nodes under the same two-phase commit transaction?
  3. What about request/response paradigm? What should I do in order to be able to provide answers to clients? Should I use a request/response Web Service as a front-end and a FABRIQ back-end? Should I use a MSMQ to inform my clients of the outcomes? What else?
  4. In case of failure we have the capability to handle transactions. How should we inform our clients of the problem?
  5. Why did you re-defined ThreadPool? In order to have many thread pool in the same AppDomain and with customizable size? Or am I missing the point?
Posted: Jun 30 2004, 03:34 PM by paolopia | with no comments
Filed under:

Comments

No Comments