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.

 

9 Comments

  • I believe that this idea of exchangable hosts is complete nonsense. You can't write your business logic (or application as you call it) without tying it to some degree towards a specific host.



    Security is often part of business logic, it can't always be attached declaratively. Transactions etc. all need to be designed into your business logic and can't just be attached as an afterthought by choosing a different host.



    Well, and finally. How can one write business logic, use the features provided by Enterprise services and not derive from ServicedComponent?!? Beyond me...

  • @David: You´re right in that there is no standard way for accessing app. host services today. What that could change.

    If you find my view desirable (although there still might be hurdles) I´m content.

    Transactions: When you use [AutoComplete()] on a transactional ServicedComponent you don´t see anything of transaction handling within your businesslogic, regardless if it´s put in the ServicedComponent or in a separate class.

    But if you don´t know, if declarative tx are supported by the current host, why not ask its meta info? If the tx flag is false, you can start a tx of your own in your application.

    How can you write businesslogic, use features of an app.host and don´t derive from its base class? Well, only an app.host agnostic extensible means must for doing so must be a available.

    I´m not saying it is there yet, but it is desirable. (And I think, it is not that difficult to implement.)

  • David / Ralf,



    With COM+ 1.5 it is no longer necesary to inherit from servicedcomponent - have a look at servicedomains.



    You may also find Shadowfax on gotdotnet an interesting read. Its is microsofts new reference architecture and is pretty cool.(you need to join the workspace to view it)

  • @Marlon: The reference to "Three-Layered Services Application" (TLSA) you provide is of course valuable and a must read. But my approach differs in several respects:



    -For Microsoft TLSA is optional; I on the other think, every business application should be architected like I desribed.



    -TLSA still has business components in the middle and not on top. This, though, is my main point: Put the business logic first, or otherwise developers will not adopt serice oriented architectures.



    -TLSA is focused on applications accessing databases and only mentions ADO.NET as a data access component. I on the other hand am more general and propose to always (!) write an application specific high level abstraction for a resource. TLSA makes this optional and gives no idea as to how this should look like. I clear drawback of Microsoft´s pattern.



    TLSA thus is more specific in some regards, in other´s it´s less specific than my approach.

  • Hi Ralph,



    I think about your way of Architecture. What i miss... or do you mean in



    [Ralph]

    ...

    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

    ...





    [Me]

    I want refine your Diagramms about your Interfaces between Frontends-Application Facade-Application. Imagine a Tilt-Database, where you see everyall. The job of these TDB's is to send Metadata to the BusinessLogic or Clients, too.



    The Interface to the Client have to transport Metadata to the Client - e.g. a number may not negativ and is an Integer - take form a HEADER in the MESSAGELINE (i miss this description in your article) followed by FORMAT (e.g. XML Schema). The HEADER contains the Parameters of an Message the FORMAT of course the format.



    [[Client]Interface <- [HEADER : FORMAT]Message]MessageLine



    I think this MESSAGELINE is necessary to stay dynamicly on clientside, too.

  • "FDL" exists. It plainly the combination of WS-Policy + Contract. The behavior requirements for an ES component can be expressed in WS-Policy just as much as the delivery assurances for MSMQ or the requiremnts for a WSE Web Service or the requirements for an Indigo service. Likewise, Contract (WSDL, XSD, RelaxNG and any combination thereof) can be used to describe messages that go through al of these transport options.



    We don't need new things; we just to start use the existing things (which don't exist for long yet) in a broader way than the current tooling allows us to do it. WSE2 is a step there and Indigo will be another.

  • @Clemens: It remains to be seen, if the combination of existing specs can and will be combined into usable tools "for the masses".

    I kinda doubt it. But we´ll see.

  • The are design patterns that isolate dependencies on container services. In the Java world (IOC) inversion of control or dependency injection is popular. Perhaps this applies.

  • @Ninse: Sure, IoC makes sense, and I refer to it when I recommend to switsch from pull to push when working with reporting engines.

Comments have been disabled for this content.