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/AnnotationProcessorExt
en
sion.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
/j
ava/com/msopentech/odatajclient/engine/utils/DefaultDOMParserImpl.java
[5]
https://github.com/MSOpenTech/ODataJClient/blob/ODATA_4/engine/src/main
/j
ava/com/msopentech/odatajclient/engine/utils/AndroidDOMParserImpl.java?
so
urce=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.
