Hi Stephan,
see my replies inline.
Regards.
On 13/02/2014 13:57, Klevenz, Stephan wrote:
Hi Fabio,
I had a closer look at proxy and engine layer and like that very much. Is
it correct that proxy is on top of engine and can be seen as an extension?
Or better the engine does work without the proxy, right?
Correct.
In current OData 2.0 library we have also something that is on top which
is JPA processor and annotation processor. This looks similar to your
proxy just because it is on top, all deal with annotations and should ease
the use of library. Maybe it makes sense first to have a deeper look into
the engine and what we just call the library.
Agree, this seems definitely reasonable.
The first thing that came into focus of my interest is edm. Concrete
com.msopentech.odatajclient.engine.data.metadata.* which is similar to
org.apache.olingo.odata2.api.edm.*. Both is edm. Independent of client or
server use case there can be at least one common edm interface. On server
side there is a so called edm provider which realizes lazy loading
(partial read of metadata). For server this is essential but for the
client lazy loading sounds like not required. I am note sure but don't see
a use case where a client reads partial metadata. So maybe we have one
interface and two implementations for edm. One edm implementation is
optimized for client and another one carries all the stuff a server needs.
About metadata, think that in ODataJClient any request but invoke does
not need metadata to work; moreover, metadata don't need to be written
on client side, but only parsed.
This to confirm that IMO we should find a way to retain a common part,
given the different usage that client and server make of metadata.
As you've already seen, we use Jackson XML [2] for parsing metadata: we
found it very efficient, flexible and unbelievably fast.
Moreover, consider that we have already implemented the V4 metadata
parsing in the ODATA_4 branch (the one which is actually being donated).
Another thing is the com.msopentech.odatajclient.engine.data package and
serialization/deserialization. Server and client do require the same
functionality. Your implementation is dom based and uses jackson for json
and xml (correct?). We are using stax for xml and gson for json and all is
event based. With a dom base approach we experienced issues (performance
and memory consumption) in case of large metadata or data sets. Jackson
for json and xml makes sense because of stax is not a good option for
Android client use cases.
The current V3 implementation works well with Android (there is also a
working sample [3]) and uses different DOM implementations for the
desktop [4] and mobile [5] use cases.
Anyway I am currently updating the Atom parser (still at GitHub, waiting
for the code to land to olingo4 repo) and I am realizing that Jackson
XML [2] is, as you suggest above, probably the best option:
* PROS: performance, uniformity with metadata handling, removal of
"special" Android treatment [5]
* CONS: need to rewrite from scratch the current Atom parser :-) - but
I've already started this work
Olingos data structure that a server has to fill is quite low level.
Actually its just a hashtable. Maybe we can make use of data classes like
ODataEntity of your engine code.
If you simplify the module proposal I made then we have a client code on
the left and a server code on the right side. Ideally client and server do
have their own best fitting architecture and structure. In other words a
separation between proxy and engine for the client still makes sense. The
challenge is the middle part, we call it 'commons', which is used by
client and server. My candidates are edm and serialization.
+1
Regards.
[1]
http://olingo.incubator.apache.org/doc/tutorials/AnnotationProcessorExtension.html
[2] https://github.com/FasterXML/jackson-dataformat-xml
[3] https://github.com/Tirasa/ODataJClientOnAndroidSample
[4]
https://github.com/MSOpenTech/ODataJClient/blob/ODATA_4/engine/src/main/java/com/msopentech/odatajclient/engine/utils/DefaultDOMParserImpl.java
[5]
https://github.com/MSOpenTech/ODataJClient/blob/ODATA_4/engine/src/main/java/com/msopentech/odatajclient/engine/utils/AndroidDOMParserImpl.java?source=cc
On 12.02.14 13:48, "Fabio Martelli" <fabio.marte...@gmail.com> wrote:
Il 11/02/2014 17:19, Klevenz, Stephan ha scritto:
Hi,
I would like to start a technical discussion about a module proposal
for OData 4.0 client and server library.
Starting point is that we have an OData V 3.0 client (Eduards new
contribution) and an Olingo client/server for OData 2.0. On following
wiki page I did draw a picture to get some first view on structure and
to find responsibilities for modules. The idea is to get the best out of
all contributions.
https://wiki.apache.org/Olingo/Olingo%20Module%20Proposal
There is not so much explained. Feel free to ask, comment or discuss.
Greetings,
Stephan
Hi Stephan, I'm taking a look at the wiki page "Olingo Module Proposal".
I've just a consideration to point out.
OData V 3.0 client is composed of two main modules: the engine and the
proxy.
These are two difference abstraction layers with different scopes, of
course.
The engine is the low-level communication layer taking care of actual
REST communication and OData entity (de)serialization, exposing methods
to hook into the OData protocol for manipulating entities and invoking
actions and functions. It is there for Java developers that needs to
access underlying details of the OData communication protocol.
The proxy converts any local change to POJOs and any local invocation of
annotated interfaces' methods into actual calls to the Engine layer. It
is thought for experienced Java developers which are familiar with
widespread Java Enterprise and / or Open Source technologies and prefer
to interact with OData services at a very abstract level (like JPA, more
or less).
Of course, the proxy layer depends on the engine layer BTW each one can
be considered as a different client.
May be it would be better to explain this concept into the picture. What
do you think?
Best regards,
F.
--
Francesco Chicchiriccò
Tirasa - Open Source Excellence
http://www.tirasa.net/
Involved at The Apache Software Foundation:
member, Syncope PMC chair, Cocoon PMC, Olingo PPMC
http://people.apache.org/~ilgrosso/
