[dna-dev] Re: JBoss DNA 0.4 planning
Randall Hauch
rhauch at redhat.com
Sun Nov 16 12:24:48 EST 2008
On Nov 16, 2008, at 4:25 AM, Sergey Litsenko wrote:
> Regarding JDBC metadata.
> ...
> 1) I'll review new chapter "how to write custom connectors"and use
> the dna-connector-svn as a reference to implement the dna-connector-
> jdbc in extensions. It will accept two configuration styles to
> specify JDBC configuration - javax.sql.DataSource and more generic
> java.sql.Driver (connection URL, username/password, etc).
Maybe this would help or give you some ideas: this weekend I've
created a prototype connector that uses Hibernate for persistent
storage. (Not quite ready for committing to SVN, but should be this
week). The RepositorySource implementation just has JavaBean
properties for the regular connection properties for Driver-based
connection, and another JavaBean property for the JNDI name of the
DataSource. The RepositorySource has a transient Hibernate
Ejb3Configuration, which it creates lazily (and stores as a transient
attribute) before creating a RepositoryConnection. The
Ejb3Configuration is created programmatically, so the Driver
properties are set as properties, but the DataSource has to be set as
a reference. (Yeah, the JNDI name could be set as a Ejb3Configuration
property, but in order to support the XAResource, I need to get the
DataSource object in the RepositorySource, which holds onto it via a
transient attribute. This works with Hibernate, since the config also
has a setDataSource(DataSource) method. Oh, and to make testing
easier (by eliminating requirement for JNDI), I also added a package-
level setter for a DataSource object, which sets the transient
attribute value. Let me know if you want to see code.
> 2) create dna-sequencer-jdbc-metadata subproject in extensions that
> will implement an interface similar to
> org.jboss.dna.graph.sequencers.StreamSequencer except for the
> “stream” input parameter because it is irrelevant for JDBC based
> conversations:
>
> package org.jboss.dna.graph.sequencers;
>
> public interface JdbcSequencer {
> void sequence(java.sql.Connection jdbcConnection,
> SequencerOutput output,
> SequencerContext context);
> }
>
> The main purpose – is to make it generic enough to allow
> implementing different JDBC sequencers.
> How it sounds?
>
> Basically, what I need to do is to port my DatabaseMetadata
> Extractor (I did it few years ago, and tested against Oracle9i, MS
> SQL Server 2005, and MySQL) into org.jboss.dna space. The extractor
> as whole package is a bit too heavy to just simply copy it – it is
> relying on several Apache\Jacarta libraries (notably on Jacarta
> commons Chain (Chain of Responsibility" pattern) + generates JDBC
> drivers comparison reports in XML and HTML. So, I’m trying to
> refactor it in the same time.
Okay, I think I see what you're trying to do. Very interesting idea.
This would all be in the connector, then? And the connector would
essentially cache the metadata graph extracted from the database
metadata, so it could respond to the different ReadNodeRequest (or
other requests) coming into the connector? (If I don't have this
right, please let me know.) Also, if you're refactoring the
extractor, would it be possible for the extractor to be used directly
the connector to obtain only part of the metadata?
BTW, the musings I've had in the past about this connector is that it
might use Hibernate (to automatically get support for the many
database management systems that Hibernate already supports; see http://www.hibernate.org/80.html)
. Hibernate Tool's DatabaseMetadata class works on top of the many
dialects that Hibernate has (http://www.hibernate.org/hib_docs/v3/api/org/hibernate/tool/hbm2ddl/DatabaseMetadata.html
). Again, not sure if this would even work or provide everything we'd
want. For example, it may not provide much (if any) of the database-
specific metadata.
>
> Regarding REST mapping. My intention was to just describe “prior
> art” for reference purposes only – let others to they work - while
> it sounds like Jerome K. Jerome’s famous quote about his addiction
> to work ;) - we may save more time on analysis of possible REST
> mapping strategies.
>
> My point is simple (and btw, it didn’t changed for years) – “program
> to interfaces”, likely standards based and setup transparent links
> (inject, configure, etc) to open source software implementations
> (preferably) of those interfaces where appropriate and possible.
>
> I’m completely agree with your comments on that, and even more –
> inspired by your feeling towards choosing right balance between
> writing own code and reusing available libraries and frameworks I
> decided to spend some time analysing possible choices and wrote a
> wiki page about prospective ways to integrate/implement various
> JBoss DNA components in the future. Basically its small review of
> technologies available in OSScommunity (especially in JBOSS
> community) that might be related to JBoss DNA concept and might be
> reused in its implementation – have a look at it here https://www.jboss.org/community/docs/DOC-12952
> – your comments are greatly appreciated. The main purpose of that
> review was to make the DNA implementation technology(s) /
> framework(s) choices broader and to address time to market
> requirement (while I love those frameworks and JEE in particular - I
> don’t want to push it too hard). The bottom line is that one of the
> main JBoss DNA/JCR and JBoss DNA/Web purposes shall be to simplify
> metadata management things, not to complicate them – from client
> prospective. Plus (I guess) serve as JBoss technology stack show
> case (to some reasonable degree).
>
> So, basically we will stick with JCR API for traversal, search,
> update nodes and map it onto URL, right?
>
> The beauty of JCR API is that we don’t need to wait till our JCR
> implementation will be ready to integrate with other frameworks or
> services. As long as all components will rely strictly on JCR API
> interfaces and access it through standard way (e.g. JNDI lookup,
> dependency injection, etc) – we can easily use JackRabbit embedded
> in a meantime, and then substitute it with our JCR implementation
> when it became ready. We would need to address performance
> limitations of JackRabbit in our implementation of JCR API – in
> order to make it better (since it mean to be enterprise wide
> repository – e.g. thousands of nodes, subnodes, properties).
Yes, that is an entirely valid, and maybe preferred approach. Yes, we
could start working on the REST service today. But a disadvantage is
that we couldn't use the REST API on top of DNA repositories until our
JCR API was finished (or at least those parts that the REST service
would use).
Also, it doesn't seem like the REST service would use much of the JCR
API. (Yes, this may make it easier to get our JCR implementation
complete enough to put the REST service on top of DNA repositories.)
But are we making it more complicated than it needs to be? What if we
put the REST service on top of the Graph API (new to 0.3), which
operates on top of a connector. This is essentially all that our JCR
implementation is doing. The Graph API can read and write today, and
it basically just consists of nodes with properties and children. And
my intuition (nothing more than that!) is that the REST mapping to JCR
would also map similarly/identically to the Graph API. The benefit is
that this would be more efficient, since the extra JCR layer is
eliminated.
I'm not sure what my preference would be. Both have advantages and
disadvantages. But maybe we could consider both before we decide.
Anyone have thoughts here?
>
> I have the same opinion like you that RESTful service in not the
> equal to web app UI. We need separate JIRA ticket(s) for Web UI
> app, each panned/proposed WS (e.g. REST-based API for remote access
> and usage).
>
> Also, we would need to clarify deployment scenarios of JBoss DNA
> stack in detail (like JackRabbit’s team did) – also highlighted on
> my wiki page.
>
>
> Regarding Web application UI. I’m not against Flex as one of
> possible UI rendering but I’m just not sold on the fact that Flex is
> the first or preferable choice for DNA UI. Reasons explained in more
> detail on the same wiki page – but basically it is all about
> infrastructure and technology/feature enablers that btw already part
> of JBoss stack. For instance, thin and rich JSF framework like
> RichFaces that nicely integrates with JBoss Seam as a web
> infrastructural component might implement all required UI
> functionality. It is easy to use, understand how it works (both
> projects have comprehensive documentation) + my past experience with
> both frameworks might help in setting up quickly web infrastructure
> for JBoss DNA web.
I would agree that it's very important for other technologies (like
Seam, RichFaces, GWT, even plain-old JSPs) to use JBoss DNA, because
people writing web applications should be able to use JBoss DNA.
However, I believe that we also need to provide an out-of-the-box
ready-to-use metadata management repository web application, and that
this will likely need to be offer rich interaction model (maybe even
allowing graphical navigation). But perhaps the most critical need is
for the application to over ways of customizing and extending how it
views information, by not changing the application but by adding/
changing data. This is content-driven, and not many frameworks make
this possible. For example, GWT does not, since everything must be
coded in Java and then compiled into the application. FLEX can be
driven entirely from data. Could Seam and Rich Faces be used this way?
>
>
> Best regards,
> Sergiy
>
> From: Randall Hauch <rhauch at redhat.com>
> To: Sergey Litsenko <litsenko_sergey at yahoo.com>; JBoss DNA <dna-dev at lists.jboss.org
> >
> Sent: Tuesday, 11 November, 2008 2:57:38 AM
> Subject: Re: [dna-dev] Re: JBoss DNA 0.4 planning
>
> Excellent! Can't wait to see what you have. You're right that we
> could code to JSR 311 and use any valid implementation, but I have
> no problem relying upon RESTeasy, since we could leverage new
> features (e.g., http://bill.burkecentral.com/2008/11/10/jax-rs-atom-support-with-resteasy/)
> , and since the RESTful service would certainly be packaged to run
> in a servlet container and thus shouldn't have any problems with
> clashes in dependencies. Plus, RESTeasy is another JBoss technology.
>
> I'm wondering if you meant to say a JDBC Metadata
> "connector" (rather than "sequencer"). If you did mean "sequencer",
> I'd be interested in hearing about how that might work (what might
> be sequenced so the sequencer knows how to establish the connection
> and retrieve the metadata).
>
> Now, regarding a REST mapping. I've looked at Sling (which has
> other features besides just a REST service), and based upon the
> documentation (which may very well be out of date), the client
> specifies the content type in the URL - that's not very appealing.
> I would much rather see standard content negotiation via the
> standard accept header. Now, the other two examples don't always
> look very RESTful (or at least "resource oriented"). For example,
> Alfresco's REST API's login method (http://wiki.alfresco.com/wiki/Repository_RESTful_API_Reference#Login
> ) uses GET even though it's not idempotent. POST would seem to be
> better here. I would love to see a more detailed discussion on the
> REST mapping. Perhaps you could start off with what you've used in
> your prototype?
>
> Another important topic is this: will we want to build a content-
> driven application framework or will we want to use Sling or
> Alfresco's WebScripts (or other)? Some advantages of reusing an
> existing system are:
> more functionality out of the box (i.e., we're not 1+ years behind)
> reuse existing technology
> leveraging existing community and possibly expand DNA community via
> participation in the other community
> There are probably others, too. Some disadvantages are:
> must choose a technology
> must live with their interface and design
> little or no value-add over the existing technology
> our JCR support must be close-to-complete before we can do this
>
> I'm a bit conflicted: I think we could do better, but just because
> we can doesn't mean we should. There's something to be said about
> focusing on what makes DNA unique and advantageous (primarily
> federation and sequencing), and just using Sling or Alfresco to
> build out some great useable applications. In fact, I think that a
> really usable and really useful content-driven rich internet
> application (perhaps using Flex) is another potential focus area for
> DNA.
>
> So, as long as as have a correct and complete (enough) JCR
> implementation, then we (or anyone else) should be able to use DNA
> in combination with Sling and/or Alfresco. We may even win over the
> Alfresco community, if DNA's repository implementation is better
> than Jackrabbit. (Jackrabbit does a lot of things well, but there
> are some things it doesn't do well. All we need to do is be better
> at how Alfresco uses JCR.)
>
> Now, having said that, I think that a RESTful service is not the
> same as a content-driven application framework. I think DNA should
> offer a lightweight, full-functioning RESTful service that doesn't
> depend on the larger content-driven applications. After all, I
> think many embedded use cases will simply want a deployable RESTful
> service so that client apps can work with a remote (federated)
> repository. And I think we can achieve this with very little code
> using RESTeasy (or maybe even other JSR-311 implementations). So we
> definitely need to do this.
>
>
> Best regards,
>
> Randall
>
> On Nov 10, 2008, at 6:04 AM, Sergey Litsenko wrote:
>
>> Hi All,
>> I've already started working on (not yet in SVN - will wait till
>> 0.3 release):
>> 1) JDBC Metadata sequencer (POJO model is ready, working on
>> extraction of metadata)
>> 2) JAX-RS prototype.
>> IMO, we would need to start working on REST mapping for JCR
>> resources. Basicaly, any implementation of http://jcp.org/en/jsr/summary?id=311
>> may be used as a core of the REST-JCR integration (RestEasy?)
>> There are at least few available implementations exists that we
>> may review:
>> 1) Sling project http://incubator.apache.org/sling/site/resources.html#Resources-JCRbasedResources)
>> 2) Alfresco REST API for JCR at http://wiki.alfresco.com/wiki/HTTP_API#Alfresco_RESTful_API_Reference
>> 3) Alfresco Content Management Interoperability Services (CMIS)
>> API http://wiki.alfresco.com/wiki/CMIS_Web_Scripts_Reference
>>
>> It would be nice to see as one of future features of DNA auto-
>> discovery (zeroconf) of some resources as well as DNA repository
>> self advertizing (for example - http://activemq.apache.org/zeroconf.html)
>> .
>>
>> Best regards,
>> Sergiy
>> From: "dna-dev-request at lists.jboss.org" <dna-dev-request at lists.jboss.org
>> >
>> To: dna-dev at lists.jboss.org
>> Sent: Thursday, 6 November, 2008 4:00:27 AM
>> Subject: dna-dev Digest, Vol 8, Issue 3
>>
>> Send dna-dev mailing list submissions to
>> dna-dev at lists.jboss.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> https://lists.jboss.org/mailman/listinfo/dna-dev
>> or, via email, send a message with subject or body 'help' to
>> dna-dev-request at lists.jboss.org
>>
>> You can reach the person managing the list at
>> dna-dev-owner at lists.jboss.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of dna-dev digest..."
>>
>>
>> Today's Topics:
>>
>> 1. Preparing for the 0.3 release (Randall Hauch)
>> 2. JBoss DNA 0.4 planning (Randall Hauch)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Tue, 4 Nov 2008 12:18:59 -0600
>> From: Randall Hauch <rhauch at redhat.com>
>> Subject: [dna-dev] Preparing for the 0.3 release
>> To: JBoss DNA <dna-dev at lists.jboss.org>
>> Message-ID: <92A505A6-0D05-47BF-813B-438181005D27 at redhat.com>
>> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>>
>> We're down to just a handful of outstanding issues targeted to 0.3,
>> and all of the big fish issues were completed. I'll be working my
>> two
>> issues over the next few days, but I should be ready for releasing as
>> early as this week. Serge has the other outstanding issues, which
>> are
>> all regarding the SVN connector. Serge, where do we stand on this?
>> Do you want more time to get some functionality finished, or is the
>> connector fairly close?
>>
>> Anybody else have anything to discuss?
>>
>> Best regards,
>>
>> Randall
>>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Tue, 4 Nov 2008 12:37:05 -0600
>> From: Randall Hauch <rhauch at redhat.com>
>> Subject: [dna-dev] JBoss DNA 0.4 planning
>> To: JBoss DNA <dna-dev at lists.jboss.org>
>> Message-ID: <9643F3D3-5E3F-4219-A492-6BC1F6196C73 at redhat.com>
>> Content-Type: text/plain; charset="us-ascii"
>>
>> Now that 0.3 is almost out the door, I'd like to start discussing the
>> goals for the next release.
>>
>> I'd love to see the JCR implementation take more shape. Right now
>> it's read-only, so getting that much farther along would be
>> outstanding. Anybody interested? I think we could easily put
>> several
>> people to work here. The graph API is pretty good, and should make
>> implementing JCR relatively straightforward. Any interest, Michael
>> Trezzi and Alexandre and Serge?
>> We need to add events to the connector framework. That should be
>> pretty straightforward. Also versioning, which will require a bit
>> more work. Plus, there are a couple of connectors that we may want
>> to
>> start working on. This is something I'd be happy to continue with.
>> Serge P. also has expressed interest in working on some connectors
>> (in
>> fact his SVN connector is coming along great!).
>> The CND sequencer could use some love and attention. Dan was stuck
>> in
>> some ANLTR hell, and got pulled off onto a different project. Since
>> it uses ANTLR, maybe you might be interested in it, Alexandre?
>> We also have a need to start working on a REST/WebDAV layer that
>> allows other client apps to access a DNA repository. There's a
>> couple
>> of things we can do, including looking at Apache Sling, or using
>> RESTeasy for a more simple implementation, or something else. Sergiy
>> and John both expressed interest in this.
>>
>> Anything else?
>>
>> We can either tackle several things at once and move them all
>> incrementally, or we can do more in just a few areas. Ideally, we're
>> looking at a 4-5 week cycle (finishing before the year-end holidays.)
>> A lot will depend on how much effort people might be able to dedicate
>> to the project.
>>
>> Please respond with your thoughts and comments!
>>
>> Best regards,
>>
>> Randall
>>
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: http://lists.jboss.org/pipermail/dna-dev/attachments/20081104/90ff822f/attachment-0001.html
>>
>> ------------------------------
>>
>> _______________________________________________
>> dna-dev mailing list
>> dna-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/dna-dev
>>
>>
>> End of dna-dev Digest, Vol 8, Issue 3
>> *************************************
>>
>> Search 1000's of available singles in your area at the new Yahoo!7
>> Dating. Get Started.
>> _______________________________________________
>> dna-dev mailing list
>> dna-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/dna-dev
>
>
> Make the switch to the world's best email. Get Yahoo!7 Mail.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/dna-dev/attachments/20081116/e139a8da/attachment.html
More information about the dna-dev
mailing list