Ralf's Sudelbücher

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.

Knives back in our boots I like Clemens' new post quite bit. Or even: I agree with his solutions for the scenarios depicted.

However, I know few developers who are going to build such kind of systems within the next 10 years. Or to be honest: I know none.

That doesn´t mean, I think there are none, but only makes a statement about the 5000+ developers I "touch" each year.

As useful and necessary Clemens´ solutions are, I don´t think, we can motivate those 5000+ developers to adapt them anytime soon. Plus, I still doubt they make sense for all of them. At least as long as the technology to implement them is not here and easy to use. (Always remember COM+: A good technology and sound concepts below it do not guarantee broad success and adoption of the ideas!)

This is why I still cling to the notion of in-proc resource components. Or maybe I should call them light weight services? ;-)

Anyway, I don´t see Clemens and me that far apart in our views. We´re just looking at applications of different scale. This becomes clear, when I say, that Clemens´ "data services" are treated as separate applications in my architectural picture. Just because some component delivers data, I don´t think it can only be a resource component. If it´s big enough (or independent/autonomous enough) sure it can be made into an application of its own. SQL Server for example is an application of its own - but my application should communicate with it thru a resource component wrapping an abstraction layer around its services.

So let me refine my overview picture like this:

Resource components (the green boxes) also communicate with applications - if they represent data sources/sinks.

Now, you could say, make the green boxes part of the orange ones (applications) and you´re in a service only world. Yes, right. But I find it valuable for developers to actually see the resource access components - and have alternatives: Sometimes data access is using another application (service), sometimes not.

Even though I´m very much in favor of clear rules, I think this much "doubt" (like Clemens calls it) is perfectly ok or even necessary in terms of an easier migration path to a service oriented world.

Since developers today still think in applications (not services) I want to provide them with a picture as close to their thinking as possible. That means: leave as many concepts in place as possible. That´s why I just moved around the boxes in our common architecture picture. I did not remove "frontend", not did I remove "data access". Me believe is, this way more developers can relate to what I´m proposing.

Well, well, fellow German RD Clemens Vasters obviously found some time to read my blog between his job as a (probably fulltime) "architecture consultant" and writing "more code on a monthly basis than some full-time application developers"; so in his blog entry he honors me with some mentions of my recent "discoveries".

Unfortunately I see some misunderstandings between us. So let me reply on a couple of aspects of his posting:

:::"The 'onion' [...] resembles the notation that Steve Swartz and I introduced": Well, I´d say, I did not claim, I invented "the onion". And neither invented Steve and Clemens it. It is a common design pattern.

Also, not any two things looking the same, actually mean the same. Clemens' picture of an onion in his post is a picture of a service. My intention, though, was not to describe a service. Right to the contrary: So far I haven´t made any explicit statement about how I´d say an "application" should be structured. Rather I left this to SOA. I´m (currently) explicitly not concerned with inter service communication.

:::"What Ralf descibes [...] is in fact a 'data service' as per our definition.": Well, Clemens seems to want to map any circle to a service. But he overlooked that I explicitly said, my (!) resource components (usually) live in the application process. And I mean it. There is no necissity to put data access into a service and deploy it pretty far away from its clients. Sometime it might make sense, sometimes it doesn't.

:::"Delegating resource access to autonomous services instead of 'just' encapsulating it [...]": As already said, sometimes it is good to set up a service for accessing a resource. But I don´t want to belittle the option of "just" encapsulating a resource in an in-proc layered component. If you have a hammer, everything looks like a nail. So if you´re working on service infrastructure, like Clemens does, probably most everything looks like a candidate to be made into a service. But as much as I like simplification and unification, I don´t think we should see everything thru service glasses.

:::"Now... Ralf [is] very concerned about streaming data": No, I´m not very concerned about it, but saw a deficiency in Microsoft´s message to the developers. Microsoft´s (current) view on data access is expressed in it´s implementation of ADO.NET. And this view leaves out streaming data access (to databases). (No, DataReaders are not enough. And pointing to ADO Classic is not enough either.) I just said, I understood the point many developers wanted to make, when they asked, what to do with huge amounts of data.

