June 2004 - Posts
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:
- 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?
- Can we cover different nodes under the same two-phase commit transaction?
- 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?
- In case of failure we have the capability to handle transactions. How should we inform our clients of the problem?
- 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?
Great session! Scott Woodgate is a guarantee! It was a 200 level session, so not so deep in BizTalk architecture and programmability, but really a good session!
Aside from the "standard" contents of a session like this, Scott showed us a wizard, fully integrated with VS.NET, to create BizTalk Adapters that he's working on. He told us that it will be available in a few days, probably next week, on
his blog. Good job Scott! Thanks!
I've just attended this session. Not so exciting, probably because I was already aware of many of the contents. The interesting thing is that it's confirmed the support for IXmlSerializable in .NET 2.0, even if the GetSchema method will be ignored by XmlSerializer, that instead will call a method defined through a new attribute called XmlSchemaProviderAttribute (something like [XmlSchemaProvider("MethodName")] on top of the class...).
We've also seen a demo of HttpListener class, hosting a Web Service using http.sys, on Windows XP SP2 (also available on Windows 2003, of course) in order to be able to host Web Services without IIS on the client side, for notification purposes for instance.
A non-standard :-) session, based on Q&A instead of slides ... It was a good idea Don, expecially in a session late in a long day.
The key concepts of this session, as I understood since my bad English understanding :-), were:
- SOA: Set of ideas for structuring software
- Protocols: not just ideas but concrete to move the bits on the wire
- Web Services: a set of protocols
- Protocols natively supported by Indigo (out of the box ... in the future...)
- SOAP over HTTP (one-way and request/response)
- SOAP over TCP
- Not faster than HTTP
- Duplex messaging
- SOAP over IPC (locally for security reasons)
- Faster than HTTP and TCP
- Duplex messaging
- SMTP: there's no time... if we won't Indigo before 2009 :-)
- MSMQ: why not ... may be...
- A kind of TCPChannel + BinaryFormatter will not be supported because in .NET Remoting, using tcp+binary, there're some issues:
- Version brittleness: you pay the pains of versioning
- Performance issues: it's good but not great, because of lack of testing and evolution during the time
- Security-ness: there's no security built-in
- In order to work with a "contract-first" approach in .NET 2.0 we can:
- Use WSDL.EXE /SERVER as before
- WhiteHorse designer
- WSDL (XML) editor provided by VS2005 with intellisense (great!)
- Third party tools :-)
- OO is like microelettronics. Every microchip needs its socket, with the right number of pins. When we use Objects we're using something with which we're always 100% comfortable and build to do exactly what we're asking it to do. Object are difficult to version. There's no way to have real transparent versioning.
- SO is for agile development and deployment, for field replacement and great versioning. Share schemas and contracts in order to achieve these goals. SO doesn't require to share DLLs on both the sides. So deployment and versioning are easier than with OO.
- SO in Longhorn:
- for instance WMI will be redone in SO
- Business Agents: the next buzword (in TechEd 2006... stay tuned :-) !)
- Many other questions will be answered on Don's blog.
Microsoft has just announced: SQL Server 2005 Express Edition, Visual Web Developer Express Edition, Visual C++ Express Edition, Visual C# Express Edition, Visual J# Express Edition, Visual Basic Express Edition!
Enjoiy the Express community :-):
http://lab.msdn.microsoft.com/express/
Thanks to Roman Kiss we are able to move SOAP messages over MSMQ with WSE2 !!!
http://www.codeproject.com/useritems/SoapMSMQ.asp
Microsoft Smart Client Offline Application Block makes possible to build applications that are network aware and that are able to work online or offline. When offline you can enqueue messages for central services using many different kind of QueueStorageProvider. One of the pre-built QueueStorageProvider is MSMQQueueStorageProvider that, as you can argue from its name, is a queue provider based on MSMQ. It works with a private queue not transactional by default. Sometimes it happens that you would like to make your messages persistent in order to keep trace of them in case of your Smart Client host shutdown, reboot, crash, etc.
In order to have a MSMQ Queue that keeps track of messages even if you switch off your client you need to mark your messages as Recoverable. To do that you can do either of:
- Set to true the property Recoverable of a System.Messaging.Message instance before enqueueing it
- Mark the queue as transactional
By default MSMQQueueStorageProvider, doesn't use a transactional queue and doesn't mark a message as Recoverable.
Here is a code snippet to replace in MSMQQueueStorageProvider in order to have Recoverable messages:
///
/// Responsible for storing array of bytes into MSMQ
///
/// Object as a byte array to store into MSMQ
override protected void DoEnqueue(byte[] objectToStream)
{
Message msg = new Message(objectToStream);
msg.Formatter = queue.Formatter;
msg.Recoverable = true;
queue.Send(msg);
}
Hello everybody!
This is my first post in my new English blog, hosted by asp.net staff (thank you guys!). Here I'd like to write some ideas and contributes about XML, SOAP Services and .NET.
As a Web Service designer, developer (and lover :-)!) I liked very much the discussion about "DataSet vs Custom Entities" that involved many blogs during the last two weeks, so I decided to give my own contribute to the discussion.
Here you can find a brief article about my point of view.
More Posts