|
The Blackmail Interview (Continued)
ED: MTS does give you the ability to move that middle tier processing to hardware separate from the database, distributing the load.
SM: Right. And it provides a level of insulation. You don't get logic embedded in the database, which can lead to further problems downstream. But it's not a free lunch either. The customers we see attempting to leverage this technology want three-tier characteristics. They want off-platform connection of some kind, they want to pull data back and massage it in a more elaborate application structure in the middle tier. In doing so, they take on a very complicated development task. The further they go down the path of attempting to create and manage a transactional unit of work through NT, the harder it is to conceive of how to construct it, make it reliable, and get it to perform.
ED: Is it fair to say that Java gives us a chance to hide the complexity of CORBA, and to avoid the complexity of dealing with multiple languages, and therefore actually gives us a chance to link everything together?
SM: Oh, unquestionably. First of all, these are problems the industry's been trying to solve for a long time. And the problems have been solved at a single platform level on the 370.
ED: Which actually is a whole group of different architectures underneath an OS.
SM: There we used COBOL as a means of masking out subsystem differences in a single platform world. DCE came along as a
means of trying to deal with interoperability in a heterogeneous environment, and CORBA is merely the successor to DCE. In fact, DCOM is the DCE RPC with an enhanced set of services around it. Which means Microsoft has the same problem of abstraction that we do, with VB on one side and C++ on the other. And that's a boundary condition that can't be crossed.
ED: How so?
SM: They're diametrically opposed. They're completely different animals. It boils down to whether you can compile down to a consistent native runtime. DCOM is a C++ runtime service, and the highest performance is achieved through the lowest level manipulation of its APIs. So if I can cross the language boundary by outputting compilable C code from VB, and then I can optimize that code and maybe solve the boundary problem. But OpenDoc attempted to deal with the same boundary condition. And it was interesting computer science, but a very hard problem to solve and not necessarily conducive to great performance.
ED: One of the things our readers have to deal with is that after doing something in the most abstract fashion possiblei.e., via a visual interface and the mysterious workings of a black boxthey'll find they have to jump into the code the black box generates because performance has bottlenecked.
SM: And now the skill set they need may be different from the one they have.
Back to top
|