Discussions

News: EclipseLink to be the RI for JPA 2.0

  1. EclipseLink to be the RI for JPA 2.0 (23 messages)

    EclipseLink, a plugin component for Eclipse from Oracle, is going to be the reference implementation of JPA 2.0, as announced yesterday by Sun, Oracle, and Eclipse. OSGi services provided by EclipseLink include:
    JPA The JPA service supports the Java Persistence API (JPA) and enables mapping a Java domain model to a relational schema using metadata provided in XML and/or annotations. Applications using this service will have access to the mapping, query framework, transaction support, object caching (including clustering support), advanced database specific capabilities, and many performance tuning and management options. Each of these functional areas are flexible and extensible to address complex application requirements. Mapping Objects to XML (MOXy) The Mapping Objects to XML (MOXy) service with support for Java Architecture for XML Binding (JAXB) enables mapping of a Java domain model to an XML Schema (XSD) using metadata provided in XML and/or annotations. This service supports the generation of mappings and XSD from an annotated model, generation of the domain model and mapping from a provided XSD, or meet-in-the-middle mapping with a provided domain model and XSD. The application interface enables the efficient marshalling of the domain model objects into an XML document and un-marshalling of XML documents into domain model objects via DOM or SAX. Service Data Object (SDO) The Service Data Object (SDO) service will allow developers to generate dynamic and static SDO models from an XSD and use these within their application. In addition to the XML binding capabilities defined in the specification additional flexibility is provided by the Object-XML service. This approach provides a solution for applications requiring less coupling to the data structures being accessed and modified. Support for wrapping a Java object (i.e. JPA entity) within a DataObject will be provided to enable the usage of existing domain models with SDO. Database Web Services (DBWS) This service will provide a simple and declarative solution for defining and generating a Web service exposing database operations. Using the core Object-Relational and Object-XML capabilities, consumers can leverage default XML representations of their relational data or completely customize the shape of their XML documents. Enterprise Information Systems (EIS) The EIS persistence service enables the usage of data stores through Java Connector Architecture (JCA) resource adapters. Using XML metadata the interactions and their exchanged data are configured and mapped onto a domain model. The interactions data can be mapped from either the Common Client interface (CCI) or using XML schemas. This usage is intended for non-relational data stores where no JDBC or SQL access is provided.
    This is great stuff - it looks like we're moving closer and closer to the time when OSGi becomes Java's module system, officially and for real. It's worth noting: right now, Eclipse refers to an IDE built with OSGi, but the Eclipse Foundation is emphasizing Equinox - as a name, and as a runtime environment. Watch for a new Eclipse portal for the container.

    Threaded Messages (23)

  2. It is true that EclipseLink is a "plugin component for Eclipse" and that both Eclipse IDE users and other Eclipse projects now have a project that they are using to meet their persistence needs. However, this is really understating the value of the project. A better description of the project is as a runtime persistence component that can be used anywhere Java persistence is required. This means it can and is being used by multiple IDE's, shipped by application servers like Glassfish and frameworks like Spring, and usable within the small and large client applications talking directly to any database or generalized data source. This project represents a persistence platform that implements all the main persistence specifications (as were listed), is integrated with all the major execution environments, (i.e. Java EE, Java SE, OSGi, SCA) and can read/write to any known type of data source. All of this in a single jar under 5M. It is very cool to be part of the Eclipse community. It is also cool to be involved with the JCP and be the JPA persistence implementation for Glassfish. -Mike (member of the EclipseLink team)
  3. OSGI[ Go to top ]

    Mike Can you give an overview about OSGI support ? Is there a OSGI bundle distribution ? Thanks
  4. Re: OSGI[ Go to top ]

    Mike

    Can you give an overview about OSGI support ?

    Is there a OSGI bundle distribution ?

    Thanks
    OSGi is still in the process of "finding itself" on the server side so there is admittedly more work to do within the specs to make everything standard. Until that is done our approach is to offer a solution that does what we think people will expect. What that means is that, yes, the first post-incubatory EclipseLink release will also be distributed as technology bundles for applications that want to use OSGi to be service-based and dependency-driven. For those who are planning on using it in this environment we would encourage you to try it out and offer feedback. Involvement is open to *all* interested parties :-)
  5. Re: OSGI[ Go to top ]

    OSGi is still in the process of "finding itself" on the server side
    The best thing that could happen for OSGi at the moment is for someone to post how to set up a web app using OSGi components. I'm playing around with Jetty and Equinox but it still feels a little kludged together. So, something like Jetty, etc. running inside Equinox, or Jetty delegating to Equinox through some sort of servlet adapter where servlets and OSGi components are installed. Has anyone deployed a web app project based on OSGi? What was the architecture?
  6. OSGI - Webapps[ Go to top ]

    We primarily build our web apps on OSGi. To support this we started a project (open source) about 12 months ago to port the key aspects of the Eclipse Workbench API and JFace into a web app. The rest of the stack is not much different from a normal web app (hibernate, spring/spring dynamic modules, etc) You can check out the projects at www.karora.org. Eclipse RAP is also much the same thing (www.eclipse.org/rap), but we've used a different UI framework.
  7. Who really needs it?[ Go to top ]

    OSGI on the server for webapps is nice, but... This technology still has a long way to go before it gets mature. Once this is stable and very well documented I'll take a look and recommend it to clients. At present documentation is a joke. And as long as it isn't mature yet I do not have any interest at all to waste my time on trying to find out how to write competitive apps with it. Development projects are moving aggressively offshore to India and other low-cost countries. Against this backdrop I'm not motivated much to conduct basic research how to write apps with this technology. Oracle, IBM and Sun should better do that in India. And btw, the webapps are moving towards Rich Internet Applications, so we need something to compete against Silverlight and Flex.
  8. Re: Who really needs it?[ Go to top ]

    "This technology still has a long way to go before it gets mature. Once this is stable and very well documented I'll take a look and recommend it to clients. At present documentation is a joke." I think Eclipse may have proved within reasonable doubt that its as stable as any other technology out there, considering Eclipse has been running on top of it for a long time now. Not to mention all the embedded devices that use it. There's also several different OSGI projects out there, not just Equinox. Admittedly the Equinox documentation is a bit light on, however for what you can't find from Equinox, you'll find from Knoflerfish, Felix, etc etc. Not to forget the actual specifications from the OSGI Alliance (http://www.osgi.org/Main/HomePage). Regardless of whether you're using a predominately client side framework such as Silverlight or Apollo, a pluggable server side framework still has huge advantages for driving these clients.
  9. Re: Who really needs OSGI?[ Go to top ]

    I expressed my previous thoughts very poorly. And excuse my bad English. As for JPA, it is extremely useful in almost every business app that has to deal with persistence. I like JPA very much and use both Hibernate and Toplink. A standarisation of lightweight persistence was urgently needed in the Java World, and we got that with JPA. Mapping Objects to XML (MOXy) sounds very useful too. And since JPA is far from perfect, it's good news to read that JPA gets actively improved with requested features. But OSGI? It's getting continously hyped and I'm tired of this. Admittedly, it is a revolutionary concept to replace parts of the application (bundles) at runtime. But OSGI for webapps is at present still a halfbaked, unfinished solution. Perhaps the core technology works well already. Could be well the case, I don't know. But the tutorial someone posted a link above to speaks for itself. It demonstrates the use of OSGI for webapps with a servlet! So should we go back to servlet programming? No! What we need in the Java world are very powerful frameworks to competitive against the newest technologies from Microsoft and Adobe. But what is the reality? This brings me back to my point in the previous point: IBM global services (and other multinationals) are building huge armies of developers in India and other low-cost countries. But they are not really using these armies to improve projects like the hyped Eclipse platform (look only at SWT which was originally (and still is being) hyped, because it provides native widgets, but it is already looking outdated and does not really get maintained actively.). Rather, the maintenance and improvement of these projects and technologies gets delegated to the so-called "community". And ideally the community should work on these project for free of course.
  10. Tutorial/Demo[ Go to top ]

    Here's a starting point: http://www.eclipse.org/equinox-portal/tutorials/server-side/
  11. EclipseLink OSGi[ Go to top ]

    You can find an overview of EclipseLink OSGi on the EclipseLink Wiki [1]. This page captures what our goals were that got this work started. From there we went on to build a proof of concept which has helped us understand the issues. Right now the OSGi packaging of EclipseLink is available in a branch of the EclipseLink SVN repository at eclipse.org. You can find instructions on getting started on the EclipseLink OSGi POC Wiki Page [2]. There are also a bunch of demos that illustrate various ways of packaging your classes and configuration. Before you get started, remember the code that's available is a POC. ;-) We'll be converting the main branch over to OSGi in our next monthly Milestone which we'll start on in April (2008). Try it out and let us know what you think on the EclipseLink forum [3] or the eclipselink-users mailing list [4]. Shaun [1] http://wiki.eclipse.org/EclipseLink/Development/OSGi [2] http://wiki.eclipse.org/EclipseLink/Development/OSGi_Proof_of_Concept [3] http://www.eclipse.org/newsportal/thread.php?group=eclipse.technology.eclipselink [4] https://dev.eclipse.org/mailman/listinfo/eclipselink-users
  12. While this has the earmarks of a Kumbaya moment, in today's SearchSOA.com story on the announcement, analysts see it as more of a realpolitik move on the part of Sun. According to Burton Group's Anne Thomas Manes:
    I don't think this represents a move by Sun to join/endorse/get-warm-and-fuzzy with Eclipse. I suspect Sun is happy that the Eclipse Foundation is participating in a JCP effort. Much of what goes on at Eclipse never finds its way into formal Java standard APIs. This situation is a case of historical rather than new precedent. Oracle provided the reference implementation of JPA 1.0 based on its TopLink implementation. Oracle has since moved this effort to Eclipse, the EclipseLink project. Sun would have had a huge PR issue on its hands if it had refused to allow Oracle to provide the v2 reference implementation just because it's being developed at Eclipse.
    For those hoping to see OSGi become Java's module system, that will likely take something similar, but with Oracle, IBM, SAP and JBoss/Red Hat all forcing the issue.
  13. JPA for Portability[ Go to top ]

    Very intriguing move from Glassfish owners, kind of signals a competitive front with JBoss over Hibernate more than an ongoing battle over porting WebLogic accounts, but perhaps this is an embrace-and-extend strategy, or maybe there just isn't a lot of strategic competitive analysis going on at Sun (apologies, i know this is not true)... OSGi has not been formally suppported by Glassfish, AFAIK, even though they are doing their own 'modularity' campaign; i can't help but think that there is a reference to Spring support coming from Sun, beyond just JAX support, which seems rather disheartening considering the anti-EJB campaign being waged by SpringSource exec's... JPA is a natural for Oracle, though they were beaten to the punch by Gavin King, and given a lifeline by Glassfish v. 1 with TopLink support; given the BEAS acquisition, there seems to be some maneuvering prior to the decision of Orion v. WL... the b.l. is that JEE continues to offer a portability value proposition that nothing else can offer, if we can ever get to a marketplace where Geronimo/WebSphere, NetWeaver/SAP, WebLogic/Oracle, Glassfish/Sun, and JBoss/RedHat can provide true inter-operability of apps, the conditions for a marketplace of components and independent developer offerings will be satisfied... (apologies for repeat from El Reg)...
  14. I'm abit of a newbie to some of theese technologies. I've used hibernate and j2ee entitybeans (ejb 2,3), and I've seen toplink. I don't know much about JPA. Are theese technologies overlapping? If not, how can I know which persistency api I should learn for the solutions I need? Toby
  15. Toby, The first choice should be to use the JPA API. It is the standard for Java ORM persistence and is implemented by multiple persistence implementation providers (including Hibernate, EclipseLink and others). Then, if you find that you need something outside the API you can make use of the vendor extensions of the implementation you are using.
  16. TopLink code base[ Go to top ]

    the fact that its most likely based on the TopLink code base makes me rather skeptical. That code is in many parts 10 years old and looks very odd, which may be partly due to its non-Java heritance, and partly to the closed source development mode it was maintained under. And despite its age it still yields astinishing errors from time to time.. Chris
  17. Re: TopLink code base[ Go to top ]

    the fact that its most likely based on the TopLink code base makes me rather skeptical. That code is in many parts 10 years old and looks very odd, which may be partly due to its non-Java heritance, and partly to the closed source development mode it was maintained under.

    And despite its age it still yields astinishing errors from time to time..

    Chris
    Well the jpa RI always used to be Toplink in some incarnation, the 1.0 RI was Toplink essentials. Now 2.0 will be based on Eclipselink which is even more of the Toplink code.
  18. Re: TopLink code base[ Go to top ]

    Christian, The first thing you will notice is that 4 out of the 5 tech components mentioned have not even been around longer than a few years, so it would have been quite a feat to have coded them up 10 years ago. TopLink has been doing ORM for 10 years, though, so some of ORM underpinnings used for parts of JPA have obviously been around for awhile, but much of the older stuff has been rewritten, reworked and cleaned up. Some is still there, though and might never be changed (and might never need to be since it ain't broke). I find it a little strange that you speak of closed source development as if it were something that by nature creates bad code. In fact, the TopLink code is better than most of the open source code that I have seen. As far as astinishing errors, well we aim to astinish. If you know of a particularly astinishing one then feel free to enter a bug, or even submit something that you think would be an improvement!
  19. Re: TopLink code base[ Go to top ]

    Mike, Of course I am referring to the ORM part only. The toplink regression errors I have recently encountered when migrating from TL 9 to TL 10 are already on record. I guess nowadays everyone can make their own judgement with regard to the code quality.. chris
  20. Persistence Buzzwording[ Go to top ]

    I find it quite bizarre that "EAI", "SDO", "XML" are considered "Persistence Architecture". They are by no means - they are mapping technologies. Object Relation Mapping *is* a Persistence Architecture but that does not make everything that can be mapped from an object and dumped into a textfile a "Persistence Architecture". As for the OSGi - I don't really care what JPA2 *uses* to be implemented and I think it is rather unwise even to consider to "extend" such a massive and complex technology. And finally for eclipse: I would really appreciate if the eclipse team would get their act together and fix their plain old java ide that (from my gut feeling, maybe because of feature creep) has degenerated lately.
  21. I would really appreciate if the eclipse team would get their act together and fix their plain old java ide that (from my gut feeling, maybe because of feature creep) has degenerated lately.
    A big thank you for your comment! I already felt I'm alone with my criticism of the Eclipse hype. We need exactly such kind of critical comments and not marketing hype. Otherwise decision makers won't listen.
  22. Re: Persistence Buzzwording[ Go to top ]

    I find it quite bizarre that "EAI", "SDO", "XML" are considered "Persistence Architecture". They are by no means - they are mapping technologies.

    Object Relation Mapping *is* a Persistence Architecture but that does not make everything that can be mapped from an object and dumped into a textfile a "Persistence Architecture".
    I am not sure where you read that EAI, SDO and XML were "persistence architectures". EIS has a Connector API and SDO is also an API. XML is... well... it's XML. There are usecases for using each of these in a persistence-related context, which is precisely why EclipseLink provides the persistence support for them.
    As for the OSGi - I don't really care what JPA2 *uses* to be implemented and I think it is rather unwise even to consider to "extend" such a massive and complex technology.
    I think you might be missing the main OSGi-related point of this thread (or at least the one that the announcement was originally supposed to have made). EclipseLink is not implemented using OSGi, but one of its goals and features is to run within an OSGi environment, taking advantage of the lifecycle, service, dependency and version mechanisms that OSGi has to offer. This means that if people want to use one of the EPS components in their OSGi application then they can. There is no requirement to do so, though.
    And finally for eclipse: I would really appreciate if the eclipse team would get their act together and fix their plain old java ide that (from my gut feeling, maybe because of feature creep) has degenerated lately.
    I obviously can't comment on that (not being part of the Eclipse IDE team) other than to say that you should offer your specific feedback to them directly.
  23. Re: Persistence Buzzwording[ Go to top ]

    EclipseLink is not implemented using OSGi, but one of its goals and features is to run within an OSGi environment, taking advantage of the lifecycle, service, dependency and version mechanisms that OSGi has to offer.
    this is sensible. Thanks for clarification, Mike.
  24. Other JPA 2.0 Providers[ Go to top ]

    The Apache OpenJPA project is also providing a JPA 2.0 implementation at [1] and has just announced an Early Access milestone 2 preview build for testing purposes only at [2]. [1] http://openjpa.apache.org/ [2] http://openjpa.apache.org/2009/06/03/openjpa-20-milestone-2-distribution-is-available.html -Donald