Versant, today announced the availability of Versant enJin 2.3. enJin provides transparent persistence and distributed caching for Java objects within EJB and servlet/jsp tiers. The latest version adds full support for JCA integration with appservers, JTA support (allows enJin to participate in managed transactions along with other datasources), and EJB 2.0 CMP.
- Posted by: Floyd Marinescu
- Posted on: June 06 2002 11:39 EDT
Check out Versant enJin.
FREMONT, Calif., June 4 /PRNewswire-FirstCall/ -- Versant Corporation (Nasdaq: VSNT - News), a leading provider of middleware infrastructure technology, today announced the commercial availability of Versant enJin 2.3. Versant's latest release enhances support for Java 2 Enterprise (J2EE) standards, making it easier for customers to develop and deploy J2EE applications using Versant enJin with any J2EE-compliant application server.
enJin is focused on the growing segment of the J2EE applications market that uses complex object models to address business needs. Using enJin with J2EE-compliant application servers makes it feasible to implement sophisticated business logic supported by a rich domain model without the time-consuming task of object-to-relational mapping.
"The growth of J2EE architectures has given rise to an increase in the use of complex, domain-driven object models to support new e-business applications," said Keiron McCammon, Versant CTO. "enJin was designed to not only simplify and speed the development of these new applications but also to turbo charge their overall performance and scalability. The growing use of XML and Web Services in these applications have also demonstrated the need to reliably store what we call application state in the middle-tier. Our latest release, enJin 2.3, with its support for JTA, JCA and CMP, makes it easier for developers to develop and deploy any J2EE, XML or Web Service application and gain critical performance and reliability benefits."
J2EE standards such as J2EE Connector Architecture (JCA) and Java Transaction APIs (JTA) were developed specifically to allow connectivity and transaction control between the application server environment and enterprise information systems, including relational databases, SAP, PeopleSoft, CICS, among others. enJin 2.3 now provides:
JCA support as the standards-based mechanism for integrating enJin with any J2EE compliant application server;
JTA support to enable standards-based synchronous transaction coordination between enJin and enterprise database systems, enterprise information systems (EIS) or Java message queues (JMS); and
Enterprise JavaBean (EJB) 2.0 Container Manager Persistence (CMP) to enable standards-based data access for EJBs.
enJin 2.3 is available today for BEA WebLogic customers and will be available for IBM WebSphere customers later in the summer.
About Versant Corporation
Versant Corporation has led the industry in highly scalable, reliable object management solutions for complex enterprise-level systems since its founding in 1988. The company's Object Database Management System (ODBMS) serves as the core database for fraud detection, yield management, real-time data collection and analysis, operation support systems (OSS) and other large-scale applications in the telecommunications, financial services, transportation and defense industries. Versant enJin and Versant Developer Suite, based on the same proven technology and seamless object persistence, help accelerate both the development cycle and the transaction speed for e-business and Internet infrastructure companies. For more information, call 510-789-1500 or visit www.versant.com.
- Versant Announces enJin 2.3 by Kenny MacLeod on June 06 2002 12:28 EDT
- Versant Announces enJin 2.3 by moussaud benoit on June 07 2002 04:20 EDT
- Versant Announces enJin 2.3 by Genady Belenky on June 07 2002 10:01 EDT
- enJin as an O/R mapping solution by Robert Greene on June 12 2002 12:56 EDT
Has anyone here had any experience with enjin? We hear a lot about TopLink, CocoBase and JDO, but little or nothing about versant's efforts.
Versant used to be the Pooch's Privates in the enterprise OODBMS world, but it seems they've realised that's a non-starter, and have moved into the O/R market.
We are using Versant Enjin integrated with Borland AppServer in all our projects and we are very happy:
* smart intergration (now iwth JCA)
* small interference with the EJB code, in mode SMP (Session manage Persistence), juste one ligne at the beginiing to get a Versant Session and one line to release it at the end.
* Good performance whatever the database size.
Versant will soon devilery a JDO driver with Enjin.
What is the difference by using enJin vs O/R mapping tools?
I used enJin 2.2 one year long in one of my projects. The project included Swing GUIs and Session EJBs (Session Facades) deployed on WebSphere Appserver 3.5. No entity beans. Development environment was TogetherJ 4.0 and Ant. We had also very strong transactional requerements in our accounting system.
Advantages of enJin -
--It is fast. No runtime mapping, no bloated memory for your cache - the object-oriented database is your cache.
--No need for cache synchronization in the distributed business logic - your database server cache coordinates the client database caches used by the Session Beans.
--It is easy in the team development.
There are no mappings in enJin in time of development at all!
Using the O/R mapping tools you may have some vendor specific tool for mappings, and you have to create the mappings during the complete development time. The mappings will be stored as files or generated java classes. If two developers work concurrently on the same mappings some merging conflicts are possible. If one of them try to resolve the conflicts, she/he will be faced to the vendor specific text/xml-files or vendor specific generated classes. It is almost impossible to solve these conflicts - this is the reason why in such projects only one person is in the mapper role (bad for XP-projects).
If you have a relational database and enJin you can create the mappings just before you build the integration version - all development with enJin is mappings-less.
Unfortunatelly I can't say anything about the reliability of enJin and it's O/R mapping functionality in the production environment.
We were happy to use it in the development.
nfortunatelly I can't say anything about the reliability of enJin and it's O/R mapping functionality in the production environment.
Do you mean you never deployed your code to production, or that you are using something else in production ? Please specify.
We deployed our code in the integration environment. The project had a pilot status - that is the reason why we didn't have a real production - the project didn't go live.
The primary storage of our business data was oodbms Versant which is part of enJin. The nature of our data and the access to it was more object-oriented then relational.
That was the reason why we did not use OR/mapping features of enJin.
enJin is actually much more than an O/R mapping solution. If fact, in many ways it is the antithesis of O/R mapping. When using enJin you actually eliminate the need for it.
enJin allows you to just use pure Java to model your problem domain and then store that object model transactionally in the Versant ODBMS. Taking this approach allows you to store transactionlly, extremely complex domain models with the same effort as writing an in memory application.
This means in your business object layer, the objects controlling business rules, workflow, longer running transactions, session state, etc can be directly held in the enJin database working within the context of a distributed cache in a clustered application server environment.
Of course, a portion of the information that may result as part of a business process could need to go back to another system ...for say billing purposes to PeopleSoft or Oracle Financials. In this case, the tools use to propagate that "data" are the standards as defined by J2EE. You use JTA or JMS depending on your application requirements to perform synchronous or asychronous transactions to those other systems.
In general, the "data" required to be propagated to those systems is far simpler and less in quantity so much more managable when it comes down to the business of doing O/R mapping. In many cases, it is simple enough that you can actually use a CMP Entity bean that takes care of the mapping for you ....something that is generally not possible when trying to write the whole domain model using CMP beans.