Sun ONE Studio took out JDO support following a product rebranding in May 2002. Now it is going back in again thanks to a partnership with SolarMetric Inc. Kodo JDO will be a plug-in for the Studio IDE.

Joe Keller, vice president of marketing for Java Web services and tools at Sun, said: "There was a request from our user base to go back to supporting JDO".

Is this a sign that JDO is picking up steam (instead of dying off like many pundits have been saying)?

Do you still consider JDO as a viable persistence alternative?

Sun ONE Studio To Include JDO Again

Good stuff!
This is important, listen to your user base!!

Thanks.

Yep this is good news. Developers definitely want transparent object persistence. Sun needs to do more to promote JDO, but this is a good start. Does Kodo have a netbeans or eclipse plugin?

Yes, Kodo JDO supports the following IDEs with close integrations:

JBuilder
WSAD
Eclipse
SunONE Studio
Netbeans
IntelliJ Idea (coming soon)

Additionally Kodo JDO integrates with Apache ANT.

Neelan Choksi
SolarMetric, Inc.

JDO is not the only one solution to transparent object persistence.

You can try others API to transparent object persistence, eg hibernate, ojb, castor. These are not based on JDO Specification.

Here are open source implementations of JDO, most of then are not JDO 1.0 compliant:

TJDO - tjdo.sourceforge.net
XORM - xorm.sourceforge.net
JPOX - www.emploigratis.com (I like this)
OJB - db.apache.org/ojb
Castor - ?? url ?? - castor is a too much far from JDO 1.0 compliance

JDO free implementation:
http://libelis.com/

Commercial implementation
http://www.objectdb.com/
http://libelis.com/
http://solarmetric.com
http://www.hemtech.co.za/jdo/index.html

More info about JDO:
http://www.emploigratis.com/kb/category.jspa?categoryID=16
http://www.jdocentral.com

I think it would be fair to also mention ExcadelJdo (http://www.exadel.com/products_jdoproducts.htm) as commercial implementation.

Best regards,
Fitech Labs, Inc.
xNova™ - Service Oriented Architecture for Java and .NET

http://castor.exolab.org/
They explain in their FAQ the diff between [Sun]JDO and their version.

"Castor JDO: Java object persistence to RDBMS
Castor JDO is not the same-as or compatible with Sun's JDO. We have a different approach to handling data object to RDBMS mappings. Please see the JDO FAQ for more information."

Not to forget FrontierSuite for JDO as another commercial implementation.

www.objectfrontier.com

No but it's the only STANDARD.

> JDO free implementation:
> http://libelis.com/

Limited to non-commercial use. The commercial version costs a whopping $4,000/cpu. We're talking WebLogic budget here.
 
> http://solarmetric.com

I've used Kodo on a couple projects now and so far it's working great for me. The support is super. And it is one of the lowest priced commercial JDO implementations.

Michael

>
> No but it's the only STANDARD.
>

Its the only SUN STANDARD, but there are other standards, eg: ODMG

Best wishes to KODO.

<Quote>
..Do you still consider JDO as a viable persistence alternative?
<Quote>

The answer we are getting from our customer base is definitely an emphatic 'Yes'.

JDO is quietly being accepted as a very solid and reliable persistence alternative by many people. And with a range of vendors offering solid reliable implementations with top quality features, it is very easy to adopt JDO. For example some of the features of FrontierSuite for JDO, a JDO impl for RDBMS include:

a. MDA based development environment. This allows developers to create class diagrams in Rational Rose, Together etc and generate JDO code and map the classes to database entities automatically.

b. Multiple development approaches. Developers can build JDO applications either freshly (forward engineering), or create equivalent JDO classes for legacy database schemas (reverse engineering), or migrate existing java applicatiosn to JDO standard through the class enhancement + reverse engineering combination (bridge Pattern).

c. Life Cycle Management for JDO applications. Model (java Class) can evolve iteratively and the code generation and mapping can handle the modifications without affecting the existing data and business rules.

d. Caching. A secondary transparent cache for the JDO objects for optimised performance.

e. Distributed and Clustered Caching. JMS based distributed caching solutions for distribted JDO applications.

f. Integration with Leading IDEs. Eclipse (by JavaOne), JBuilder, Forte ...

Developers can pick up full fledged tools like FrontierSuite for JDO and carry on with the same kind of features and support that they can get with 'frontline' technologies like J2EE.

regards
Rajesh
(S Rajesh Babu)

FrontierSuite for JDO - Enterprise scale solution for JDO Applications
www.ObjectFrontier.com

Not true. ODMG is a pre-existing (more powerful) standard.

Unfortunately, the feature that makes ODMG so good, OQL, has semantics which make it problematic for ORM solutions. Nevertheless it is much preferrable to (and much, much more sophisticated than) JDOQL. Actually its not really a fair comparison, since OQL is a full ad hoc query language whereas JDOQL is really just an expression language for filtering Extents. JDO ORM vendors all fall back to SQL for "difficult" queries.

As we will argue in our forthcoming book (SHAMELESS PLUG), it turns out that neither specification really addresses ORM problems particularly well (both were *heavily* influenced by OODBMS vendors). JDO fails to take account of the fact that efficient relational data access is different to data access in an object database. "walking the object graph" is simply not an efficient way to retrieve data from a relational database; it is not how relational technology was intended to be used.

Our book, published by Manning (ABSOLUTELY NO SHAME), will set out some ideas for the future of ORM - of which Hibernate can be considered an imperfect, work-in-progress implementation. We think that ORM has never been taken seriously as a unique problem in its own right. It has usually been treated has an ugly sister of OODMBS. Since the reality is that object database technology is looking deader all the time, its time to rectify this.

Now is the time for *innovation* in object/relational mapping, not for standardization!

Excuse me for sounding grandiose today.... ;)