My intention was to give two clear rules: 1. Never use streaming access between frontend and application (service). 2. Streaming access within (!) an application (service) is ok.

:::"Now, I consider data consolidation [...]": I don´t see, why data consolidation (here: reporting) should be inherent to a data store. As the term says, a data store stores data. Why should it print a report on it? Although traditionally it is like this, it need not to continue to be like this. Consider, for example, "data consolidation" across several data stores. Which data store should be responsible for it?

Sure, a data store like a database can and should provide aggregation functions, cross-tabs and the like. But it should be devoid of a presentation layer like a report engine.

:::"A reporting rendering tool shat get pre-consolidated data": I totally agree. A reporting tool should only be concerned with formatting consolidated data. No calculations necessary any more.

:::"Also, Ralf´s proposed delivery of data to a reporting engine in chunks": I´m not proposing delivery in chunks. My point was just to push data to a reporting engine, rather than let the reporting engine pull it from a resource directly (and even do consolidation work on it). Reporting engines must not circumvent application logic!

:::"[...] doesn´t avoid [...] co-locate all received data": I don´t make any statement as to how and where a reporting engine should store data or how it should handle it. If data is consolidated within the application and pushed to the reporting engine in the right order, the reporting engine probably needs not store much data during report production.
(This is of course may be different, if Clemens means a reporting engine stores all data in an intermediate format first.)

By the way, if a reporting engine is designed as an application itself, it could host application specific resource components and get streaming pull access to them. That´s fine with me.

:::"What Ralf leaves a bit in the fog is really how the reporting engine learns of a new reporting job, [...]": Yes, sure, why should I clear the fog. My intention was not to talk much about the details of reporting.

How should a reporting engine learn about a new job? Maybe by establishing a TCP/IP connection with it and sending some appropriate information? Remember, from the point of view of an application, a reporting engine is a data sink. So streaming push access is allowed.

Where should results be delivered to a reporting engine? Maybe thru a TCP/IP connection? Maybe thru a service call? It´s the responsibility of the reporting engine´s resource data sink component.

How to deal with concurrency? What does Clemens mean? Concurrent data access? Or several reporting tasks at the same time?

:::"Ralf doesn´t mention context and how it is established and also doesn´t loop his solution back to the layering model he found.":  Hm... which context does Clemens mean? In his posting he has a tendency to become a bit obscure when things get interesting (e.g. "context", "but I don´t want to get carried away here"). And what does he mean by "loop back his solution"? I embedded my view on reporting/stream data access in my application model. And I did not intend to be more specific with regard to reporting.

:::"The reporting service shall be autonomous": Maybe to Clemens´ surprise this is ok with me. If so, though, it is important, the reporting service cannot circumvent my application logic. It would need to go thru either the application or one of its data source resource components.

:::"What´s needed is simple a message/call exchange pattern [...]": Sounds good. Sure there should be duplex communication between services. But this should not be limited to message exchange. Message exchange is good to span larger distances between components. But not all components need to be set far apart. This is why in app architecture picture I distinguish between applications and resources. Applications and frontends or other applications are removed from one another. But applications (or business logic) and resources can reside in close vicinity.

Again, even though we need to move to more service oriented thinking, not everything is a service.

"Bottom line [...]": I agree with Clemens here: Sometime pull is good, sometimes push, and to have duplex communication is excellent.

To wrap it up: I don´t want to replace Clemens' and Steve´s view, but rather complement it or refine it here and there. As much as I like their approach, I still think it provides too few concrete rules. Plus, it starts at a point, where many developers are not yet. Without first changing the developers´ view of application architecture slightly by bringing application logic into the center of their thinking, they won´t be able nor willing to jump on the service bandwaggon. That´s what I´m concerned with.

First shift application logic into the center of the app architecture view, then explain what happens with frontends and data access. Then wait for this change to settle in. And not before several months (even years?) have passed expect the majority of developers to breath SOA.

