A Changed View on Application Architecture: Final Remarks on How to Host Businesslogic
In the past days I tried to explain, what I think has to change in our application architecture message for the majority of developers now. My main point is: We need to change how we depict the parts of an application (i.e. frontend, businesslogic and backend). We don´t need to introduce new technologies/concepts, but just shift the implicit/explicit emphasize on existing ones.
Today I want to add the last piece to my puzzle: What should the application look like?
The application is the center piece of any software system. Today it is called businesslogic in most diagrams, but I´d rather call it "the application" to make clear, it is the most important part of a software system. (Until now, common understanding was, the frontend was the application. But that led to today´s misunderstanding or ignorance of application servers.)
Changed view of business application architecture. The emphazis is on the businesslogic.
So what should the application look like?
Since it is a library it always needs an application host.
The application always needs a host.
The application host keeps the application in memory, triggers its initialization, and maybe provides infrastructure services. .NET Enterprise Services/COM+ is the first application host that should come to your mind at this point.
But I think .NET ES and ASP.NET are just two of more possible application hosts. I´d even say, as long as they are the only ones, developers will have a hard time adotping the idea of an application being its businesslogic. We need simpler (less feature rich) application hosts, too. (And with .NET Remoting that´s easy to accomplish.)
We need a larger variety of application hosts.
The simplest application host should just host the application in an appdomain of its own and make it accessible thru .NET Remoting. Nothing more. No fancy infrastructure like transactions, security etc. needed. The main service is to keep it separated from frontends and other applications behind an appdomain boundary. This boundary makes communicating with the application very explicit and thus motivates decoupling. My opinion is: Form should follow function. Meaning: If a component is representing my businesslogic, i.e. draws an explicit circle around itself and separating it from other components, than its form should always underline this separation.
So, to actually adapt the notion of the application (businesslogic) sitting in the middle and being most important, it has to be very easy to set up the application in a host. For that, three things are needed:
1. An interface definition of the application´s services. (You can call this a contract, if you will.)
2. The application itself, implementing the application interface.
3. An application host dependent facade to the application.
The application host directly hosts only the application facade (3) (e.g. a ServicedComponent, a WebService class, or a MarshalByRefObject). The facade, though, does not contain your application logic! It just is an app. host dependent container and/or interception component. It can for example acquire services of the app. host (e.g. transactions) for the real application component.
The real application is alway independent (!) of any application host (2). It is never itself a ServicedComponent or a WebService!When you program an application, it should never directly access any app. host specific infrastructure services (although meta-info on the actual app. host should be accessible). This way you could use your application today in a simple appdomain host, tomorrow in a Web service, and then in an .NET ES application. The application itself would never need to change. You just would need to have it called from different facades.
However, the application needs to clearly define its functionality. In order to do this, it should implement an interface (1) which any clients can bind to. Since clients never see the application itself, but a facade, the facade should implement the application interface too.
Now, how to arrive at different application facades and the application interface? I propose a Facade Definition Language (FDL) (hey, it´s just a working title, so please don´t complain ;-) to define the outside of an application. An FDL document would describe the contract of the application (e.g. message endpoints, messages; like WSDL) plus additional requirements of the application in terms of data validation, security, transactions etc.
From such a FDL document an application interface would be generated (as an assembly) which can be used in a client, but which would most importantly be implemented by the application.
And in addition to the interface, application facades would also be generated. Ready to be hosted by on of the application hosts. (Of which a simple appdomain host would still need to be developed.)
The application interface as well as application host specific facades/containers should be generated from an app. host independent application service description.
The benefits of this would be huge: Without changing your architecture, you could start with very simple application hosts and later upgrade to a full blown Application Server. The application service definition would be implementation independent. (An example of what a FDL could do is, allow for method level declarative tx for both ASP.NET and .NET ES applications, although .NET ES currently only supports class level declarative tx. It´s just a matter of the code that is generated for each app.host.)
Ok, that´s it. So much for my first stab at my view of business application architecture. I don´t claim to have invented anything here. And I admit to be pretty ignorant of the wonders of Indigo. But I´ve already seen the impact this slightly changed view of application architecture can have. The other day I did a workshop on .NET Fx programming and used a non trivial scenario to introduce a couple of .NET Fx technologies. At this workshop for the first time I also explained application architecture as layed out here - and the result was stunning. It was so much easier to describe and justify the app. architecture. And nobody doubted a host for the application was needed - but of course, they did not need to swallow the .NET ES pill ;-)
I´m convinced, this is the first draft of an application architecture message that is understandable by a much larger number of developers compared to the current one still showing frontends to be equal to businesslogic.