P.S. Once again, if you disagree, please engage my ideas, not my character. (Its a pity I need to say this!)

Hi Gavin,

Just as a point of info - our product (FrontierSuite for J2SE) supports ODMG OQL for querying data in relational databases.

And we will be providing support for OQL in FrontierSuite for JDO as an extension pretty soon.

And the limitations of the current JDOQL are active points of debate within the JDO community currently, and we are quite confident of having a solution maybe by the next version of the spec.

regards
Rajesh
S Rajesh Babu)

FrontierSuite for JDO - Enterprise Scale solution for JDO applications
www.ObjectFrontier.com

Hi Gavin

"JDO ORM vendors all fall back to SQL for 'difficult' queries"

JDOQL has been designed so that it can be efficiently expressed in SQL and most things you would want to do in SQL can be done in JDOQL. There will be some queries that are best done in SQL but these will typically be a very small part of a project.

I would not want to use a query language in an application on a relational database that was not completely translated to SQL. So the restrictions in JDOQL that make this possible are good IMHO.

"JDO fails to take account of the fact that efficient relational data access is different to data access in an object database. "walking the object graph" is simply not an efficient way to retrieve data from a relational database"

Optimizations to overcome the O/R mismatch are the same for any O/R mapper. They are independent of JDO. JDO Genie does eager fetching with joins and supports multiple fetch groups (access paths) among other features in this bracket.

What JDO does very well is hide most of this from the developer. Its nice to be able to navigate a reference and not have to worry about fetching it. The JDO implementation can prefetch it or cache it to make this efficient.

Cheers
David
JDO Genie - High Performance JDO for JDBC

So, I'll show some Hibernate queries (st8 out of our reference doco) that utilize some features of ANSI SQL, and you'll show me how to express them cleanly in JDOQL.

(1) Aggregation:

select cat.color, sum(cat.weight), count(cat)
    from Cat cat
    group by cat.color
    having cat.color in (eg.Color.TABBY, eg.Color.BLACK)

(2) Multi-column queries (notice the outer join):

select cat, offspr, mate.name
    from eg.DomesticCat as mother
    inner join mother.mate as mate
    left outer join mother.kittens as offspr
    order by cat.name

(3) Subselects:

from eg.Player p where 3 > all elements(p.scores)

from eg.Cat fatcat
where fatcat.weight > ( select avg(cat.weight) from eg.DomesticCat cat )

from eg.Cat cat
where not exists ( from eg.Cat mate where mate.mate = cat )

That'll do for now. I'll give a couple of final examples. They are monsters and, of course, queries like this is rare. Nevertheless, they are similar to ones I have used in a real project:



select account, payment
from Account as account
    join account.holder.users as user
    left outer join account.payments as payment