We´ve seen the MTS/COM+ desaster: barely anybody knowing or using Microsoft´s Applicaton Server. This must not happen to the next technology. So, rather than wading knee deep in theoretical discussions I prefer to pick up developers where they are right now and provide them with a "migration path" for their thinking.

Well, what is left now is to say: Hey, Clemens let´s drink a beer and push the knives back into our boots, ok? ;-) (Upps, look at this, mine was just a rubber knife anyway :-)

If you´ve been following my thoughts on changing our view of the application architecture (of business apps), then you might have gotten the impression, I´m very firm in my views and want everything to be governed by clear rules not to be broken.

Well, this impression is not wrong.

Yes, I´m very much in favor of clear rules. And I think there are not enough of them yet in the software business. Patterns are a start. But we need more rules, clear rules. Rules telling us when to do what - and not to think about it for a long time.

Every art and trade has rules. But most of the time, they are rooted in the inevitable: in physics, chemistry, mathematics. Bot so in our software business.

There are no physics putting harsh constraints on how we architect our software. When architecting buildings you can´t cheat. Physics will claim its toll if you calculate the statics wrong.

But with software it´s much harder to know beforehand, what will happen to a certain architecture. And even more so, if there are barely any architectural rules.

That´s why I'm so firm in stating my believes. Also, I have come to hate the conjunctive and making my statements relative (so as not to hurt anybody or paint myself into a corner).

If we continously use the conjunctive and make fuzzy statements using "mostly", "sometimes", "it depends" etc. we loose the ability to clearly communicate.

So I prefer to make clear statements - even though I run danger of being misunderstood.

But don´t get me wrong: Even though I try to phrase clear rules and lay a narrow path, I´m always open for rational discussion. Always! And I don´t fear making mistakes. I allow myself to change my view any time, if I find a better one.

And one last statement in favor or more rules: Only where there are clear rules and mastery of them, creativity can flourish!

Yesterday I drilled down into my new view on application architecture to explain, how I think frontends and application should communicate.

Today I want to drill down on the relationship between application and resources. (For the relationship between applications consult the SOA literature.)

To do their work, applications rely on services provided by resource components. Resources are passive, in that they don´t demand functionality from the application. Frontends on the other hand are active, as they trigger application functionality.

Resources are about data. Which does not mean, they are necessarily concerned with databases. A resource could, for example, be a source of random numbers generated by some hardware attached to a computer.

Applications need data resources for their work. Resources live close to an application and can be classified as data sources or sinks.

Resources can be categorized as data sinks or data sources or they serve as both.

But regardless, their services should be offered thru an interface facade. On the outside, resources thus look like applications. This again fosters decoupling etc.

However, resources are typically not living on their own. They are not applications, but rather helping applications by living close to them, i.e. usually within their process. From this follows, the data flow between application and resources does not necessarily be in a disconnected manner. There can be streams between applications and resources (while some application message endpoint triggered by some frontend is doing its work).

Nonetheless it´s advantageous to model the outside of resources with interfaces. But those interfaces can function as factories for deep object hierarchies connected to the resource. I think, that´s perfectly ok. But if you like, sure you can work with resources in a disconnected way using disconnected data containers to move data back and forth.

A resource component itself usually has the following structure:

Usual structure of a resource.

A resource component encapsulates a resource. This can be a database, a TCP/IP connection, a RS232 interface, a file, a process controller etc.

The resource component uses the resource thru an API. This can be ADO.NET, System.Net, System.IO etc.

Now, the important part about resource components is, an application does not use the API directly, but rather a higher abstraction. However, by that I don´t mean a generic data access layer around ADO.NET (like the data access building block), which I call "Low Level Resource Access Layer" (LLRAL). Such a LLRAL is nice to have when implementing a resource component, but by no means necessary.

Necessary, though, I think is an interface providing access to the resource in terms of the problem domain of the application. If the application is about order entry, then a resource component encapsulating the database should for example provide an interface with a method called GetOrdersOfCustomer(). In the case of database resources, the resource component should abstract away the resource, so that there are no more SQL statements in the application.

