|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 23
Messages: 23
Messages: 23
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
EclipseLink to be the RI for JPA 2.0
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.
|
|
|
Message #249175
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: EclipseLink to be the RI for JPA 2.0
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)
|
|
|
Message #249179
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
OSGI
Mike
Can you give an overview about OSGI support ?
Is there a OSGI bundle distribution ?
Thanks
|
|
|
Message #249181
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: EclipseLink to be the RI for JPA 2.0
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.
|
|
|
Message #249183
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JPA for Portability
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)...
|
|
|
Message #249186
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: OSGI
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 :-)
|
|
|
Message #249206
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: OSGI
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?
|
|
|
Message #249212
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
OSGI - Webapps
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.
|
|
|
Message #249225
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JPA, Hibernate, Toplink, J2EE entitybeans
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
|
|
|
Message #249265
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TopLink code base
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
|
|
|
Message #249284
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: TopLink code base
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.
|
|
|
Message #249292
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Who really needs it?
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.
|
|
|
Message #249294
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JPA, Hibernate, Toplink, J2EE entitybeans
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.
|
|
|
Message #249296
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: TopLink code base
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!
|
|
|
Message #249309
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Who really needs it?
"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.
|
|
|
Message #249315
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: TopLink code base
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
|
|
|
Message #249316
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Persistence Buzzwording
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.
|
|
|
Message #249321
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Who really needs OSGI?
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.
|
|
|
Message #249323
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Eclipse hype (Persistence Buzzwording)
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.
|
|
|
Message #249348
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Persistence Buzzwording
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.
|
|
|
Message #249356
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Persistence Buzzwording
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.
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman continues to explore the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(January 21, Article)
Ted Neward is an independent consultant specializing in high-scale enterprise systems, and an authority in Java and .NET technologies. He is the author and co-author of several books, including Effective Enterprise Java. At TheServerSide Java Symposium in March, he will be presenting sessions on pragmatic architecture, ECMAScript and Scala.
(January 15, Article)
Now that Oracle is absorbing Sun Microsystems, there mixed views on what should come of the Java Community Process (JCP). While some say Oracle should become the new steward of Java and keep the JCP much as it was, others argue that it may be time to open-source this widespread language.
(November 24, Article)
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
