.NET Framework 2004 to include JDO-like Objectspaces

Discussions

News: .NET Framework 2004 to include JDO-like Objectspaces

  1. Microsoft has published their 2003-2005 developer tools roadmap which mentions that .NET 2004 will include Objectspaces, an object oriented transparent persistence framework, much like our own JDO. Might this development finally convince the J2EE vendors (especially Sun) that transparent persistence really matters?

    From Microsoft Developer Tools Roadmap 2003-2005:
    Whidbey will also eliminate the gap between data manipulation and programmatic object manipulation with ObjectSpaces. Complementary to existing data models, ObjectSpaces enable the manipulation of data transparently as objects.

    Gopalan Suresh Raj has an article about ObjectSpaces.

    Threaded Messages (34)

  2. The SUN JCP told us we need EJB, BluePrints, JSF and Portlet (JetSpeed) and that this is best practices and smart thing to do. They are the Expert Group after all and we are just silly application developers, we do not mind doing it the hard way.

    Becuase of this, I will not downlod C# for FREE to even try it:
    http://borland.com/products/downloads/download_csharpbuilder.html

    Look at the _bad_ way here, they (C# developers) just go after data, without EJBs, ha, ha:

    Creating a master-detail WinForm with C#
     http://bdn.borland.com/article/0,1410,30192,00.html
    ASP.NET datagrid design with C#
     http://bdn.borland.com/article/0,1410,30190,00.html

    They (C# developers) should get their own expert group to tell them how silly it is to go after data and that they should get EJB's in C#.

    .V

    (of course I do not use .NET, I do Struts and iBatis as tabular data with SQL and stored procedures, not JSF and EJB. I think clients using JSF w/ EJB will be on .NET very fast)
  3. Vic,

    I don't think that it is useful to discuss the whole EJB vs. JDO vs. ER/mapper tools vs. direct DB access once again here. Many articles and even some books been written on this topic, and if people *still* mis-use EJB and related technologies, then it's really their problem...don't blame it on Sun, the JCP, expert groups, or Java as a whole.

    Anyway, thanks for your links to .NET demos. Neat stuff, Borland rocks as always. I think this is certainly the right tool for many developers (especially for VB dev's) and for many situations. However, i can code both app demos at the same speed (the second one even faster), but in my working environment everything is 100% transparent, 100% flexible and 100% open source (except java itself).

    cheers
    joe
  4. Joe,
    You are right, I tend to be a broken record sometimes.
    However.... as I do consulting/mentoring from sevearl very nice companies, they say things like:
    "Tomcat is not J2EE!"

    !?
    My point is that EJB != J2EE.
    I think J2EE is great and competetive w/ .NET.

    Or
    " We have a policy of getting data from EJB layer"

    !?
    (I will not say what I think, so not yet another EJB flame. If soware enginers were designing a car, they should spend a lot of time on wind resistance and engine fuel eficenecy, lowering cost of development and operation.)

    But EJB does make .NET relatively better than J2EE for those that use it. So I just preach J2EE w/o EJB.

    .V
  5. Entity beans or Session beans?[ Go to top ]

    Are you against the use of ejb's as a persistence framework (i.e. entity beans) or are you also against the use of ejb's as a transaction and security framework (i.e. stateless/stateful session beans)?

    I guess a perfectly valid approach would be to use session beans + jdo, or?
  6. Are you against the use of ejb's as a persistence framework (i.e. entity beans) or are you also against the use of ejb's as a transaction and security framework (i.e. stateless/stateful session beans)?

    >
    > I guess a perfectly valid approach would be to use session beans + jdo, or?

    Good point, separating the distinct benefits that EJB tries to offer: transaction demarcation, access control, session state management, entity persistence.

    Let's not talk about Entity Beans vs POJO persistence here but focus on Session Beans. Session Beans have their value for remotely exposed components. But when just using them locally within a web app, the per-client state management of SFSBs doesn't add value. The pooling of SLSBs is pretty meaningless too, if you don't keep non-thread-safe resources as instance variables. So it's mainly about SLSBs for transactions and security here, not about state management. I assume that the majority of web apps doesn't use method-level access control, therefore that value of local SLSBs is of low importance too.

    This leaves convenient transaction demarcation as the single most important benefit of local Session Beans, especially declaratively via CMT. If this is the only EJB feature that you are actually using, then there are viable, more lightweight alternatives like the Spring Framework's transaction support. The latter provides transactions to POJO beans via pluggable transaction strategies. JTA, a single JDBC DataSource, Hibernate, and JDO are supported out-of-the-box. Transactions can be demarcated programmatically, or declaratively via a respective AOP interceptor (Spring has integrated AOP support).

    The most important benefit of Spring's transaction support is that it isn't bound to a container at all. Configured to any other strategy than JTA, it will work in a standalone or test environment too. Spring's resource management allows for transparent switching between a JNDI DataSource and a local one, same for Hibernate and JDO. Especially for the typical case of single-database transactions, this is a very lightweight and powerful alternative to JTA, and to Session Beans as transaction drivers.

    JTA does not just involve container dependencies on JTA itself and on JNDI DataSources. For JTA-driven JDO transactions, you have to use the JCA connector of the respective JDO implementation, which is typically only included in the Enterprise Edition (e.g. Kodo, Lido). Spring-driven transactions can work with a locally defined JDO PersistenceManager nicely, just like with a local Hibernate SessionFactory or JDBC DataSource - if accessing a single database, of course. Therefore you just have to fall back to the JTA transaction strategy when you are actually facing distributed transaction requirements.

    A final note: A JCA connector needs container-specific deployment steps, and obviously JCA support in the first place. This is far more hassle than deploying a simple web app with local resource definitions and Spring-driven transactions. And you often need not only the Enterprise Edition of the JDO tool but also of the container, as e.g. WebLogic Express does not provide JCA. On the other hand, an app with local resources and transactions spanning one single database will work in any J2EE web container (without JTA, JCA, or EJB) - like Tomcat, Resin, or even plain Jetty.

    Juergen
    Spring Framework developer
  7. Frankly I find discussions like "Spring better than EJB" quite strange. In the end what it comes down to is that you need a container. Spring is - at the moment - a lightweight container. Well fine. I like it - although it could be a bit better documented :-) - but in the end, what people want is the container do *everything* for them. They don't admit it, but in fact they do.

    Distributed transactions? Sure need them. Remote and distributed objects? Can't do with them. Should they have transparent persistence? Of course! Should it include simple facilities to send email? Definitely..... Look at something that happens if a container is underspecified: Some vendors or de facto standards emerge that are then kept and layered under another standard that in turn needs to be layered under some api developers can really use - logging in the J2EE world is a fine example for such a process. Quite a waste of resource IMHO.

    Given this simple fact I have the feeling that each of these "simple" and "light weight" container approaches will definitely grow to be huge - and sometimes ugly - monsters. Just look at all the stuff that pops up around Web Services making them the next big Corba Clone.

    And in the end those people have a point. Consider the software stack you need to create this functionality by buying or pulling stuff from open source. You will usually end up with around 20 different program packages that have slight but important dependencies on each other. This is especially bad using Java where it is very hard to shield packages against version changes/upgrades in another package (something that is fairly trivial in .NET).

    Oh, and while the container grows and grows the need will arise to put all these callbacks into declarative files. Soon using Interceptor definitions will not suffice. More semantics will be needed and we end with config.xml files for app servers, application.xml for enterprise applications and what not.....
  8. <karl>
    In the end, what people want is the container do *everything* for them. They don't admit it, but in fact they do.
    </karl>
    I disagree. I think the history of EJB suggests the reverse is the case: people don't necessarily need one monumental solution to every conceivable problem. Developers were given a hugely ambitious spec with EJB, but many have gradually realised that much of the complexity in that spec, such as SFSBs and entity beans, were not that useful to help solve typical problems. So they're paring back to SLSBs, and it makes perfect sense to analyse the problems they want to solve with SLSBs, as Juergen did, and see whether there are in fact simpler solutions altogether.

    And there is a strong argument for leaving out things that are well solved elsewhere. Take transparent persistence. JDO and Hibernate solve this problem well, as did TopLink even before EJB appeared. Rolling everything into one God spec can tend to dumb things down compared to a best of breed approach. Compare TopLink in 1999 with 1.1 entity beans.

    Btw, Spring does not aim to be a complete replacement for EJB. It doesn't need to get into massive complexity reinventing things such as distributed transactions that EJB does well, because it's aimed at the 90% of problems that don't involve this kind of complexity (or shouldn't). EJB will continue to be a good solution for the rest, meaning that Spring won't have to become a "monster." The motivation of Spring (and Nanning and the like) isn't that EJB is bad, but that the complexity of EJB isn't appropriate in many cases, and that simpler solutions will be better and cheaper. YAGNI/The Simplest Thing that can Possibly Work.

    Regards,
    Rod
  9. Frankly I find discussions like "Spring better than EJB" quite strange. In the end what it comes down to is that you need a container.


    > Distributed transactions? Sure need them. Remote and distributed objects? Can't do with them. Should they have transparent persistence? Of course!

    It's not about Spring "being better" than EJB. Some of Spring's facilities are a way to adapt to various environments with as little code intrusion as possible. The goal is to get a lot of the convenience benefits of EJB like transaction handling, plus persistence via Hibernate or JDO, locally within an application - without the notion of deploying separate components to a server container. Your business code can be used outside of server environments too.

    Spring does not try to replace EJBs in general. It just allows to restrict EJB usage to the scenarios where the latter actually makes sense, like offering remotely accessible transactional components via remote SLSBs and SFSBs. Like Hibernate is a viable alternative to O/R mapping via Entity Beans - Spring's middle tier services can be considered a viable alternative to local SLSBs, offering a bean registry and transaction management among other things.

    So you can choose between local resources and container services, requiring the latter only with good reason, e.g. JTA for distributed transactions. As many typical applications still access a single database, this adds a lot of value by avoiding unnecessary JTA dependencies, allowing the use of simpler containers like Tomcat. The same applies to JNDI: Use a JNDI DataSource if you want the container to manage them, choose a locally defined DataSource else.
     
    > Given this simple fact I have the feeling that each of these "simple" and "light weight" container approaches will definitely grow to be huge - and sometimes ugly - monsters. Just look at all the stuff that pops up around Web Services making them the next big Corba Clone.

    Spring will definitely *not* grow to be huge like a EJB container. It has completely different design goals, staying lightweight in the sense that many parts can either be used as library or wired up via an application context. It can leverage container services where appropriate but offers alternatives for common scenarios where the power of a container's offerings isn't necessary for the tasks at hand.

    Classloader separation, thread management, heavyweight remoting, session management, of course HTTP serving - all those things will stay responsibilities of the container. Spring does not aim to compete in that respect. It makes applications *require fewer* container services though. This way, business code can easily be reused in desktop apps or test environments, while still being able to leverage container power where necessary.

    Web Services are a good counter-example, I fully agree. That's why Spring integrates alternative web-based RPC mechanisms like Caucho's extremely lightweight Hessian and Burlap protocols. Generally, Spring aims to integrate appropriate solutions where available. Why should we reinvent an O/R persistence tool when there's Hibernate? :-)

    > Oh, and while the container grows and grows the need will arise to put all these callbacks into declarative files. Soon using Interceptor definitions will not suffice. More semantics will be needed and we end with config.xml files for app servers, application.xml for enterprise applications and what not.....

    Currently, Spring's bean definition XML file is extremely simple. If you just wire up application beans, you won't find anything else in there. For transaction management on resources, you will need definitions for those resources and a respective transaviton manager. If you leverage the AOP support for declarative transactions, you will need AOP proxy and interceptor definitions. You just need to worry about the stuff that you're actually using.

    Juergen
  10. No[ Go to top ]

    but in the end, what people want is the container do *everything* for them. They don't admit it, but in fact they do. <

    I think, actually, this is slightly wrong.

    What they *really* want is a container that can integrate _other_ services effectively and elegantly. Unfortunately, this has not been possible with J2EE containers. So, necessarily, the J2EE spec has to grow to accommodate all the things people need.

    Now, I argue that this is a problem with INTRUSIVE containers like the EJB container. A non-intrusize container like Spring, or other containers supporting AOP and IoC, allows Plain Java Objects to be assembled together, and then have application infrastructure interpose itself _transparently_.

    Then, this application infrastructure can implement things like transaction managenement, exception handling, distribution, persistence, etc in a very customized way, adapted to the needs of the application - not to the lowest common denominator that the EJB spec targets.

    The container becomes a way of cleanly assembling things together (I don't mean "assemble" in the sense of the J2EE spec, either).

    But we have a long way to go before ideas like AOP and IoC will really become accepted, unfortunately.
  11. No?[ Go to top ]

    <Quote>
    What they *really* want is a container that can integrate _other_ services effectively and elegantly. Unfortunately, this has not been possible with J2EE containers. So, necessarily, the J2EE spec has to grow to accommodate all the things people need.
    </Quote>

    This is an interesting train of thought. Because it puts the application developer (well the project manager really) somewhere in between to choose between "standards" and "best of breed". IMHO, EJBs huge number of services also grew out of previous experience with CORBAs "optional" standards (Service Providers). Also consider the fact that versioning and library interdependence is very poorly addressed in java. Right now this starts to create huge problems of interdependent and intersecting library stacks. Therefore people desparately look for standards. Open source somewhat helps, because we are not dependent on a vendor *not* to go bust, but it helps only so far.

    In reality, the only way to upgrade existing application without major intrusions into their source is to move along standards. Therefore XML handling, Web Services and Logging needed to be integrated into the Java core libraries, because they were about to become unmanageable. I strongly doubt that this can be addressed with a different programming model - like AOP - because at its core the problem is IMHO with the libraries not with the source code (although of course AOP modularization can help tackling it on the source level).

    In a way, I still think what really would serve us better is to adhere to a development model that provides meaningful functionality in coarse grained, easy to handle components that shield from everything they are dependant on. Sounds somewhat like VBX, doesn't it. Maybe there is a reason, VBX has been the only truly commercially successful component architecture to date. But then again, I moght be wrong.
  12. I tend to agree with Rod, Juergen, etc, that monolithic container won’t work. It never worked before (PL/1 anyone – it comes to my mind as an example from ages ago) and it won’t work now. J2EE has never been design to be a monolithic but rather to address some common use cases in the enterprise. There are plenty of other enterprise use cases that are explicitly or implicitly left out of J2EE spec. And we are starting to see new types of middleware that are beginning to address these issues.

    As for the thread topic, I think it’s a good news for both Java and .NET community (if it turns into actual product). .NET developers would benefit from this technology (those who actually believe in O/R mapping) because Microsoft was literally non-existent in this technology and left it to the 3rd parties, while Java camp should enjoy healthy doze of competition on the technology side.

    Just my 2 cents,
    Nikita Ivanov.
    Fitech Labs.
  13. hi Vic,

    okay now i know what you meant originially - you were referring to the *attitude* of certain people who think that only expensive and *huge* systems are good systems - - -yes, i totally agree with you on this issue :-)

    cheers
    joe
  14. of course[ Go to top ]

    Of course Microsoft is going to ship tranparent object persistence. It's what developers want. It's the single most useful capability I can think of for any enterprise project. J2EE vendors absolutely know this, but they can't jump immediately into JDO because they need to recover their investment in entity bean technology. But, there's really no need for JDO to be included in part of the J2EE spec since the present JDO spec already covers getting a PersistenceManager from a container. It would, however, help JDO get into the lime light if the big players got behind it.
  15. of course[ Go to top ]

    Well, a day has passed, and TheServerSide hasn't referenced the entirely psychotic ravings of Sun's head, Scott McNealy, in which he compares people using Linux to people who download illegal MP3s.

    Which isn't surprising, because neither JavaLobby nor TheServerSide mentioned the news that Sun was in some way helping SCO in their attempt to sue IBM for not-so-open-source bits of Linux.

    Is Sun helping pay for TheServerSide, or is it still just Microsoft? :)

    Sun is really trying to put the squeeze on Linux, enough to the point where they may withdraw future implementations of the JVM on linux breeds they deem unlicensed. This could really affect Java users almost everywhere. To not report on what Sun's CEO is thinking is completely irresponsible. Sun is getting hammered by Linux, and they're putting the squeeze on Java.

    People need to know about this so Sun can't do this stuff under the radar. Java lovers need to know about it and express their opinion (whether pro or con, I don't care). You've posted Ellison's rantings on here before, so why not McNealy's?

    Steve
  16. of course[ Go to top ]

    Well, a day has passed, and TheServerSide hasn't referenced the entirely psychotic ravings of Sun's head, Scott McNealy, in which he compares people using Linux to people who download illegal MP3s.


    I saw those articles, were about to post them, and then decided that just because it's from Sun doesn't mean it belongs on a J2EE portal. This is a serious technical site. If you want controversy, read JDJ.

    >Which isn't surprising, because neither JavaLobby nor TheServerSide mentioned the news that Sun was in some way helping SCO in their attempt to sue IBM for not-so-open-source bits of Linux.

    You obviously know a lot more than I do about this, I don't know anything about Sun's involvement in the SCO dispute and it wasn't a factor in deciding that McNealy's 'raving' wasn't TSS newsworthy.

    >Is Sun helping pay for TheServerSide, or is it still just Microsoft? :)

    I have no idea what you're talking about.

    Floyd
  17. of course[ Go to top ]

    Scott's psycotic ramblings are, of course, contrary to what his company is actually doing with respect to Linux:

    (From the SuSE website)

    SuSE Linux to Become a Java (tm) Source Licensee and Distribute Sun's Java, Sun to Distribute SuSE Linux Enterprise Server

    I wouldn't pay too much attention to McNealy - he is trying to use the uncertainty surrounding Linux as generated by SCO to drum up business for Solaris - but he knows (or some of the other folks in his company know) that Linux is here to stay. He may not like it, but that's his perogative.

    Cheers
    Ray
  18. JDO in production[ Go to top ]

    looks like JDO is being used:
    http://www.exadel.com/products_jdoproducts.htm
    It is also mentioned at IBM website.

    pavel
  19. of course[ Go to top ]

    But, there's really no need for JDO to be included in part of the J2EE spec since the present JDO spec already covers getting a PersistenceManager from a container. It would, however, help JDO get into the lime light if the big players got behind it.


    I agree that it doesn't need to be part of the J2EE spec. But if the vendors did get behind it, the technology would be developed and adopted much faster than it is today. I mean heck, whenever a J2EE spec goes final the expert group for the next version usually forms within a month and continues development of the next version.

    JDO 1.0 came out ages ago and the JDO 2.0 expert group isn't even formed yet.

    Floyd
  20. JDO and J2EE[ Go to top ]

    JDO 1.0 came out ages ago and the JDO 2.0 expert group isn't even formed yet.



    JDO has been adopted last year, a release maintenance (JDO 1.0.1) has been adopted it should be publicly available soon.

    And there is a JDO expert group meeting next week to push things towards a new version of the JDO specification. This release will address most of the requirements we get from the market in one year.

    That said, I can see a lot of clues showing JDO is more and more adopted as a standard. The 2 leading OSS App Servers (JBoss and JOnAS) decided to implement it, and SunONE Server 7 CMP mode is based on JDO, this can certainly boost the relationships between J2EE and JDO.
    We now have more than 10 commercial implementations and more than 6 OSS projects working on it. More, there are now a lot of third-party products (plugins, GUI tools, generators...) available around JDO as a standard technology. All JDO vendors now publish a list of visible references some of them already being large deals, where all their developers will now use JDO as the unique persistence layer.

    Best Regards, Eric.
  21. Transparent object access???[ Go to top ]

    <quote>
    Of course Microsoft is going to ship tranparent object persistence. It's what developers want. It's the single most useful capability I can think of for any enterprise project.
    </quote>

    I know that it has been discussed before but if I read stuff like this I just can't resist. JDO as compared to Entity Beans is *not* about transparent object access. That's just plain wrong and shows limited insight into real usage scenarios of the technology. JDO is about enabling a presistence layer outside of the EJB (potentially light weight). Since most existing systems will get their database design not from JDO generators (for the foreseeble future, but the MDA hype might of course change that ;-)) "transparent access" requires object relational mapping - there is just no way around it - as long as you interact with a real world relational database.

    And while entity beans used to suck, given modern EJB containers and development environments they can be worthwhile to pursue in some usage scenarios.
  22. I think JDO needs to be included in the spec for it to mature. We all agree that we need a transparent objct persistence framework. If JDO were in the spec it would give companies a choice for persistence and save some money... i.e they would only still have to buy just an application server (and have entities CMP and JDO as persistence frameworks... at least the choice will exist within one package) rather than an application server + the cost of some other JDO implemenation. As far as I know... there are still no "ready" opensource JDO implementations and the JDO RI from SUN is hardly something should be considered for projects.


    SUN/the JCP members/Big J2EE appservers/Java IDE vendors/whatever don't need to wait for the competition to get ahead before they act. Look at JSF, JCache (which may even be dead), JDO (SUN doesn't even ship a commercial implementation!?!), any decent Java IDE (it was a WHILE before we got any decent IDE... although we have quite a few now which is a good thing). I think Java/J2EE vendors need to be more proactive.

    Just my 2p...

    Cheers

    Smythe...
  23. ObjectSpaces versus JDO[ Go to top ]

    It is clear Microsoft now communicates on ObjectSpaces, even if it is still hard to find accurate technical information about the future product.
    They also clearly looked at JDO before starting ObjectSpaces (a kind of recognition from what JDO brings).

    Besides the Gopalan's pages, here is a site (in french) where you can find information and useful resources about .NET and persistence:
    http://www.dotnetguru.org then click on "persistance". There is an interesting article about "JDO versus ObjectSpaces" (also in french).

    That said, there is a big difference between JDO and ObjectSpaces. JDO is a standard defined under the JCP and implemented by several vendors and OSS initiatives. ObjectSpaces is a product, designed and edited by only one company. It means there is no open specification process, no competition between implementations.
    For instance, I suppose ObjetSpaces will support all RDBMS equally but maybe it will be more complete and efficient on SQLServer ?

    Please note DotNetGuru mentionned few O/R mapping products already available for .NET but I'm curious to see what will happen to these products onece ObjectSpaces will be available ?

    Best Regards,
  24. ObjectSpaces versus JDO[ Go to top ]

    Someone told something about the site dotnetguru giving an overview of objectspace vs jdo.
    There is also an article on yukon (the next sql-server) where they said objectspace might be an sql-server only product. Hard to know exactly how "opened" will be objectspace.
  25. Floyd
    <
    :) How strange... all this while I got the impression that it was *Microsoft* that was interested in seeing whether this business of "transparent persistence really matter[ed]". Why do I still sense that there is some reluctance from Microsoft regarding ObjectSpaces? Hmm...

    If it takes Microsoft to convince the Java community that JDO has its merits, then I swear this industry has to be the most bigotted one there ever was!

    <g>
  26. JSF is first off something that can be used with any persitent framework. As a matter of fact, the model object can be any Java Object that can be linked to a tag that represents a control and bring bag tabular data. So JSF brings some very interesting possibilites to compete with ASP.NET and ADO.net combinations.

    EJB is not just a Object relational technology. Stop dragging the EJB technology in the mud. I think every application can benefit from a Stateless Session Bean Layer that represents an entry to your business domain. Microsoft is no different with COM +. Message driven beans are a great technology as well. If you want to attack Persistence, say Entity Beans and CMP. Specifically attack the piece. EJB in itself is not what you are attacking. Session Beans are no different than coding a factory and distributed object pattern yourself. Except you get transactions and other services for free.

    J2EE is a bunch of specifications, but the core is still: Servlet, JSP, and EJB. Session Beans are a good thing and should be used in most applications. I agree that Entity Beans are debatable (not all together bad, just debatable to you prefence of persistence). Stop saying J2EE without EJB is the best. Say J2EE without CMP if that is what you mean. But I believe EJB is a great technology (Stateless Session Beans and Message Driven Beans). I mean, you even have a Local Interfaces if the Remote overhead still is a concern.

    I get really upset at people who group EJB into on lump of bad technology. Rather than people saying J2EE != EJB, they should say EJB != CMP.
  27. J2WE != J2EE[ Go to top ]

    Yeah, right!

    To me the Java 2 ENTERPRISE edition spec IS really all about EJB's. Session EJB's and MDB's rock! EJB's ARE the core of J2EE. But entity beans, hmm... Well, I could say they are something of a failure. But still have their use, sometimes.

    The stack of JSP's/Struts/Servlets/POJO's/iBatis or anything like that could be called the Java 2 WEB edition. IMHO.

    My proverbial 2c (EuroCents :)

    //ras
  28. I'd be curious to know if anyone has tried using a lightweight container framework within SLSB's to make them (effectively) stateholding? The old problem with SFSB's has always been their overhead, and I wonder if a transparent framework could be an easy way to implement session management at lower cost (perhaps using a session ID as a key in a table)?
  29. Wrong, wrong[ Go to top ]

    It is amazing how much stuff (mostly so-called object persistence layers) in J2EE is based on total misunderstanding and ignorance of relational databases (another thing is JAVA ignorance of other styles of programming then “object-oriented”). And now comes the Microsoft! I don’t believe in these rumors about Object Spaces as this contradicts all previous Microsoft recommendations to implement data access layer using stored procedures. If you are delegating processing and manipulation of data already stored in one of relational databases to JDO, EJB or whatever “object data persistence” layer, then you are going back 30 years before the existence of relational databases. Impedance mismatch between SQL and “object-oriented” languages is mentioned so many times as a lack of “object-orientedness” of SQL but in fact real mismatch is the difference between one-record-at-a-time and set processing. Next version of SQL Server will integrate .NET Framework into SQL Server in the essence that .NET Framework types are brought into SQL Server and mixed with SQL Server’s built-in types but this is far from the Chris Date’s pure relational language called Tutorial D. Reasons for the current miserable treatment of relational databases by so called “object persistence layer” are purely historical and have roots in how programming languages and databases have evolved separately. Programming languages have evolved over time with the addition of possibility to define his/her own types in addition to built-in base types but without any data model (storing and processing). On the other hand relational databases model as only scientifically based data model, has evolved theoretically and practically with the support of built-in basic types only due to SQL language limitations. I believe I saw announcement on this site about someone from the J2EE community giving presentation about greatest J2EE mistakes and ignorance of relational databases was mentioned as one of them. There are few great books discussing why object-relational mappings are wrong, why “object” databases will never work and why is a bad thing to keep your data in “objects”. But I have doubt that many “pure” application architects will rather spend time with newest tech fads. I don’t want to make this post too long but anyone really interested in what relational databases are and what they ‘re not and what they could become in the future I encourage anyone to pick up Chris Date’s book, which just has been released in 8th edition.
  30. Re: Wrong, wrong[ Go to top ]

    Right, almost. What's your recommendation (in addition to reading some books and switching to FirstSQL) for the thousands of developers with "unpure" SQL databases? Stop working, live under a bridge and start writing books about the holy grail?

    Date, Darwen, Pascal, Badour, are right on most of the things they say, but attacking the users is not the solution. Go attack the multi-billion dollar corporations. You won't start a rebellion if you insult others for being stupid if they are only trying to make a living.

    It also doesn't make a difference to be "right" or "wrong" if the marketing of the "right" idea sucks. Most I've seen/read from the TTM crowd is preaching, but not for a friendly religion ("Unworthy! Stupid! You'll all go to hell! Confess!"). You won't get any converts that way.

    Can you show me a single book that not only covers theoretical constructs like "Tutorial D", but explains in detail how to use them in daily work with that Oracle 8i? After reading TTM you feel much better, until you have to go to work the next day...

    </rant>
  31. Re: Wrong, wrong[ Go to top ]

    I can’t comment why current relational databases are not truly relational or whether such and such person has been doing right or wrong marketing to big corporation to gets those ideas implemented or why SQL has been chosen as a database language lingua franca in the past instead of some truly relational language. My comments were not in the light of not-yet implemented future “truly” relational databases.

    The fact is that all “object persistence” technologies are ignoring currently available commercial relational or object/relational databases for what they exists for – to store and manipulate data. And this ignorance is not caused by the lack of “commercial “Tutorial D” implementation as you are trying to suggest. There is no need for the persistence layer if data is manipulated where is residing. My comments were against more and more practices ignoring basic facilities offered by different database vendors for the long time. The fact that data in relational databases can be stored and manipulated as a set using simple (not perfect) SQL language as opposed to data stored in objects. Not even to start talking about concurrency and recovery, which is refined to perfection for the past two decades.

    I strong believe that all “object persistence” layers or any data access layer should exists only to abstract RDBMS own data access layer implemented using vendors particular SQL dialect with extension. Many who think differently use procedural languages like Java and consequently to avoid poor performances they must throw lots of hardware in middle tier or simple blame DBA for the “RDBMS poor performance”.

    There is a well know and powerful language to manipulate data stored in Oracle database. There is no need for the commercial Tutorial implementation with the existing Oracle databases. Tutorial D language has been implemented by the company called Alphora but in the form of the layer on top of the existing relational database.
  32. Re: Wrong, wrong[ Go to top ]

    And this ignorance is not caused by the lack of “commercial “Tutorial D” implementation as you are trying to suggest. <

    Read again, I don't suggest it. For almost any of us, it doesn't exist.

    >>> The fact is that all “object persistence” technologies are ignoring currently available commercial relational or object/relational databases for what they exists for – to store and manipulate data <
    That would be FirstSQL, Matisse and all the other proprietary O-R extensions, right? Why should these be covered in an Object Persistence book? If they are truly relational, why doesn't Date write a practical book about them? Maybe I missed some of his work, though. Been busy working on real applications where the customer decides what database he uses enterprise-wide. It is not FirstSQL.

    >>> I strong believe that all “object persistence” layers or any data access layer should exists ... <
    Believe and "should" is not helpful if you want to get your bills paid.

    >>> There is a well know and powerful language to manipulate data stored in Oracle database. There is no need for the commercial Tutorial implementation with the existing Oracle database <
    You are talking about the mighty PL/SQL with its powerful String manipulation capabilities (32KB!), i guess. Its power must be the reason why both medium sized projects with SP I worked on used C and Java for the procedures (not my decision, I only touch PL/SQL with a long pole wearing gloves). Oh, and its nice to throw away all your work on the next project, because it uses a different PL/SQL dialect or other proprietary extensions.
  33. If you are delegating processing and manipulation of data already stored in one of relational databases to JDO, EJB or whatever &#8220;object data persistence&#8221; layer, then you are going back 30 years before the existence of relational databases. Impedance mismatch between SQL and &#8220;object-oriented&#8221; languages is mentioned so many times as a lack of &#8220;object-orientedness&#8221; of SQL but in fact real mismatch is the difference between one-record-at-a-time and set processing. <


    FYI, one of the goals of the Hibernate project is to enable "set processing" of objects, by taking advantage of the features of the underlying RDB but allowing you to use the language of properties/classes/polymorphism, etc. I think you have a very narrow view of what is possible in ORM.

    (Obviously, the kind of things I am thinking of are _not_ possible in most ORM solutions, including the ones you mentioned. And, of course, Hibernate as yet falls far short of a full implementation of this ideal.)

    >> It is amazing how much stuff (mostly so-called object persistence layers) in J2EE is based on total misunderstanding and ignorance of relational databases <
    Really.

    Gee, maybe I should go out and learn something about this topic?

    "relational databases" .... hmmmm .... is that like Oracle or something?

    >> another thing is JAVA ignorance of other styles of programming then &#8220;object-oriented&#8221; <
    Clearly, if you don't develop using object-oriented style, then you shouldn't use ORM. No-brainer. And since I've never heard anyone claim otherwise, this is really a red herring.



    P.S. Somehow I don't think that any "real" development teams will be using Tutorial D in the next two years or so.
  34. early access code at the PDC[ Go to top ]

    The ObjectSpaces technology is currently planned to ship in the next version
    of the .NET framework, code-named "Whidbey". There will be sessions at the
    PDC covering ObjectSpaces. Also, we are planning to release early bits of Whidbey at the PDC, and those bits would include ObjectSpaces.

    -Dino
    <Microsoft/>
  35. The ObjectSpaces technology is currently planned to ship in the next version

    > of the .NET framework, code-named "Whidbey". There will be sessions at the
    > PDC covering ObjectSpaces. Also, we are planning to release early bits of Whidbey at the PDC, and those bits would include ObjectSpaces.
    >
    > -Dino
    > <Microsoft/>

    Hi all,

    <grumble>
    First of all: I find it increasingly annoying to find out that most of the discussions going around the original subject of a thread on TSS is just plain, useless noise. I mean, what do people care about your rantings about J2EE vs .NET, or EJB vs JDO, we're supposed to discuss ObjectSpaces in here, aren't we for God's sake ???!!!
    </grumble>

    Thanks Dino for the info. I'm still a bit unclear as to what Microsoft's roadmap for ObjectSpaces is:

    I initially heard ObjectSpaces was to be released as part of the next SQL Server version codenamed "Yukon", and that this release was planned for 2005.

    However, after reading the Visual Studio roadmap, I'm growing more confused: it basically says that ObjectSpaces will be released as part of VS.NET 2004, but what about Yukon ???

    So, I'd be grateful if you or someone else out here could sched some more light on ObjectSpaces, and tell us:

    1. Whether SQL Server "Yukon" will be released at the same time as VS.NET 2004
    2. Whether ObjectSpaces will only support SQL Server, or if it will also support Oracle and other RDBMSs.

    Thanks !