Where the LLRAL is nice to have, the High Level Resource Access Layer (HLRAL) is a must!

That said, now for a special case of a resource, that boggled my mind for quite some time. I´m talking about streams of data.

When trying to convince developers to use DataSets they mostly nod and they "Sounds nice, but...". And they mean: But what about use cases where I need to work with streams of data, where I need to work with millions of records in a database? And they have a point there.

But now I feel I have the answer:

• Streams of data between frontends and application are always "evil". Don´t do it. Ever! Forget about displaying three million records in a WinForms DataGrid. Always use disconnected data containers!
• But streams of data are perfectly fine between application and resources! So if you like, go ahead an open a ADO classic Recordset by calling a resource component method. Move up and down the cursor as you like - within the call stack originating from a single method call on an interface of an application. As long as you´re in this call stack, the application logic is stateful and all´s just fine.
  And if working on those three million records takes longer than a second, do the processing asynchronously within the application.

Sounds easy, right? But then, what about reporting? And this is, why sticking with this answer had been difficult for me. Reports often work on huge amounts of data. And reporting engines are frontends or are used in frontends. So they´d need streaming access to data. Right?

But giving reports streaming access to data is against the programming paradigm of applications described so far.
Firstly, because all data transport should be using containers. Secondly, if reports circumvent the application and directly access a data source, no business logic gets enforced. Both is bad.

The solution to this came to me yesterday morning: Our current view of how reporting should work is wrong. Crystal Reports and even the new SQL Server Reporting Services are based on direct access to the data they report on. They pull the data they need from the data source. And that´s not good. No, no, not good at all!

Rather than allowing reporting engines to pull data from resources, we should push the data to them. And that´s the responsibility of the application.

Reporting in the future thus should look like this:

Either a reporting engine is capable of pulling data from our application, thereby following all our business rules. Then reporting on the frontend is just fine - but it is limited by how much data can be packed into a data container.

Or, and this is the solution to the sceptical throwns of the above developers, or a frontend triggers the application to produce the report (maybe asynchronously). The application then pushes the data to report on to some reporting engine data sink. The application could, for example, open a ADO.NET DataReader based on a complex SQL Join, and pass each record to the reporting data sink in a generic name-value data container or via a TCP/IP connection. At this point, we don´t need to care how this happens, whether the application gets some help from the report engine or not. Most important is, the application pushes (!) the data to the reporting engine. Then, how the reporting engine processes the data or on which computer it is located, is not important either at this point.

So this is my message:

Whenever you think you need streaming access to data, only think of doing it within the application, never in the frontend! And if this streaming access so far pulled the data itself from a resource, think about switching to a push model, where the application sends the data to your processing logic. Rather than a frontend implement a resource component.

In my last blog entry I suggested a new view on basic application architecture (at least for "business applications"). The purpose: to change the patterns in which developers think, so concepts like Application Server no longer are deemed esoteric tools for only a few.

However, yesterday´s post only showed a very high level picture. Today I want to clarify two things and drill down a bit.

First, as Christian Weyer pointed out, the picture left it open, if a frontend would be allowed to access a resource directly. The answer of course if no! So the picture now puts the application and the resources in a box, and the only entry point into that box is the application.

The frontend is not allowed to access any resource directly.

Second, the question arises, where does SOA (Service Oriented Architecture) fit into my view? As far as I understand SOA, it´s all about communication between services. Since in my view applications are the equivalent of services, I´d say, SOA is concerned with connecting different applications. SOA is about the orange boxes and the red lines in the following picture:

SOA is about communication between services, so it´s about connecting applications.

Sure, this is a broad generalization, but I guess I´m at least not mistaken when saying, SOA is not concerned with frontends, nor with resource access.

That said, now for the drill down. Several parts of my view of the application architecture need refinement. Let´s start on the left of the picture. The relationship between frontends and application:

Frontends interact with the application thru service interfaces. Whether these are implemented as Web services or Serviced Components or something else, is of no concern here. That´s an implementation detail. Most important is...

