On 8 Feb 2004, at 07:31, Daniel Florey wrote:
It is, in fact, the API dual of the entire WebDAV protocol stack on the
server side.
This sounds good. It would be best, if they would somethimes have a real 1:1
relation. But as far as I know today there are some things needs
consolidation.
There is a great deal of functional overlap between WebDAV and JCR. But there is at least one big difference.
Let me explain: a contract is what separates two concern islands in order to formalize SoC (separation of concerns)
[island] ---(contract)--- [island]
this contract can be anything (the shape of the electric plug, a protocol, a practice, an API). In short, a contract is what both sides take for granted and allow them to interoperate.
A solid contract allow things separation and isolation, therefore parallelization and polymorphism.
Now, this said, in client/server architectures, this contracts are directional and identify the client concern and the server one (there are few bidirectional contracts, but that's rare even if becoming more popular with p2p systems)
WebDAV, just like HTTP, is a contract with a very precise orientation: a server implements WebDAV and a client calls it. But, this tends to implicitly indicate that there will be far more clients than servers.
The Servlet API, on the other hand, (or any other module API for a web server) started as a way to allow people to write their own modules. In this regard, the few2many relationship is reversed: there will be much more modules (servlets) than clients (containers).
So, the picture for http/servlets is
client -(http)-> server -(servlet API)-> servlets [many] [few] [many]
[this was the basic of the 'application server' concept that is now obsolete as a marketing term]
What is the picture for webdav/JCR? well, let's see:
client -(webdav)-> server -(JCR)-> repository [many] [few] [few]
As you see, there is a difference and this is also *the* single worst architectural weak point of the Servlet API: it's too granular!
More and more the Servlet API evolved to reduce the granularity and more and more packaging into the API (the WAR concept, for example) and today almost nobody writes servlets by hand but uses a framework.
So, the granularity fo the API was fixed with framework
client -(http)-> server -(servlet API)-> servlets -(framework)-> webapp [many] [few] [many] [few]
so that can be collapsed, from the webapp point of view in
client -(http)-> server -(framework)-> webapp [many] [few] [few]
Cocoon, Struts, Turbine, Tapestry are all very different examples of the same architectural de-granularization.
So, instead of having a ton of various JCR repositories and have the container handle the mapping and routing of information (in a nonstandard therefore inconsistent way!), JCR is *already* a framework for you to plug in your different nodetypes (which are the JCR closest equivalent to slide stores)
One note here: the spec originally included a way to make those nodetypes portable across containers. This was removed because it would have add too much complexity to the spec at this stage and we weren't sure on how the people would have used the API, but we will probably add it later down the road if it makes sense.
What about typed properties in webdav?
what do you mean?
What about events/observation?
Observability is an optional property of a JCR repository. Unfortunately, I must say. But some vendors can't provide that functionality. [you have to make compromises in those groups]
Transactions?
yep
As I posted in another thread I found some information on webdav-extendsions
that would fill this gap (have a look at exchange 2000 sdk). Isn't MS member
of wedav.org?
webdav.org is Greg Stein's own web site and has no official affiliation with the WebDAV working groups at IETF. Yes, Microsoft was a big part of the IETF working groups. [that's how they were supposed to screw open source by making the protocols incredibly complex, read the helloween documents, too bad that Greg implemented mod_dav in two weeks and that forced them to shoot a little higher and that's how SOAP got in the picture]
These items in the hierarchy can be really anything. They can make JDBC
connections to a database, IIOP connections to a satellite system and
grab the latest weather image, talk to CVS, of your file system, or
LDAP server, or XML database, you name it.
The idea is that vendors will standardize on this API to split their software offers in two: the presentation layer and the data layer.
Don't get me wrong, this won't replace RBDMS for the data that is purely relational or for things like EJB or other object-relational mappers, but for all sort of semi-structured data, we hope that JCR will find a nice place.
The big thing that we are still discussing is what query language to use. One of the suggestions is to use DASL basicquery for now and see what happens out of XQuery, since we'll provide a transparent XML view of the item hierarchy that you would be able to query on very granularely.
As the discussions in slide-dev showed, it is really a sophisticated task to
find a good solution for queries.
yep
I think it is a way to go to provide one simple basic search (to allow
standard search over different repositories) plus repository/index specific
search.
we are converging toward that as well.
Anyway, we should be out in public review very soon now and I expect
this to come up during the public review period, so I'll let you all
know when that happens so that you can give us feedback where you think
we are doing something wrong
Believe me, the group is very nice and we are really open to suggestions.
If so I see the benefit for such an api.
Good
We could enable access to all of this repositories with just building one jsr170-store. But maybe I got it wrong again...
I would think that Slide should become *the* JCR implementation, much like Tomcat is for the Servlet API. So, what tomcat does for the web, Slide would do for WebDAV and JCR.
This my hope and lots of folks in the expert group would love to see that happening, because that would create a market for more fancy solutions.
Is jsr170 more a set of interfaces or does it implement some logic as well (e.g. mounting of different stores, configuration)
It's mostly a contract, so it's a set of interfaces, classes and it includes a hierarchy of nodetypes that all containers are supposed to have (this gives some solidity to the searchability of the data model)
If I want to have a mixed repository (user=LDAP, some files=Filesystem, some
other files=DB etc) can this be achieved by nodetypes that are mapped to
different vendor implementations?
yes, that's the idea.
Or do we still need a concept comparable to slide-stores/scopes?
No, not really. As I explained above, this would strongly limit your ability to move your data from one repository vendor to another, unless even the mapping/configuration details were specified.
True that there is no way to move the nodeTypes across the containers, so it won't be possible anyway with this version of the spec, but, architecturally, it would be easier to add in the future. [or, at least, that's how I see it]
Something like (server side only):
JCR (LDAP impl) webdav->JCR (Slide impl with scope config) < JCR (Filesystem impl)
JCR (RDBMS impl)
Or how can we take advantage of the vendor specific JCR-impls without loosing the mixed repository feature?
eh, good question. The architectural idea is that you have only one JCR implementation and all the various mapping are done inside by the various nodeTypes. Just like you don't have several Struts talking but one that includes everything you need for that webapp.
The way you mount, install, configure nodeTypes will be container/specific though. Meaning that you might be able to migrate your data from one vendor to another, but not the functionality transparently.
In the future, we expect to be able to do that as well. but political interests might block this.
What exactly is the target of jsr-170? Is not webdav the standard to
access
a content repository?
webdav is a protocol, JCR is an API. the parallel that comes to mind would be HTTP and the Servlet API.
JSR-147 seems to be the standard to access a content repository via java api.
Yes, client side.
So what is the use case for jsr-170 api?
server side.
Is it only the webdav layer or is there any imaginable server side application that needs to access the repository via jsr-170?
there are multiple scenarios.
1) embedded
application -(JCR)-> repository
I'm just curious if you have server side application in mind that needs
access to a content repository but has no need to be clusterable.
Oh, my blog, for example :-)
:-)
No, serious, all sort of micro-content management doesn't require clusterization nor complex architectures.
pro: speed con: architectural flexibility
2) remote (via RMI)
application -(JCR)-> -(RMI)-> repository
pro: improved architectural flexibility (many application can access the same repository) con: speed, only java application can access it
3) remote (via webdav)
application -(JCR)-> Webdav client -(WebDAV)-> Webdav server -(JCR)->
repository
Did you mean application -(JCR147)-> Webdav client -(WebDAV)-> Webdav server -(JCR170)->repository ?
No, I really meant JCR.
[please, keep in mind that JSR and JCR are too different things: JSR stands for Java Specification Request, while JCR stands for Java Content Repository (here I normally omit API)]
Sorry- I mixed this up.
No problem. Just wanted to outline this because people might get confused as well.
Imagine a scenario where you start with
application -(JCR)-> repository
then you want to migrate to a clutered environment. You don't want to move from 170 to 147, that wouldn't make any sense.
If you already know that you are going to be targetting a webdav
server, then 147 is for you, but if what you care is just a repository,
then 170 is the way to go.
I admit there is some overlap and that it's unfortunate that the way the JCP works doesn't really allow for technology to converge and reduce overlap.
This is my favorit approach as it allows easy clustering for the application.
Then go for it. JCR is not designed to be a client-side API, but it could be used to decouple thru a WebDAV tunnel, even if, admittedly, JSR147 is probably a much more elegant way of doing it.
I'm still confused as I sometime ago thought that JSR 147 only focusses on
deltav-client stuff (so that it would be ideal suited for IDE vcs
integration). Now I have the impression that both jsr's will totally overlap
if they are finished...
I don't think so (especially as the spec lead of 147 is a very active member of 170) but I admit that I don't know 147 well enough to outline the overlap precisely.
For application developer it would be ideal if there were one api to adress
repositories and the impl cares about remote or direct calls.
Yeah, I know.
I'm really curious which direction all this will take
mee too :-)
and look forward to have look at both JSR's!
Hopefully that will happen soon.
-- Stefano.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