where :currentUser = user
    and PaymentStatus.UNPAID = isNull(payment.currentStatus.name, PaymentStatus.UNPAID)
order by account.type.sortOrder, account.accountNumber, payment.dueDate



select count(payment), status.name
from Payment as payment
    join payment.currentStatus as status
    join payment.statusChanges as statusChange
where payment.status.name <> PaymentStatus.AWAITING_APPROVAL
    or (
        statusChange.timeStamp = (
            select max(change.timeStamp)
            from PaymentStatusChange change
            where change.payment = payment
        )
        and statusChange.user <> :currentUser
    )
group by status.name, status.sortOrder
order by status.sortOrder


>> There will be some queries that are best done in SQL but these will typically be a very small part of a project. <
In Hibernate, they are best done in HQL ;)

>> Optimizations to overcome the O/R mismatch are the same for any O/R mapper. They are independent of JDO. <
Not true. JDO does not have any API for *runtime* fetching profiles. (In Hibernate, it is integrated in the query language.)


>> What JDO does very well is hide most of this from the developer. Its nice to be able to navigate a reference and not have to worry about fetching it. The JDO implementation can prefetch it or cache it to make this efficient. <
But then how would the JDO implementation know WHEN to fetch eagerly, and when to fetch lazily. This things should be determined at the level of a transaction, not at the level of the mapping.

peace :) I appreciate hearing your views.

Hi Gavin

Once again the same debate :-)
Each time there is a new thread on JDO, we have few people from the "old" (it's a joke Gavin, don't kill me) O/R mapping world entering the debate, like you Gavin or the famous W. M., bashing JDO.
It seems they know everything about RDBMS engines and how to tune systems, and all other people (mostly JDO ones) are dummies on the wrong way.

1. JDO is not limited to O/R mapping, and it is nice for all people that are still not using RDBMS (much more than you think, from mainframes to embedded systems)
2. JDO is defined in the JCP, that is an open process, you can participate if you want
3. People doing JDO implementations for JDBC also have (like you) a good RDBMS background, we don't ignore how to produce optimized statements, complex queries and so on
4. With all the time you spent on bashing JDO, Hibernate could be already JDO compliant, like OJB from Apache is doing :-)
5. ODMG is not really a good example of a successful standard (from the commercial point of view I mean)
6. Do you support the complete ODMG or only OQL ?
7. Do you support complete OQL (with methods in filters) ?
8. OQL was rather a standard related to ODBMS, this is why I find strange to implement it on RDBMS

But the more important is :

From the samples you give it seems you really believe all business logic can be expressed through extremely complex SQL Statements.
You're job is just to access existing RDBMS schemas (no inheritance, no collections...), using Java syntax and complex queries but no business object models at all.

Best Regards, Eric

It is an important debate. Data access is one of the most critical parts of building a web/enterprise app. And I am intensely interested in these issues, obviously.

>> Each time there is a new thread on JDO, we have few people from the "old" (it's a joke Gavin, don't kill me) O/R mapping world entering the debate <
The Hibernate project is barely older than the JDO spec. Most of the code has been written subsequent to the release of JDO. I investigated the spec when it was released, didn't like it (in its current form) and decided to build something better. That something subsequently became one of the most popular projects on sf.net.

>> 1. JDO is not limited to O/R mapping, and it is nice for all people that are still not using RDBMS (much more than you think, from mainframes to embedded systems) <
Thats fine. JDO is great for those people. We are building an ORM for those 99% of Java developers who have to work with a relational database every day. That is quite enough of a problem by itself.

>> With all the time you spent on bashing JDO <
As the leader of the main competing solution, it is my job to evangelize and criticize. If people like me do not point out the faults of the spec then it will

(a) never improve
(b) be adopted in the face of superior alternatives

I am not "bashing" JDO because I want to see it fail. I am "bashing" JDO because I want to see it improved. Please recognize constructive criticism.

>> Hibernate could be already JDO compliant, like OJB from Apache is doing :-) <
Why would we do that, if we are unhappy with the limitations of JDO?? What a bizarre suggestion! Anyway, judging from forum/mailing list activity, we have more users than OJB and Kodo put together, so why exactly would we follow those examples?

>> ODMG is not really a good example of a successful standard (from the commercial point of view I mean) <
Ditto JDO, so far!