• those interfaces are just plain lists of functions.
• data is exchanged between frontends and application by value. (All parameter data types need to be serializable.)

Complex data (e.g. database records) needs to be put in a container.

Communication between frontends and application always uses containers for data transport.

That means, communication between frontends and application essentially is message based. All data passed to frontends is disconnected from its source. So don´t even think about scrolling thru some 5,000,000 records in a grid in some WinForms frontend.

Frontends don´t do any (heavy) data processing. So there should be no need to return large amounts of data to them from the application or pass large amounts of data to the application. Yes, that means, frontends don´t do data import themselves. And frontends also don´t do reporting (on large amounts of data). There is no streaming data access by a frontend!

If you feel the urge to retrieve large amounts of data (where large means, you don´t trust a dataset with it) whatever component you´re thinking of, it can´t be in the frontend!

This might sound rigorous and it is. I mean it.

Why? Because we need firm (!) guidelines for architecting applications. And my opinion is, this is a good guideline for 98% of all business applications. (Ok, maybe just 95% of all business applications ;-)

It provides several benefits:

• It decouples frontend and application.
• It makes the relationship between frontend and application robust.
• It makes it easy to understand.
• It makes it easy to test.
• It allows for orthogonal services on the service interfaces.
• It assigns clear responsibilities.
• It is the foundation for distributing frontends and application to increase scaleability.

Does that mean, an application system necessarily is a distributed system? No. But more on that on another day.

Web services were yesterday. Today is SOA (Service Oriented Architecture). And what´s tomorrow?
The only constant about buzzwords is change.

But as much as I like the SOA idea, I think many, many developers are so far away from the concept in their thinking, in their applications, it will be very hard to get them hooked. Even after 8 years of MTS/COM+ the concept of an Application Server has not taken hold in the (German) developer community. An ad hoc poll among some 100 developers in a session at the recent German DevDays showed: only 5-10% knew what COM+ was, and none (!) used it in their application.

And even if I´m optimistic, I´d say, only maybe 30% of Microsoft oriented developers have a grasp of COM+. And maybe just 10% of them actually use COM+.

Given, that not all projects need COM+ or Web services or .NET Remoting, surely many more than todays would profit from those technologies. But developers don´t even give them a try.

Why? Because their view of the basic application architecture is still rooted in the 1980ies. They think, their applications are whatever they see on screen. For them the frontend is the application. (Even though, they are using objects and are building some components.)

This like locating your self right behind your eyes in your head. But that´s just one view of the world. Other times have been and other cultures are thinking differently. And it´s even changing in the western world. More holistic views are appearing. A person is not just it´s brain. There is no homunculus in your head.

But how we view the world determines how we interact with it. Thinking of our selves as sitting behind our eyes and steering a body separated from us models our whole world from interaction with other people to medicine etc.

So I think, our view of how applications should be architected does the same for our perception and use of technologies.

The current "canonical" idea of an application architecture, the dominant meme so to speak ;-), looks like this, I´d say:

Current "canonical" application architecture picture.

Frontends are on top (or on the left), the BL is in the middle ("middleware"), and on the opposite side sits the data access layer (invisible for the frontends). This sounds plausible, looks ok, and is not even wrong. (As it is not wrong to locate at least major parts of our self within our heads.)

But this view of a basic application architecture still suggests, it´s good to start with frontends. Frontends are important. Frontends are hosts for BL. etc.

But this is only a limited view. It causes the 1980ies thinking to continue. Application servers don´t seem necessary. Hey, why use COM+ oder even a .NET Remoting console application when I can host the BL in my frontend. And if I can do that, why rigorously think about a service facade in front of my BL. Plus: What is BL anyway?

My opinion is: Unless we change the basic picture of how applications should look, the majority of developers will not change their thinking. They will not adapt (quickly enough) to Web services or any other kind of services. And that will make life more difficult for them in the future.

Thus I propose to aggressively promote a modified picture of an basic application architecture:

Suggested "canonical" application architecture picture.

