The rumours have been confirmed. Late last week, Oracle and WebGain cemented the deal to handover the TopLink family of products (as well as the support, development and consulting personnel) to Oracle. TopLink v4.6 will appear on the Oracle Technology Network for free download on tuesday.
Via the OTN, developers will be able to download a full non-expiring copy of TopLink, but must purchase standard licensing when ready to deploy it into production. Pricing of Oracle's TopLink has not yet been set.
Oracle has committed that TopLink will continue to support non-Oracle appservers and databases, and that TopLink development and support will continue.
Oracle has not announced any special packaging plans/strategy to leverage TopLink in its quest for higher Oracle 9iAS marketshare, although possession of one of the industries best O/R mapping/caching products surely gives it an upper hand next to IBM and BEA.
As for WebGain, by all accounts it is no more.
Past TSS Related News:
Large Liquidation Auction at WebGain Headquarters
WebGain to Sell TOPLink to Oracle and Exit Tools Market?
Wednesday June 19:
Oracle has posted toplink on the OTN here:
I worked with TopLink for about a year. It had a challenging learning curve, but it greatly enhanced WebLogic's own ability to manage object persistence. At this point, one could argue that EJB 2.0 could make TopLink redundant, but I am not sure. I believe that TopLink failed as a commercial offering because it was too expensive. Now ironically, I think it may undergo a rebirth and successful run if it can attract a new set of developers who would previously have ignored such a high priced item.
What do you think ? Does EJB 2.0 make TopLink obsolete ? Or does TopLink still offer compelling functionality above and beyond other persistence frameworks ? If the latter, will ORacle be an effective owner for this technology?
my former company used toplink because of its fair performance / rbdms portability ratio, and friends of mine architects use it and are quite happy with it too (for the same reasons). Now that oracle got it, I wonder how performance will evolve on rival rdbms like db2, ms-sql, open source databases and others. It sure is great news for life long, oracle only houses cos they get a great O/R mapper and JDO implementation that will fit perfectly with their favorite database, but if I would be a db2 or ms-sql client and had already had invested in toplink ($s and engineering effort) I would be quite worried about the future. Even if Oracle wouldn't drop support for other rdbms, their best interest is to optimize the good stuff for oracle and only after that think about rival systems, which is a complete opposite of webgain which, since it wasn't in the rdbms market, needed topink to be as portable and possible and performance to be as good as possible on all supported platforms. or am I just to paranoiac?
TopLink hadn't yet completed a JDO interface for its product, which is something I was really hoping for. They provided a "preview" of their technology, but it was released prior to the finalization of the JDO spec.
I would love to see Oracle finish the JDO work that WebGain had begun in TopLink and make it fully JDO 1.0 compliant.
I wouldn't mind seeing the pricing model come back to reality, either...
Having worked with TopLink on a number of our client sites I have come to the conclusion that it basically delivers as promised: dramatically reducing the amount of code that must be written in the persistence tier and also providing serious performance improvements at run time.
EJB2.0 is a great improvement on 1.1 but still does not have the flexibility and power of the TopLink O/R. Nor do the container vendors provide the range of caching options that TopLink does.
The concern for me was that Oracle would fold this into their app server and stop supporting the rest (still a possibility I would think).
Who knows: they may actually price the product so it is more favourable to smaller organisations and thus allow more to benefit until the EJB specification catches up.
As with all acquisitions - will be interesting to see what is what in 6 months time.
Price will be a noticeable factor in my interest. TopLink used to be fairly inexpensive, and pretty cool, but as it matured, it became (IMO) very expensive. Still feasible for large projects with solid technical management, mind you, but harder to justify on small-to-mid projects and without the presence-of-brand to sell it as a line item.
With those constraints, EJB/CMP and JDO loomed large as upcoming competition. If Oracle can return TopLink to its pricing roots, or closer to it, my interest in it might be substantially revived.
How long before Ward Mullins plunges into this discussion and starts plugging CocoBase? :-)
How long before Ward Mullins plunges into this discussion and starts plugging CocoBase? :-)
Why should I when you've done such a nice job for me :)
After just completing Floyd's Design Pattern book (great book Floyd) and after giving it quite a bit of thought, I come to the following conclusion.
It looks like entity beans (even CMP 2.0) isn't there yet. Maybe there is great promise for the future, but it looks like a company getting ready to start a J2EE today, would be prudent to avoid entity beans (i.e. give the vendors another couple of cycles on the spec and see what they come up with). So based on that, as Floyd points out in Chapter 8, you only have a few choices. A O/R tool like Toplink, RYO (roll your own), or JDO. All of this means we are still "on the bleeding edge" so expect some pain with either choice. That said, I'm inclined to lean towards JDO, but then, it's not part of the J2EE spec, and not likely to become part of it. So I guess I'm looking for input from other's on what would be a practical JDO path TODAY. Is an open source product like Castor a good starting point? Depending on the size of the project, I may be more than willing to solve the PM layer problem as best I can today, knowing full well I may incur the cost of rewriting that layer later if a better, and cost-effective solution shows up in the future. If not Castor, what would someone recommend. I realize this is a little open-ended without budget contraints factored in, but am curious what JDO options we have in the industry today?
Thanks in advance,
TopLink had its own pros (enterprise class, feature rich) and cons (slow, expensive etc). But in todays economy where cost is a major factor companies/projects have started looking for alternative solution. To cater to the new economy we at Objectfrontier have been marketing "Frontiersuite" a feature rich, enterprise class persistence product at a very reasonable price with no runtime, CPU or Server Fees. We provide caching mechanism, both single JVM and JMS based distributed caching features. Our product supports EJB 1.1, EJB 2.0 and JDO 1.0 all from the same product. We provide a rich GUI environment with integration to UML tools like Rational, Together, Paradigm Plus and IDE's like JBuilder, Forter, Visual Age etc. FrontierSuite is portable across application servers and databases. Our customers (proven by internal metrics) have compared us with our competition and found us to outperform our competiton time and time again. For those who have not tried out FrontierSuite you can download a free evaluation copy at www.ObjectFrontier.com.
<Quote>I realize this is a little open-ended without budget contraints factored in, but am curious what JDO options we have in the industry today? <Quote>
Try out FrontierSuite for JDO at WWW.ObjectFrontier.com. We recently released the GA version and is the 1st JDO product in the market today with a robust GUI development environment. We also offer a powerful and stable single JVM and JMS based distributed caching mechanism with integration to leading tools like Rational, TogetherSoft, JBuilder, Forte etc. We also support application servers like Weblogic, WebSphere, JBoss, Oracle etc.
Thanks for the reply. Yes, it does look like you have very reasonable pricing. I will look thru your website for documentation, but let me ask you a high level question. Can you compare your product (JDO) to the open source Castor, maybe on the basis of features that would be important to the J2EE developer.
<quote>....but let me ask you a high level question. Can you compare your product (JDO) to the open source Castor, maybe on the basis of features that would be important to the J2EE developer<quote>
This is indeed an high level question. Anyway, I am splitting the comparision (FrontierSuite JDO vs Castor) between development and runtime.
FrontierSuite for JDO provides.....
1)Reverse engineering an existing schema (tables, views, sequences, stored procedure, foreign keys constrains) into an object model and generate JDO classes along with deployment JDO XML file.
2)Forward Engineering from Object Model to automatic (of course customizable) mapping and generation of tables, JDO class code generation.
3)Take existing Java Classes and enhance them for JDO Capabilities and automatically create relational mapping.
4)Take existing Java Classes and existing relational tables and provide a workbench for mapping the java classes to relational tables. (A bridge Pattern)
FrontierSuite for JDO runtime.....
1)Works in any managed J2EE compliant application server environment. (With container managed transactions)
2)Supports Optimistic and Data Store (Blind Update and Pessimistic) transactions.
3)Transactional work is flushed to the data store (as a logical unit of work) before transaction completion to achieve optimal data store calls.
4)Maintains process level (across all persistence manager instances) caching which improves higher performance. Process level caching is not only at object level but also across object relationships.
5)JMS based distributed caching across JVM (clustered environment)
I would encourage you to download and evaluate FrontierSuite for JDO and if time permits provide us with a feedback as to how we are different/better than Castor. Maybe we can use your report for competitve analysis!!!!!!
Thanks for the further feedback. The PM topic seems to be a moving target in J2EE land. I would hate to have been a company who invested significantly in Toplink and was not an Oracle customer. Some things, like Application Servers lend themselves to being dependent on black box solutions where you rely on the vendor. A J2EE developer's platter is full enough without having to write the application server plumbing code also. I haven't decided if that same thinking applies to the PM code. I'm thinking actually having access to the source code for the PM layer, even if less robust, may be the prudent play at this point in time. This would leave one with RYO, or open source like Castor. Just my two cents. I do appreciate the feedback.
It looks to be at
Go to http://otn.oracle.com
Click on Oracle 9i Application Server on the right
Click on Production Software
It looks like it's listed as #2: Oracle 9iAS TopLink 4.6 for Linux, Unix, and NT/2000, 32Mb Unix or 42Mb Windows download.
Quick link is at:
I tried this link http://otn.oracle.com/software/products/ias/content.html
It's empty. No files to download yet.
I wonder how many people downloaded TopLink from oracle today just to see if it _really_ was there.
I downloaded it yesterday from technet.oracle.com. They have both Windows and Unix/Linux downloads.
It's _really_ there.
This is consistent with Oracle's general policy of offering free development versions of all their products, no matter how big... Oracle 9i Enterprise edition database is over a 1.5 gig download, but I can get it. :)
This is good. But it's almost 5pm on Tuesday and I don't see it yet. Bah.
As a former developer at the Object People, it's sad to see Webgain's demise. I helped write the original version of Toplink for Smalltalk and Toplink for Java. At the time, Toplink was reasonably priced and the development overhead was quite low.
However like many users I feel that the pricing scheme initiated by Webgain really did more harm than good. After leaving the Object People to pursue consulting, I tried to persuade many projects to consider using Toplink but the price was always an issue. Also, when we released Toplink for Java in 1998, Cocobase was our only competition. The only other alternative was coding straight JDBC calls. Now with EJB, JDO and numerous free OR mapping tools available, it's hard to justify the price.
In my opintion, entity beans perform very poorly and the book is still out on JDO. I hope Oracle continues to support Toplink since I still consider it the best tool on the market.
yvon at yslconsulting dot com
By the time we evaluated Toplink, we composed a list of the product comparison with Entity Beans based solution (see below).
TopLink 4.0 comparison with Entity Beans-based solution
1. Multiple Java application types exist at CNA. Not all of them have Entity Beans as a component. Subsequently, Entity Beans option is applicable to only a fraction of current and future applications, while TopLink does cover them all.
2. Mapping options of TopLink are by far more advanced than these of Entity Beans. TopLink supports following mapping options: One-to-One, One-to-Many, Object-Type, Aggregate-Objects, Direct Collections, Many-to-Many and Transformations.
3. Stored procedures are not part of EJB 2.0 standard, which means one cannot map stored procedures to the Entity classes. TopLink’s support for stored procedures is not excellent but rather satisfactory. Still, it’s better than nothing.
4. Alternative data sources, such as XML, are not supported by Entity Beans. TopLink’s current support is rudimentary but extensible, so it is perceivable that the required support can be added relatively easy.
5. Debugging is easier with TopLink. Being packaged as a regular .jar file, TopLink can be debugged using regular Java debugger. For Entity Beans, debugging is complicated due to their “remote” nature.
6. TopLink’s performance is superior. According to vendor, TopLink performance is even better than the custom JDBC code, let alone traditionally slower Entity Beans. WebGain claims that the TopLink may exceed performance of Entity Beans based code by factor of 10.
7. WebGain provides strong toolset that includes Mapping Workbench, Object generator, Schema generator and administration utilities.
8. Programming interface to TopLink is simpler and can hardly be misused.
9. Number of classes to handle is greater with Entity Beans. It requires multiple service classes to be used along with the base domain class. Toplink only requires base domain class.
10. Number of configuration files is much smaller with Entity Beans solution. With version 4.5, TopLink introduces one XML file per class to be mapped, thus creating dozens of configuration files per average application.
11. Two solutions can coexist. When it is appropriate to use Entity Beans, TopLink may be used as the Persistence Manager, or “behind the scenes” mapper and optimizer, while preserving the standard API of Entity Beans.
12. EJB approach requires higher skills from a developer. It is a complex standard and has to be used carefully. TopLink is simpler in use and doesn’t require extra training except for designated data administrators. Regular developers are not exposed to the internals of TopLink, unlike in case with Entity Beans, where every caller procedure has to incorporate elements of the EJB standard.
13. Cost of Entity Beans solution is significantly less than that of TopLink, but it is not negligible. Websphere has an alternative, cheaper edition without an EJB container, that can be used instead of Advanced Edition in cases when no need in EJB has been identified. Toplink can still be used in those cases.
14. CMP Entity Beans solution frequently requires writing custom objects outside the EJB container to handle complex queries that need exceptional performance. This creates a mixed environment which is harder to maintain. It is less of a case with Toplink, as it is much more efficient and supports complex queries better.
15. Locking is not natively supported by Entity Beans, while Toplink has the support.
16. CMP Entity Beans do not support role based database security.
17. Toplink doesn’t even need application server to function.
What will happen with Oracle's own framework BC4J ?
I think with Toplink they have a more matur addon product to oc4j and support for Ejb 1.1 and 2.X !
For the TopLink BC4J relationship take a read of the TopLink FAQ:
They are clearly two different products:
* BC4J is an application development framework based on J2EE Design Patterns delivered in Oracle9i JDeveloper - see:
that happens to have some object relational mapping capabilities within it but has a far broader focus than that alone.
* TopLink is an O/R mapping tool as per this discussion
Right now they appeal to two very different kinds of developers with some small overlap; however, the BC4J team would like to be able to provide the option of taking advantage of the TopLink O/R layer.
On their own each is quite powerful, when/how BC4J starts utilizing TopLink, for those interested, it will make for an even more interesting combo. Especially since the next release of BC4J will have a Apache Struts presentation binding.
My impression is BC4J is too Oracle proprietary to be taken seriously by the hard core J2EE community. I know guys who haven't written a line of code using this framework. Its' drag and drop functionality leads to rapid development of small data capture systems. I think the drawbacks are less maintainability (if things start going wrong!), inflexibility to cater for larger systems needs, and the Oracle runtime libraries that say another J2EE vendor like WebLogic needs to run these BC4J applications (very non J2EE!).
TopLink on the other hand is a great ORM tool. We are achieving great performance. It did take a while to get up and running though. It is non intrusive into your ORMs (no interfaces to implement, no classes to inherit from) although of course it does have a propietary code when u want to read object, update and commit changes. I think as long as you keep your business model pure (standard J2SE) and keep TopLink propriatary code limited to your business objects then you'll more readily build up common library when using TopLink and be in a better position to change from TopLink to another ORM in the future.