XAF and Acropolis

A recent post to our XAF newsgroup is asking the following question: "How does this eXpressApp Framework differ from Microsoft's Acropolis framework?"

The question implies that the difference is somewhat hard to spot, and yet it was my first reaction to think that they are really nothing alike, and accordingly the difference should really be very obvious. I guess the truth is somewhere in between the extremes, as usual, and so it takes a bit more thought and effort to find the answer to that question and describe it in an understandable fashion.

There are a number of different angles from which this problem can be examined. First of all, maybe we should all go ask Microsoft a similar question: "how does this differ from XAF (or a bunch of other, vaguely similar producs out there)?" After all, they are the ones reinventing something that tries to occupy a market which is already occupied pretty densely, as well as displacing CAB, which until very recently used to be worthy of sessions at TechEd.

Secondly, we didn't consider the differences between Acropolis and XAF, or even CAB and XAF, when we started the project - simply because none of those were around at the time. Of course we have re-evaluated the market since those days, but the fact of the matter is that there isn't a single feature in XAF (yet?) that is positioned to mimick something that's also in these other products, or even to compete directly with any of them.

Now, these thoughts bring me to the point where we find the actual differences. It's all about priorities, functionality and being a lazy programmer.

(I've said it before and I'll say it again: being a lazy programmer is a good thing because it makes you want to find ways to do your work more quickly and more efficiently. If you need to justify this to your manager, try mumbling terms like "time to market" or "team velocity" in between the shouting.)

Think about it this way: why have we all evolved - well, many of us - from Win32 API programming in C to .NET Framework based programming in OO languages like C#? There are many answers to this question, but they all involve priorities (most of us earn money through programming these days, so finishing an application is more important than creating a global Windows hook to insert another button in an Open File window title bar), functionality (we've recognized that in the majority of cases it's more useful to have communications functionality available in the framework than to be able to m_lpFolder->EnumObjects(m_hWnd, SHCONTF_FOLDERS | SHCONTF_NONFOLDERS | SHCONTF_INCLUDEHIDDEN, &penumFiles)) and being a lazy programmer, which kind of summarizes a healthy attitude that often makes us do the right thing with regard to efficiency.

With this background - what's the difference between XAF and Acropolis? Not surprisingly, it is that both products have rather different priorities and functionality. I can't say whether the Acropolis programmers are lazy, but I can tell you that ours have taken their laziness to a new level, resulting in fantastic efficiency for themselves and XAF. Acropolis focuses on WPF UIs. Full Stop. They do have some extensibility in place to support adding reusable functional parts to the framework, but they are definitely not promising to provide these parts. They mention that other UIs can be used, but they are very careful not to promise to provide these either. It might sound sarcastic, but one of their most important priorities seems to be not to promise much functionality apart from the UI itself.

