On 02/05/13 13:57, Andy Seaborne wrote:
You may wish to consider a 3-tier architecture - thin client, Tomcat for
the application layer and Fuseki for the database layer (which can be
another tomcat or even the same one but if it's a separate process or
server, using the integrated Jetty server is less work).
Fwiw, I've recently used a similar pattern but with Ruby-on-Rails as the
application tier. There are two ways to approach the application tier:
either using JRuby and the jena-jruby gem (which I should update, and
will as soon as the next Jena release goes live), or use regular Ruby
and request results from the Fuseki tier in JSON format. Both work well.
A third option would be to use the Ruby linked-data gem, which provides
quite a bit of RDF and SPARQL support, but I can't personally recommend
that because it's still on my "I must try this out one day" list!
Ian
Andy
On 01/05/13 21:45, Claude Warren wrote:
My experience is with medical research on large distributed SPARQL
servers
queried from a single server. Our server rewrote queries which it
sent to
endpoints and then recombined to present solutions to the clients. In
this
configuration we were dealing with fairly large data sets. In the end
our
application used javascript on the client to format and display the data.
There are several libraries that can provide rich user experiences. In
our case this worked well. I do not know what the final performance
of the
configuration was but I suspect that it would be lower than attempting to
do all the processing on the server. In our case the server just
presented
data (JSON format).
Claude
On Wed, May 1, 2013 at 8:28 PM, Joseph Daryl Locsin
<[email protected]>wrote:
I would like to ask for your opinion guys...
I am building a prototype client-server architecture using the semantic
web. I have decided to make a thick server (Server does all the semantic
related stuff using Jena (querying, instantiating, storing)) and a very
thin Android mobile client (client sends request with parameters and
receives response). My assumption is that this will still be feasible
even
when I have hundreds of clients (not tested).
*1. My question is, in a design like this where hundreds of clients will
access the server --- since it uses a knowledgebase and not an RDBMS (it
will be slower) --- is it practical to create a fat/thick server? or
should
I take some load off the server and put it on the client side e.g. using
AndroJena for Android so some processing will be done by the client as
well. Carefully planning this part is crucial since it will be
time-consuming to refactor code from server to client and vice-versa.
(note
Android phones are multi core phones which can means they can also do
some
heavy lifting)*
*2. Since AndroJena does not have an active community, not like this
forum... are there any better alternatives for Android? I have
checked the
SWIP link *http://swip.inrialpes.fr/ *it looks like there is still so
much
to do and not a single robust API like Jena.*
*
*
*3. Since I am also working on the iPhone, are there anything similar to
Jena out there? Probably Redland (although I haven't tested it yet)*
*
*
I really like Jena, I have tried resorting to RAP once (tried a PHP
server)
but documentation is poor and it looks like its deserted already. I am
happy to be a part of this community.
Cheers,
Daryl
