Hi Russ
This is something we're considering at the moment - the best way to get remotable APIs used by the web client. We think it mean a service layer between the current native Java and the Web Service APIs - but as I say, it's something we've just started considering. We don't really want to force the web client through a WS api.
Cheers
Paul.
Just digging around in the source a little, creating for example a node service implementation that consumes the web services? That is what I was thinking as well. I havent gotten in to the web services very deeply so I dont have a good feel for how aligned they are. From what I can see its not a one for one translation from java to the webservice. I assume you wanted the web services to be more coarse grained to cut down on chatter.
If you make a remoted version (via webservice) of the node service for example – which seems like the way to avoid refactoring the webclient… just alter the spring configuration and go sailing – what are the biggest concerns?
The two that pop up in my mind are call volume, and authentication/authorization persistance over all of the calls - not just as it relates to basic webservices but also as it relates the repositories authentication scheme.
Jackrabbit remoted the JCR with RMI. Thats got firewall issues, its java centric and and has some scalability issues - not to mention what a pain it is to work with RMI and serialization
. Dont get me wrong. Its been a blessing to have a remoting capability on top of alresco JCR… My proof of concept stuff has jackrabbit to thank but we do need something that can traverse a firewall and isnt java centric.