XAF is different. We do lots of things that Acropolis doesn't have on the menu - let's see, in no particular order, and certainly not exhaustive:

  1. XAF supports multiple UIs - not just theoretically, but really, out of the box.
  2. A very simple summary of what XAF does is "it creates a full data management application for you based only on a single class declaration per data type". I don't think Acropolis even tries to make a claim like this.
  3. XAF has loads of functionality in the package - think of runtime UI customization, Reporting, Validation and the Security systems, to mention functionality on a variety of different levels.
  4. XAF is largely based on mature components and libraries. Data storage is provided by XPO, which has been around for many years and targets more than 10 different database backends. The Windows Forms components (and some of the ASP.NET ones - we'll be  improving on the current status in that area soon) as well as printing, reporting and export support are extremely feature rich, having been developed for years as well. Acropolis doesn't have anything to compete with this.
  5. I feel pretty safe to promise that XAF will be supported for many years, in the worst case. Of course we will deliver the source code once the product is final in a few months. In contrast, what are you going to do with Acropolis today? It's not shipping, in fact it's pretty far away from shipping. And the whole CAB/SCSF/Acropolis thing doesn't look good to me either, certainly not very future proof.

So how about this summary: Acropolis is a framework that allows others to implement application functionality in a modular way. Once it becomes available and 3rd parties do their thing and provide the functionality, you might be able to use it as an efficient way of creating business applications - perhaps, although not very likely in my opinion, even as well as you can with XAF. I don't believe you'll ever reach the same degree of integration that XAF provides, nor probably the same high level functionality. Certainly you can't get it now. Most probably you won't be able to get it in 2008.

As I said, it's all about priorities and functionailty, and well, yeah, being lazy. Remember, it's a good thing.

Tags
11 comment(s)
Mark Gillen

I looked at XAF very briefly but one of my concerns is how to integrate third party controls into it.  It looked to integrate very tightly with all the DevExpress controls out of the box but support for other grids wasn't immediately obvious.

15 August, 2007
Oliver Sturm (DevExpress)

Well, unsurprisingly we don't deliver support for other grids in the box. Next, I would obviously have to ask whether we're talking about the Windows Forms frontend (where our own grid is extremely feature rich, including the fantastically efficient integration with XPO, and as such I can't really imagine how a 3rd party grid would improve on that) or the ASP.NET frontend (where we currently don't use a "real" grid control at all, but will integrate with our new ASPxGridView soon).

In any case, it is a target for XAF to allow integration with any arbitrary UI control out there. In practice it is impossible for us to test each and every control that somebody might want to use, and certainly a grid is more or less the most complex single control you might want to replace. If you contact our support, we will try to help you if you have specific issues. I'm just being a little careful here, as 3rd party control integration is obviously a complex moving target.

15 August, 2007
Jafar Khayatpour

Thanks for the clarification. After you pointed out the reporting, security etc.. the differences become quite obvious.

Will there ever be any kind of web integration with frameworks like DotNetNuke?

For this, XAF would need to integrate with the login providers and also for the web forms to be .ascx controls rather than .aspx.

Certainly something to think about.

I must admit that I am relishing the thought of being able to create applications where all of the framework has been done. Could this be the silver bullet most of us are after?

15 August, 2007
drew..

Oliver, that was a great post, informative and entertaining too! thanks!

15 August, 2007
Visma Retail Software

In my mind there’s no doubt that you guys have something good going with XAF. I’m eager to get going on a LOB application using XAF and see how well it satisfies my needs.

Neither the CAB nor the promises we’ve seen so far from the Acropolis team makes these products any threats to XAF. Both products have a somewhat different focus and target than XAF. (Besides they’re free.)

Even though XAF may be more feature rich than to other frameworks, it’s not always an option to use XAF. Sometimes customers have requirements too. Heavily depending on one vendor as the case is for XAF worries a few of our customers. Some even mentioned an “incident” when a certain Delphi component company withdrew from the market and left us with a set of components and an embedded database solution well below par. We definitely don’t want to find ourselves in that situation again.

Besides, some of our customers want to divide the module development between different departments and companies. They rely on us to deliver the core of the application and use in-house developers for a few of the modules. If XAF require all module developers to have a XAF license, it would be out of the question for our customers to use XAF. Instead of fleshing out thousand of dollars for a complete DXperience suite, they can use out of the box VS controls and a free Module loading / plug-in framework.

During the design phase, choosing between XAF and CAB / Acropolis is an either or decision for us as developers. You, as a component library provider, should not limit my options but rather extend them.

Not everybody is willing to rely on community provided solutions for CAB / Acropolis support. Please don’t ignore CAB and Acropolis just because you have invested in the XAF. If so, people will be forced to choose one of the other library providers.

16 August, 2007
Oliver Sturm (DevExpress)

Hey Espen,

Thanks for a useful comment. I totally take your point about XAF not being the solution to every problem - never said it was, in fact I think I mentioned priorities and functionality, didn't I?

With regard to your risk assessment - I see that point, too. At the same time though, I have to say that there's only so much we can do from our side to provide security for our customers. We deliver the extensibility to allow other components to integrate with our framework. We give you the source code for everything. What else do you have in mind in that regard?

Finally, about support for CAB and Acropolis. Supporting it or not supporting it doesn't have much to do with XAF. As far as I know, we are currently considering actively supporting CAB - no idea what the outcome is going to be. In any case we've had a bunch of requests about that, and so we consider it. Of course there's been a 3rd party solution for a while, so it's not as if our customers are being left outside alone.

In the end, of course we want to support what our customers ask for, but the best solution is usually not to go for everything at once. There are entire operating systems out there, some of them with a considerable user base, that we don't currently support. And while, as you say, it is a good target to want to extend customers' options, we have to make a living ourselves while we do that. As a result, we'll always only support a few of all the available options, and at that point it's once again about priorities and functionality.

16 August, 2007
Visma Retail Software

Everything in SW Dev is about priorities. There just not enough time and money do what we developers want to do :-)