It contains the same players, the same terminology, but moved around the boxes. Seems a small change, but I think it´s an important one.

The Businesslogic now sits in the middle and on top! And I replaced the somewhat fuzzy term "Businesslogic" with "Application". The BL is (!) the application. It´s the heart of what a programm is supposed to do.

All other stuff is nice to have, so to speak ;-) Frontends are nice to have, but not necessary for a particular BL (or application). An application could be started by just loading it into a host (Applicaiton Server).

Resources are not necessary either. An application could just communicate with frontends and keep state in memory. (Memory is no resource worth mentioning in this picture as are databases, TCP connections, the file system. For resources a special API is needed; memory you access thru objects.)

So an application should be just this thing in the middle and on top. Nothing more, nothing less.

Most of the times, though, it is not selfsufficient. It´s no monk meditating in a cave, not eating, not drinking, not speaking. An application needs to interact with the world.

Applications most often want to access resources. And they might want to communicate with other applications.

Although an application could perfectly well just churn on data from resources and be driven by some internal rules, sometimes it´s necessary to trigger it from the outside. Or you want to take a look at its current state of processing.

Only then come frontends into play. I think they should be degraded from primary focus of development to just triggers of events in the application. Frontends trigger processing, they send events to the application and receive data about its state. Sometime this can be accomplished by a scheduled a WSH script, sometimes an elaborate GUI is necessary.

But in any case, the frontend is just an "add-on" to the application.

Only if we change the weights within the commonly promoted picture of application architectures in this way, I think we can effectively change how developers view Application Servers, (Web) services and the like.

Thanks to Christian Weyer and Markus Baulig for giving me the chance to refine my thinking about this idea in conversations with them.

After 5 locations of Microsoft DevDays tour throughout Germany and my talk on building a data access layer and several conversations with colleagues and attendees, I´m now convinced of the following:

-How application development currently is "sold" is wrong. Developers still - after 8 years of Microsoft application server - don´t really understand the concept of application server or the value of business logic components. (And I mean "real" business logic with a service oriented interface.)

The culprit I identified: How we draw pictures of applications. In those pictures the frontend still gets to much weight. The business logic is not at the center of attention.

That needs to change!

The business logic has to be emphasized as the "real" application, its heart.

And this business logic then communicates with resources or services to do its job. Plus, it gets triggered by clients. And I mean "triggered". What a WinForms frontend does or a WSH script is firing an event in the business logic. Nothing more.

So any specific frontend is optional. Sure there needs to be some, but it can be veeeery simple, e.g. WSH script calling one method on the BL, setting it thereby off to work for weeks.

-Secondly I´m now sure we need to change our view of interaction with databases (or resources in general). Databases need to be viewed as services, i.e. we need to look at them through a set of interfaces. "We" in this means any client of a database, e.g. a business logic layer.

Clients of databases must not only be free of db API calls (e.g. there should be no ADO.NET use in BL), but also of any SQL statements.

Clients should definitively view databases only through a list of high level methods. Whether these methods are then implemented by a Data Access Layer as inline SQL or a stored proc, the clients don´t care about.

If data access is implemented this way, binding to a database can be as simple as referencing an assembly or accessing a webservice. The database looks just like a set of methods for retrieving/storing/manipulating its data. And those methods mirror the concepts found during requirements analysis. Those methods know of "Customers" or "Orders" etc. They are specific to a problem domain, not generic. They deal with business entities, not abstract entities like tables.

More in a future posting.

With only one day to go, I´d say I´m at the door step of an exciting new phase of my professional life.

After 12 years of leading my own software company, then after 6 years of freelance work, now from tomorrow on I´ll be part of a new effort where the whole is larger than the sum of its parts:

http://www.thinktecture.com

Although I love to be independent, this team truely is very special, vibrating with ideas, motivation and enthusiasm - and also fun to work with!

Many things have changed since the stoneage. Many!

But some things have stayed the same. For example: It´s easier to conquer the world in groups.

So, why should I defy this constant of our conditio humana? ;-)