Dna Vs Oo

DNA = MicroSoft's "DistributedInternetArchitecture

Acronym probably chosen due to the famed DNA = DeoxyriboNucleicAcid

was....

http://www.microsoft.com/dna/

If you click above link in 2004, you will be redirected to the current favorite architecture, to be superseded by ServiceOrientedArchitecture when MicrosoftIndigo becomes a finished product.

(Kinda' like DEC's DistributedComputingEnvironment?, only not as much of a "standard?")

A more direct comparison is JavaTwoEnterpriseEdition. Both attempt to specify the architectural model, and how technologies plug in, though Sun's J2EE is attempting to do it through Sun's JCP standards mechanism, and MicroSoft is just saying, "Here it is." -DinoChiesa, 12 April 2000

With DNA, MS is apparently setting out to make it impossible for application programmers to build what used to be referred to as object oriented software:

DataCentric? code - that stuff with all the embedded select statements, transactions, recordsets and so on - can't be efficiently encapsulated by classes. Select statements have no hierarchical filiation, so they can't be re-used. Transactions replace OO exception-handling (See TransactionsVsExceptions), but OO apps should recover from exceptions, not pretend they never happened. Worst, using recordsets to represent data members flattens the whole type hierarchy; recordsets aren't types - so the classes that wrap them can't be more than utilities and facades.
MicrosoftTransactionServer doesn't scale. It allocates 2K per component. A component might need 1 byte of state, but it gets that 2K whether it needs it or not. So we can't afford to have little objects. We have to have great BigBallOfMud ones. And we can't rely on any objects existing between calls except for the ones we create during the life of the method, so observers, brokers, multicasters and so on are impossible to implement. For this great sacrifice we get in return nothing more than a jumped up AbstractFactory pattern. OO goes by the wayside again and the benefit is ... ?
Stateless objects? Nope. DNA objects aren't stateless, they just have to reconstruct state from the database whenever we call one of their methods. Going out to a database, doing a query, retrieving the data, doing some bit of work, and then shoving all the state back out to the database so we can be "stateless" again - all this - is vastly more expensive than keeping some transient objects around between calls. The counterargument is keeping all the state around for all the objects created by an internet app isn't going to scale. Sure, it won't, but we should be making rational decisions about when to write objects to the DB, not blindly writing them all out as often as possible.
ThreeTierArchitecture. We have business objects and the database split into different servers with all the overhead of marshalling, COM, DCOM, MTS, MSMQ, and who knows what next between them. What's the benefit of all this overhead? We economize on database licenses by having a single central database ... but there are free databases and/or we can twist a DBMS salesman's arm to get a site-license that'll suit. An enterprise-wide datamodel might be a point in its favour, but truly the notion that an enterprise can live with just a single data model is old and sad. This leaves just a single point: you can always buy more compute power in the middle tier. This seems more a way to market slow middle languages (ie. VB) and sell wintel boxes than it is any generic architectural solution.

Here's a very interesting datum: http://msdn.microsoft.com/vstudio/downloads/scale/summary.asp . (BrokenLink 2002/06/20) This is what MS had to do to make a DNA app scale. Shame they didn't really stress the thing - 12K users is the magic figure they used a couple of years back - but that's not what's very interesting. Check the code. Most of the business logic is in stored procedures. The middle is just a thin wrapper. So much for the wonders of 3-tier ... or maybe it works better if you steer clear of VB ...

C++ with ATL would improve things in the middle, but then you've got to think of the TotalCostOfOwnership bit. MS chose this particular toolset for a reason - this is what they're marketing to minimize TCO in the enterprise.

What's revealing is that what they're marketing isn't what their best engineers did. MS VB forces your business logic into stored procs to scale resulting in enlarged maintenance costs. It's also expensive to hire C++ programmers in the middle while still employing DBA and ASP specialists on either end. Using Java the whole way through courtesy of Oracle 8i starts to sound much cheaper. Java on the front, in the middle, and inside the DB. Replace MTS with EJB, replace Windows 2001 with Linux, and your TCO just dropped like a stone.