My point was that even though you have developed XAF, there’s a few of us out here that will need to consider other solutions from time to time. Don’t forget us.

I don’t know the details of your licensing scheme for XAF, but it would definitely be desirable to have the possibility to write simple XAF modules without having to pay a full license. This would allow us to provide any third party developers with the XAF shell application and the details on how to extend it without paying a full license. Sometimes customers want to use our application more or less as a shell for several different business functions. If we provide the Shell and an account module, the customer might want to add a CRM module. It’s kind of hard telling our customer that they first have to pay us top $$$$ for the application and if they want to extend it they have to pay you a few $$ too.

At the time I wanted to use your controls with CAB, there was no solution available. I did a little research and wrote my own. Later on I realized more people wanted CAB support so I released the code on GotDotNet. (Now on CodePlex). I don’t think every developer is interested in doing that. It also seems like the Acropolis integration will require a little more effort. I just hope that you’re on top of it in respect to Acropolis.

17 August, 2007
Oliver Sturm (DevExpress)

Ah, Espen - I didn't recognize your name there as they guy who does the DX/CAB stuff :-)

With regard to the licensing scheme and everything... it's really quite simple: if you write a piece of software that requires libraries from the XAF project, then you'll have to pay for a developer license for XAF, for each of the developers working on that project. IOW, if you can't build the project you're working on if XAF is not installed, then obviously you need a license for it.

If you want extensibility mechanisms - there are lots of solutions out there that help you do that (I would recommend looking at VSTA - msdn2.microsoft.com/.../aa700828.aspx), and though I'm not a lawyer, I believe that this is allowed under our EULA to a very good extent. If your customer is the kind that actually gets Visual Studio installed and creates his own software that depends on libraries from the XAF project, then he clearly falls into the first category above, wouldn't you say?

Don't get me wrong - I think I'm actually open to discussions about certain specific use cases of XAF for developers. I do accept that there are certain different roles in the development of large projects, and that those roles have different requirements. But the definition above is still one that I can't get around - if you need XAF to build your project, you must buy a license. To state the obvious: your customers can develop as many modules as they like which don't require XAF to be built, without buying a license. This doesn't seem useless to me - they could be creating forms using standard .NET components (as you said yourself), or implementing business logic, for instance.

17 August, 2007
Kavan Shaban

XAF has enabled us in a few short months to not only model a real world enterprise management system, but to also make the continous refinements and sometimes the drastic overhauls that almost always come up.

My only real question going forward is how can we tier this.  Meaning have the XPO model with all the validation set on the server side.  And data caching is another issue coming up.

Bu overall keep up the good work, you guys definetly are on to something.

18 August, 2007
Gary Gibbons

Great post Mr. Sturm!

You folks won me over months ago;  and other than to wonder a bit, with Acropolis I could anticipate a very tough learning curve with what seems limited results - time I've well spent already on XAF with marvelous results (thank you support staff)!

I looked at some of their early samples, and I would agree, they have much work ahead just to get into XAF's dust.  ;-)

Gary

31 August, 2007
vgrigor

What if I want to use another persistent framework

that was developed internally, and which is insistently recommended within enterprise (- what is happen often)

but the very want to use your XAF.

Can I switch to another persistence mechanics,

implementing some interfaces

as I can do with any Microsoft DataSource provider ?

To have such flexibility would be the very critical with integrating XAF to different solutions

with custom data persistence requirements

thanks you

28 October, 2007

Please login or register to post comments.