I believe that this JSR is trying to over simplify the needs of a CMS API. Maybe similar to other vendor specific JSR's like JSR 143 and its oversimplification of write once run everywhere fully manageable fat clients. There is a lot more to a good CMS vendor's API than just versioning and locking checks. An API really needs the vendors value offering incorporated into its own API; because we all know each product has different value propositions. However, perhaps more important is the real value to us the users and implementers of these CMS's. I would purpose a more finely tuned requirement for a CMS JSR.
What I would like to see out of a CMS JSR is a nice clean java API that interfaces with any type of content repository. This API should allow users access to production available content. Both, Weblogic and Websphere have this concept built into their personalization API's, I am more familiar with Weblogic's. Weblogic has a document service providers interface, the "Document manager." This API allows me, a weblogic developer, to request content from a content repository, through a vendor neutral interface and vendor neutral query language. Many of the vendors, IWOV, Fatwire, Documentum, Stellant, etc... have built a "Document manager" for BEA's personalization product. Now what I believe would be nice is if, on the coat tails of JSR 168's success, the vendors could produce one driver, i.e. similar to JDBC, to interact with production capable content from their blackbox content repositories (regardless of the products native language). In essence, providing developers with the ability to create a write one query to execute against any type of content repository. This interface shouldn't just be limited to CMS vendors but also other software markets as well, such as querying into ecommerce product catalogs and trouble ticketing systems knowledge bases.
The subsequent architecture to this JSR would be the framework to "plug" these drivers together so that developers could execute one query and receive a consolidated result set from all content repositories. In essance creating the holy grail of an enterprise content bridge. I think that this would provide much value back to all of our customers and not just Communiqué's customers.
Posted by twissink at November 21, 2003 08:55 AMhi travis,
thank you for your interest in jsr-170, let me quickly try to comment on some of your thoughts:
> What I would like to see out of a CMS JSR is
> a nice clean java API that interfaces with
> any type of content repository. This API
> should allow users access to production
> available content. Both, Weblogic and
> Websphere have this concept built into
> their personalization API's ...
agreed... jsr-170 is exactly the mechanism
to harmonize these, since currently they are entirely different...
this is of course one of the important reasons why BEA & IBM and other portal vendors are part of the expert group and are strong supporters
of jsr-170.
> ... the vendors could produce one driver,
> i.e. similar to JDBC, to interact with
> production capable content from their
> blackbox content repositories.
you got it.
> The subsequent architecture to this JSR
> would be the framework to "plug" these
> drivers together so that developers
> could execute one query and receive
> a consolidated result set from all
> content repositories. In essance creating
> the holy grail of an enterprise content
> bridge.
there is most certainly a lot of value in the virtual repository approach that you describe in the above statement, jsr-170 aims exactly to be the basis for that.
so one of our guiding principals of jsr-170 is to improve the operability between all the different repository vendors to allow the developer to work with one homogenous api for all the content repositories.
> I think that this would provide
> much value back to all of our customers
> and not just Communiqué's customers.
i think i lost you on that one?
jsr-170 improves interoperability and avoids vendor lock-in in the future and has very little to do with day software's product communique other than day software as the spec lead and initial creator of jsr-170 obviously is very committed to support jsr-170.
i am looking forward to your technical feedback during public review,
regards,
david
I recently sent this to the jsr 170 group during the public review stage.
Dear JSR-170 expert group,
I wish I had more time to get into more of the details but I don’t. Here are three topics of concern.
1) Seems that JSR 147 has many duplicate functionalities that are in this spec. Is there anyway to consolidate efforts so that there aren’t too much wasted resources on similar API's. Or is JSR 147 dead, I don’t know.
2) It almost scares me to see how some vendors will produce their JSR 170 compliant API’s. I have been in the CMS space for a little bit and I have faith that the marketing hype will be better than the implementation. I can see many areas for performance related problems. Is their any way to build performance enhancements into the specification? There are over 900 “CMS” products on the market with many having or wanting JAVA API’s. I would hate to have many good products go bad because they didn’t understand the initial impact of creating an API like this. Additionally, I am primarily concerned with adding fuel to the java performance argument by having a highly visible spec perform badly due to vendor incompetence.
3) The API node tree hierarchy is conceptually similar to some of the DOM API’s. I think that to assist developers, and the ever-growing number of API’s that we are supposed to know, that JSR 170 could use the same API references as the DOM even maybe implement a SAX Parser to run against the repository. So in essence turning each VCR into an XML document. I think that there are some pungent benefits there if you think about it.
Sincerely,