Or maybe not. Regardless of toolset, a good skeptical outlook will still show us the best way to use what we're lumped with. In this case, the MS Scalability code is a lot more useful to my team than the MS hype. YMMV. -- PeterMerel

If there's no scaling issue then this MS code is very curious indeed. I wonder - when you say "it scales" perhaps you're not attempting quite the same scales MS are addressing here? -- PeterMerel

In the July 1999 issue of Component Strategies magazine, in the COMponents column, "The Power of Processors", Tim Ewald Principal Scientist at DevelopMentor, a COM think-tank writes very well on your issue. (http://www.componentmag.com/html/from_pages/column.shtml):

"The mechanics of distribution and transactions in general, and the mechanics of transactional objects in MTS and COM+ in particular, argue for an approach that translates the same analysis model into a more sophisticated design including objects representing Processors."

This My Favorite Middleware can Scale better than Yours isn't productive. I don't know of a head-to-head comparison between the current leaders - ComPlus (DNA), and the various EJB-based servers. Unless someone can cite one, or cite a reasonable set of references for both sides, we can only speculate. -- DinoChiesa, 12 April 2000

See the July 1999 issue of Component Strategies magazine, in the COMponents column, "The Power of Processors". Tim Ewald, Principal Scientist at DevelopMentor, a COM think-tank addresses your issue:

http://www.componentmag.com/html/from_pages/column.shtml

: "The mechanics of distribution and transactions in general, and the mechanics of transactional objects in MTS and COM+ in particular, argue for an approach that translates the same analysis model into a more sophisticated design including objects representing Processors."

On Point 3, MtsObjectsCanBeStateful. This means that you can rely on objects existing between calls, you can implement stuff like observers, brokers, and multicasters, and you can make rational decisions about when to write objects to the DB.

The objects collaborating to support an individual GUI interaction (in the applications I write) aren't necessarily all transactional, don't necessairly participate in the same transaction, and yes, may be around for multiple GUI interactions. Maybe I'm misunderstanding DNA but this seems Ok to me. Eg:
- In a web application I might store some session level information about the user (encapsulated in an object) that is used to elaborate subsequent calls to stateless transactional MTS objects. I'm not necessairly holding a transaction open for the lifetime of the session to do this.
- I might have objects running in the client application which collaborate with MTS objects running on the server. For example an object that manipulates a disconnected recordset produced by an MTS object on the server.
- Maybe I have a facade in which all my objects are fully stateless (ie. call SetComplete? at the end of every method) and my facade uses objects which are stateful from the perspective of the facade (ie. they call SetComplete? when the object is terminated).

DNA documentation does appear to encourage you to write objects which are mostly just thin wrappers around stored procedures and which produce recordsets. All this is in the name of 'scalability'. This obviously isn't very OO. However, MTS doesn't force you to write software this way - it just forces you to be explicit about state and transactions.

Sure, but you know MS tools have a certain grain to them; go against that grain and life gets hard. Doing things that MS doesn't envision for their tools makes it harder still to adopt the next version of their tools. Here, the big carrot being offered to keep you doing things the DNA way is "free threading" - multiple threads per apartment with no marshalling anywhere. The next version of MTS won't let you have "free threading" unless you're good and stateless. If you don't go stateless then when your app can't scale MS will just say you did it the wrong way ...

I'm not sure I understand what your saying here. "Free threading" as you refer to it means that your component lives in the MultiThreadedApartment (which has the attributes that you described). There is nothing in ComPlus that prevents you from having a FreeThreadedComponent. TransactionalComponent-s in ComPlus are usually marked as "single threaded" and live in the SingleThreadedApartment to ensure the atomicity of the transaction. How else would you keep two threads, from two separate transactions, atomic?

-- DrewMarsh

You can have a DB server with 32 processors and it can perform 3 tasks at once, some of which will be doing db stuff and some will be doing data processing stuff (like sorting, filling objects with the data, filling listboxes etc etc). That's on a 2 tier design. With a n-tier, you have 32 processors dedicated to doing db stuff. your middle tier does the DP stuff. Hence you get more scalability costs a bit more perhaps, but that depends on the machines you use in the first place, maybe now you don't need such a big DB server. Note that the DB server could also run the middleware, so you don't need more boxes.. in this case all you're getting is the better manageability of splitting the DP components away from the DB. This is usually the main reason why people go n-tier, the speed you can rewrite parts of the whole, or add to the whole, without affecting the rest. Makes testers very happy if they don't have to test the entire thing for a minor change.

You're not forced to wait for the DB to provide you with state. The most common used way to store state is for the client to pass it in with every call. ie, the client stores it. You can see this all the time with web pages that are in the form 'http://somepage?somestatevar=somestate' alternatively, you can store the state in the middle tier using something like MTS's Shared Property Manager (referred to as SPAM for some reason) or write your own Resource Dispenser (which is effectively an object that is persistent and shares out its data).

If you were writing transaction processing software then you want fullscale reliability and guarantee that is did only what it said it did, in which case everything will go slowly anyway. (relatively speaking). all DB writes will be to the temporary tables so that it can throw it all away if it aborts, or copied in once its committed. You'll have logging and auditing and probably security and encryption in there as well. so... big deal if it spends an extra 5% going across the wire to a DB server - your threads will be slept and others will run... don't forget that scalability = number of users that can use it at any given time, and not performance. With a stateful design you're looking at halving (at least!) the number of users that can use it, even though you may gain in performance.

"For this great sacrifice we get in return nothing more than a jumped up AbstractFactory pattern. OO goes by the wayside again and the benefit is ... ?"

The key to COM is interface based programming, and MTS introduces process based programming and additional of services at a "low cost". OO is still around, and there is no reasons why complex OO objects cant live outside of MTS and still use the good old OO approaches.

So ... you really are saying I should use MTS as a database adaptor. Wow. The future of components is not itself OO?

"Stateless objects? Nope. DNA objects aren't stateless, they just have to reconstruct state from the database whenever we call one of their methods."

For good reasons: To ensure the semantics of a transaction. Much confused point.

I guess where I'm going with this is thinking about OODBMSes and ORDBMSes, both of which allow me to stay fully OO and still provide me with transaction semantics. Can't we have both?

What about EnterpriseJavaBeans? Look at entity beans or stateful session beans: you CAN be both OO and n-tier.

-- DanielSadolevsky?

Regarding Point 4, Are you saying that multi-tiered architectures are bad? Then you've got more than DNA to rail against. How about CICS, Encina, Tuxedo, EJB, and um... The Internet? All of these systems use multiple tiers to address scalability.

Some of the opinions offered here (DNA is Not OO; ergo DNA is Bad) are a bit beside the point.

Some of us believe that OO is not the answer to every question. OO is a tool. Let's not pursue architectural purity, but instead pursue results. The basic question is, does it work? If OO can make it work better, then Great! let's use it. If we have to bend the OO rules to make it work, then, ok, kick us out of The OO Knights of the Templar, but recognize that it works.

Why are ORDBMS or OODBMS still not beating the pants off plain old RDBMS in the market place? Certainly there is a ton of vendor investment that will resist such a change: Oracle is not likely to give up its stronghold easily. But beyond that, O*DBMS have simply not reached critical mass. People are using what works, what solves their problems today. And it looks like Oracle and VB (shudder!) still work.

-- DinoChiesa, 12 April 2000

Microsoft has a page of advice on Top Windows DNA Performance Mistakes and how to prevent them at http://msdn.microsoft.com/library/techart/windnamistakes.htm.

It discusses many of the issues mentioned here. -- JonathanBlackmore

The criticism that using stored procedures goes against n-tier is rubbish. One, n-tier means distributing logic where it makes sense (in this case has the best performance). Two, the performance gain comes from the fact that the transaction between client and app server is much longer than that between app server and database for the typical case of a HTTP request.

Re: Select statements have no hierarchical filiation, so they can't be reused.

At the risk of starting another Relational-vs-OO HolyWar, what is an example of how hierarchical taxonomies increase reuse? I find hierarchies a rather artificial fit to the real world (see LimitsOfHierarchies). Even many OO fans don't put much stock into hierarchies, I would note, preferring delegation, etc.

CategoryComparisons CategoryMicrosoft