>> Do you support the complete ODMG or only OQL ? <
Not quite understanding you. Hibernate has an ODMG-style API and an OQL subset. But we don't claim compliance and anyway nobody uses it. They all use Hibernate API and query language.

>> Do you support complete OQL (with methods in filters) ? <
Of course not! It is kinda nonsensical in an ORM setting. What a strange question.

>> OQL was rather a standard related to ODBMS, this is why I find strange to implement it on RDBMS <
Agreed. It is not really possible to support "correct" OQL semantics. Which is why we have our own dialect, HQL.

>> From the samples you give it seems you really believe all business logic can be expressed through extremely complex SQL Statements.
You're job is just to access existing RDBMS schemas (no inheritance, no collections...), using Java syntax and complex queries but no business object models at all. <
Once again, quite a strange view. I suggest you learn more about Hibernate before commenting further. Also check out the discussions of Hibernate on JavaBlogs.com. Hibernate is EXTREMELY OO. But it also lets you use the rdb for what it is good for (searching, aggregation, etc).

I really like hibernate, but it flaws in documentation..

To make the version beta 2 version working, with no documentation, I spent 8 hours. Searching on google, etc...

In the latest release, the doco is in the

C:\hibernate-2.0\doc\hib_docs\reference\html

directory. Apparently some people had trouble finding it there.

We will put it up on the website when we release 2.0 final.

Eric>>>>>>So am I :-)


We are building an ORM for those 99% of Java developers who have to work with a relational database every day. That is quite enough of a problem by itself.

Eric>>>>>>>>Less than 50% of data are stored in RDBMS today. That's why O/R mapping is nice but not enough, and that's why JDO is so important.


> >> With all the time you spent on bashing JDO <>
> As the leader of the main competing solution, it is my job to evangelize and criticize. If people like me do not point out the faults of the spec then it will
>
> (a) never improve
> (b) be adopted in the face of superior alternatives
>
> I am not "bashing" JDO because I want to see it fail. I am "bashing" JDO because I want to see it improved. Please recognize constructive criticism.


Eric>>>>>>>>>Criticisms are always welcome (when not in the W. M. style).
But I'm sure your "contribution" would be even more efficient if you could participate in the JDO Expert Group.


> >> From the samples you give it seems you really believe all business logic can be expressed through extremely complex SQL Statements.
> You're job is just to access existing RDBMS schemas (no inheritance, no collections...), using Java syntax and complex queries but no business object models at all. <>
> Once again, quite a strange view. I suggest you learn more about Hibernate before commenting further.

Eric>>>>>>>>I visit your site quite often, and have your releases installed on my box.
For instance, I recently discovered you use the same support platform system as us (JIRA). I have more than 35 O/R mapping tools installed on my machine including commercial and open source, JDO or not. I regularly inspect the source code and documentation of most of them (sometimes using JAD :-).
I also browse all these related public forums as it gives a good picture of what the market really wants.

Alternately, I can say YOU never downloaded our product :-)




Also check out the discussions of Hibernate on JavaBlogs.com. Hibernate is EXTREMELY OO.

Eric>>>>>>To me this is nothing more than an opinion.
For instance, on your site you speak about Smalltalk, but I'm not sure you really THINK object.
BTW, I've seen you'll be in JAOO in September, so we'll have the opportunity to discuss this with a beer (no free beer/speech in the real world :-)


Best Regards, Eric.

Eric>>>I completely agree with you here, and I don't see anything in JDO that prevents you from doing like this. The fact it is not defined in the standard does not prevent you from supporting this kind of features.

Best Regards, Eric.

