Archive for July 16th, 2006
Enterprise What?
What really makes something “enterprise” in context of software development?
“Enterprise” is a term that I hear so much it gets under my skin now days. “Enterprise Quality”, “Enterprise Software”, or “Enterprise Capable” are all terms I hear a lot. If you think of J2EE or enterprise services in the .NET realm, enterprise means component re-usability and persistence, transactions and fault tolerance, and scalability. Thing’s that enterprises (as in large companies) have to worry about when handling thousands of simultaneous processes. It means using ideas like the preallocation of data, persisting and storing state of objects, pooling and caching resources across all running sessions, and working with models, frameworks, and design patterns that scale almost effortlessly.
However I think the term sometimes gets confused with another word, “quality”. “Enterprise” does not mean “higher quality”, although many “enterprise” capable applications require a bit of planning so the code is more likely to be a bit higher quality but that’s mostly just a by-product of the extra planning. I know a good number of “enterprise” level applications that are written horribly and pretty much nothing more then just amazing beasts (one I know makes me giggle thinking about it), but would still be considered “enterprise” in every respect because they all still manage to hit that factor of being able to handle thousands of simultaneous processes.
Nearly any language in almost any platform can be “enterprise” capable if it can support those basic concepts or has anough flexablilty to build them yourself. That includes C/C++ (of course), Mono/.NET, Java, Python, Ruby, and even ColdFusion and PHP to some extent if the applications are designed correctly. It’s nice when something in the platform supports those “enterprise” concepts out of the box, but normally, if your language can support threading and OOP type concepts, you can roll your own “enterprise” level scaffolding for your project to get the job done in many cases. Even J2EE is written in Java.
Recently though, I heard some F.U.D. from a very notable person that claimed that Mono wasn’t an “enterprise level platform”. That really bothered me, more because this was coming from an architect, and architect of a very well known and respected piece of software. However after listening to him I doubt he has ever really worked with Mono. He was focusing on the original goal of Mono as said by Miguel when creating the project, that Mono was to help in the rapid development of desktop applications (to help the desktop Linux world keep up, stay maintainable, and grow as fast as windows). The idea behind what he was saying was that many of the “enterprise” level features you see most often are not really necessary in single user environments. He used the fact that our “System.EnterpriseServices” namespace as not being complete as his fuel to help prove his point. He was also making a lot comparisons to VB6 when writing GUI applications (which is not to be confused with VB6 in combination with COM+ which gives VB6 the ability to be some what “enterprise” capable).
It all got under my skin though I thought his comparison of VB6 to Mono was really very funny. The biggest reason being that VB6 doesn’t support threading and only really faked the concepts of OOP development. For that reason you couldn’t roll your own enterprise capable framework written in VB6 itself very effectively because of language and platform limitations. You couldn’t do like how I said before how many J2EE implimentations are written in Java and write COM+ inside VB6. Also, it is true that we don’t support System.EnterpriseServices, but that’s more because EnterpriseServices is simply just a wrapper on COM+ services provided by Windows, so its something that isn’t cross platform capable, and for that matter is even hardly used even in pure .NET in running on Windows only type setups. It’s so easy to roll your own enterprise level concepts in .NET without the need to use EnterpriseServices, so many just don’t use it (that and you don’t get that bad taste in your mouth from using anything COM related).
Also Mono, since just shortly after its conception, has been moving to be so much more then just being a platform built for desktop applications that it started out to be. Mono itself is modeled directly around the standards published by Microsoft that define .NET as well as all the standard class libraries. The design of the class libraries and languages built on top of it are really built to be a best fit for almost any scenario (just in the same way as Java and Python). It’s not intended just for the web like PHP and ColdFusion are, nor is meant for just desktop applications like the way VB6 and VBA are designed. It might be a different story if Miguel chose to start from scratch on designing a new platform altogether.
We might not have an nice prepackaged application server solution to host your components and maybe give nice you a pretty admin interface or xml config file to setup all those nice features like component pooling and caching that you see in many off the shelf application servers in Java or with Component Services with COM+ (unless you consider XSP for web services), which means you have to write your own service daemons in many cases to do that sort of thing. We also might not have (as some would consider) the legacy EnterpriseServices so it means doing anything you want from that namespace yourself, which I know many of us would rather do anyways for the control and simplicity of doing it the .NET way. Mono supports object serialization, remoting, and web services which makes pooling, persistence, and handling state very easy to do on your own. You can still write a true “enterprise level” middle tier and even host them in their own application server, and do all of that with just a little extra planning.
One really great of example of Mono working as enterprise level product is imeem. Over at imeem, they run Linux and Mono on their applications servers and they deal with the massive amount of concurrent connections from all the client applications accessing the service at any given time. They are great example of how Mono is completely capable of being enterprise worthy. Some other great examples can be found in SecondLife’s use of Mono to power its scripting language and also with Novell’s iFolder solution.
About the time we release 2.0, I think we should rename Mono in the Mono 2.0 release to “Mono 2.0 Enterprise Edition” (or M2EE), just for fun. 
