A few weeks ago I asked folks to think about where they were using rules within their architecture (see the original post here). I thought it would be a good idea to peel back the layers a bit more and dive into where RFDN fits within a prototypical ASP.NET architecture while also including WCF and WF.
I superimposed the likely integration points for WF (the same could be true for BizTalk) and ILOG Rules for .NET (RFDN). In this diagram, WF is operating as an aggregator of service end-points. This is the most logical use of WF since it covers the most widely talked-about BPM/SOA technical use cases. Within the WF process, RFDN is called as just another WCF end-point to be aggregated. Decisions are based upon the state of the process data at any point required for the process.
The execution object model (XOM) is typically referenced at all levels of the diagram since it represents instances of transient data that pass across tier boundaries and establish the data portion of the contract within the interfaces. In using WCF I have found that at times it may make sense to have a slightly different set of parameters used for the WCF service contracts verses exposing the interface of business objects directly. This is the same issue one has when wrapping a simple a data access object (DAO) method with a similarly named business object method. They may remain one-to-one for a while but eventually many wrapped methods will evolve independently and require additional behavior.
Finally, I added WF to the business tier because upon review it could be a better way to aggregate lower-level in-process object calls with out-of-process services. Orchestration adds some over-head, but it may reduce the complexity of a specific method. Obviously one has to weigh the cost/benefit for each method before employing WF to solve the problem.
RFDN adds value at just about all levels of this architecture. It can be use to establish how to stream the GUI for a portal all the way down to the database and be called by a stored procedure (I don’t typically recommend this but customers ask about this all the time). Moreover, it is essential tooling whenever you need to analyze the state of data at any given moment and you find that your code has suddenly become non-trivial.
It is true that I have omitted many other interesting frameworks and tools such as O/R and LINQ; but in spite of this, does this architecture look like something you could get excited about? Please post a comment below and tell me about your architecture.