There are certainly two dominant POVs in this conversation. One is, how can I maximize the percentage of things I can do with SQL through an OO implementation (Hibernate) and the other is, how can I maximize what I can do with an OO standard (JDO) and map it through to (among other things) SQL. I can't see how JDO is a negative, even if it fails to do some of the things that Hibernate does. If it were all things to all people, it would suck like every other standard that tried to be all things to all people. I can definitely see, though, that 90% of "new" apps (i.e. non-integrations) could fairly easily take advantage of JDO, and building on an open standard is traditionally viewed as a much safer route for a corporate development team than building on a product. OTOH, having Hibernate being an open source project with a number of products already using it will mitigate most "product lock-in" concerns that companies will have. I can't imagine how the end result is anything but a win for customers: some JDO "standards-based" products (and I've seen first-hand the ability to interchange implementations) and other excellent choices (OJB, Hibernate, ...) also available.

BTW - JDO is definitely not limited to O/R mapping. The O/R mapping market is very competitive and very crowded, so the most lucrative areas for JDO are in the legacy integration connectors that it can support. In that respect, I think you can see why OQL and SQL can't be fully supported. If you didn't notice, I'm a big proponent of JDO, not because I think it's perfect, but because I think it's pretty valuable to have a standard that addresses a relatively large class of problems in a fairly elegant way.

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Easily share live data across a cluster!

This is a great point. The JDO specification is flexible enough to allow you to store data just about anywhere. This has a number of implications:

- First, and most obviously, data can be stored in a non-relational back-end. Aah, but everyone already uses relational databases, so who cares? Well, everyone does use relational databases, but many people use other systems as well, often in concert with a relational database. For example, employee information might be stored in an LDAP system. Or financial data might be accessed through an SAP implementation. Or an insurance company might store some information in a 25-year-old mainframe. Now, there's no reason why your business code needs to know where the Person class is stored -- all your business code cares about is that it can store instances of the Person class *somewhere*. Enter JDO. By abstracting the business code away from these types of concerns, you retain the flexibility to make deploy-time decisions at, well, deploy time. This is obviously a boon -- an architecture that lets you delay decisions until they have to be made rather than forcing your hand early on is a good thing.

- To follow on from the last point, your data might be stored in a mix of different back-ends. You might store user data in a relational database, and financial data elsewhere. There is nothing preventing a JDO implementation from supporting such a hybrid system.

- More subtle, but much more powerful than the above two points: the JDO spec does not make dictate the runtime architecture of a JDO system. So, if you need a highly scalable, highly performant system (a system that achieves "scalable performance", to steal a phrase from Cameron's lexicon), you might look for a JDO implementation whose architecture looks quite different than a straight two-tier JDO-talking-to-database picture. For example, Kodo can be deployed alongside Tangosol's clustered caching product (Coherence) to provide some quite advanced distributed data access capabilities.

Currently, most of the JDO implementations on the market are targeted at either relational databases or object databases (or both). There are, however, implementations in the works for other less standard back-ends (contact me directly for details -- there are a handful of such projects in varying degrees of public availability underway at SolarMetric, and I know of a couple of other companies working on JDO bindings for their data frameworks). Over the next several months, more and more alternative back-ends will have JDO support, and more and more advanced JDO architectures tuned for particular needs (offline systems for embedded data, multi-tier highly scalable solutions, products targeted at legacy data systems, ...) will start hitting the market. With such products available, it will be possible to migrate your deployment architecture as your business requirements dictate -- maybe you start with a simple two-tiered deployment, but then need to move to a more scalable architecture as your service becomes massively popular. Because JDO does not impose deployment limitations on your application design, you can make these types of changes without re-coding your application.

-Patrick

--
Patrick Linskey
SolarMetric Inc.

Hi Gavin

"(1) Aggregation"

Yes the current JDOQL will not do this. However I would argue that most projects will only need this in reports and SQL is the best language for that. Often these will be written with some external non-Java tool anyway (Crystal or SQR or whatever).

"(2) Multi-column queries (notice the outer join)"

This can be done in JDOQL by just querying against cat and specifying the ordering on name. You can get to the other fields by navigation. JDO Genie supports extra fetch groups to get only what is required and to do it in one query if possible (prefetching).

"(3) Subselects"

The "not exists" one can be done using a JDOQL variable. The others use aggregation and cannot be done in JDOQL. The monsters also not. However again I believe those are best done with SQL anyway. Use SQL for the mean data aggregation stuff and JDOQL for the 99% of the rest of the project.

Interestingly I doubt if the queries you have listed will run on that many databases. MySQL 4.0 does not have subselects. Informix requires that the columns used in the order by appear in the select list. Oracle BLOBs are completely horrible. JDO Genie will handle all of these nasties when translating JDOQL into SQL. It will generate very different queries on MySQL and Sybase for example.

These are important things gained from working at a slightly higher level of abstraction (JDOQL vs SQL and transparent persistence vs lower level O/R APIs).

">> Optimizations to overcome the O/R mismatch are the same for any O/R mapper. They are independent of JDO. <Not true. JDO does not have any API for *runtime* fetching profiles. (In Hibernate, it is integrated in the query language.)"
"But then how would the JDO implementation know WHEN to fetch eagerly, and when to fetch lazily. This things should be determined at the level of a transaction, not at the level of the mapping."

JDO Genie supports this. You can specify the fetch group to use when executing a query at runtime. However on real world projects this feature is rarely needed.

Cheers
David
JDO Genie - High Performance JDO for JDBC

I have already submitted one proposal for Aggregation ans Projection support in JDOQL to my colleagues in the Expert Group. Not much has been done on that, what with the finalization of JDO 1.0.1. However JDO 1.0.1 is approved now, and as soon as my Bunsiess Case for JDO breakfast seminar is over I'll be pushing for some prototype work on JDOQL Aggregation / Projection to make sure these for a central part of the next JDO release.

Remember that JDOQL is an object query language. We will do as much as we can to support query constructs that map well onto an Object Persistence topology. However we're very unlikely to sacrifice JDOQL's clean OO focus in order to "match" SQL. As others on this list have pointed out, sometimes the native Query language of your underlying datastore is the most appropriate tool.

On another point, I know some relational vendors allow you to invoke stored procedures through the JDO Query interface. That might be of interest to some of you.

Gavin, I've enjoyed reading your posts. I know that JDO is not Hibernate, and Hibernate is not JDO. Again people will choose the appropriate tool for their task, and it is up to the rest of use to keep them well informed about their choices! I hope that JDO will evolve (quickly) to encompass some of the more advanced runtime features of Hibernate. I know vendors are actively working on extensions to support per-transaction fetch patterns, etc., and in due course we will standardize features such as these.

Kind regards, Robin.

[ If you're in London on Friday 09 May I hope to see you at Business Case for JDO ]

Cool, I'm pleased to hear that some of these issues are being addressed. I'm VERY interested to see if it is possible to simultaneously satisfy the requirements of

(1) the level of abstraction of JDO (independence from datastore technology)
(2) the ability to take advantage of more relationally-oriented functionality like aggregation, etc

They seem to be somewhat opposing requirements and I'm sceptical, but time will tell.

Note that my main reason for insisting that (2) is needed is simply that thats what our users have begged for, at every stage. I am often wary of the output of "expert" groups, because the feedback mechanism is fundamentally broken. It is difficult for these kinds of groups to take the input of users seriously. What happens is that outside criticism is usually met with hostility by the spec authors/boosters. By contrast, open source projects like ours simply can't help addressing the needs of our users. Anyway, thats a tangent....

Its an interesting discussion. I will be at TSS symposium (and JAOO) if anyone wants to discuss these things offline.

peace....

I agree that Aggregation is needed. However it's not a show-stopper for many potential users of JDO.

I'll also be at JAOO - I'm presenting on JDO (naturally) and also on Collaboration Patterns (as per Streamlined Object Modelling). See you there, Gavin!

Gavin,

The need for aggregation is a real one for JDOQL, and I would be very surprised if we didn't get that support into JDO 2.

However, the need for selecting particular tuples of data in a query (rather than entire objects) is less real -- this is more of a perception thing than anything else. Specifying that you want to select the first name and last name from all Person objects in a database is just not that important, what with JDO's ability to tune fetch groups (and most implementations' abilities to configure custom fetch groups -- another feature slated for an upcoming JDO spec revision). Since querying for a Person object does not necessarily result in all the data being materialized up-front, there is relatively minimal value to specifying a tuple at the query level rather than just only accessing those fields that you care about.

That said, clearly, there is something of a need for supporting this type of behavior from a marketing standpoint.

Additionally, note that an important distinction to make when comparing things like JDO (a specification) to things like Hibernate (a product) is that you're comparing apples to oranges. A more appropriate comparison would be a JDO implementation (I'd suggest Kodo, but I'm probably biased in some ways there...) to Hibernate, as that's a product-to-product comparison.

Finally, congrats on the book deal with Manning.


-Patrick

Does Kodo JDO support FirebirdSQL (http://www.firebirdsql.org) ?

While we don't officially support it, IIRC a number of our customers use it. Kodo can adapt to most any JDBC 2 compliant driver/db with a simple DBDictionary plugin.

Steve Kim
SolarMetric, Inc.
http://www.solarmetric.com