You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Anders Rundgren <an...@gmail.com> on 2017/01/28 05:50:43 UTC
YASMIN - Yet Another jSon Message notatIoN
This is a considerably updated version of the scheme I sent earlier.
Enjoy!
-------------------------------------------------------------
WebSocket [1] is claimed to be the most efficient communication method for interactive Web applications.
REST [2] is essentially incompatible with WebSocket although some people try to merge them. That's IMO fairly pointless, since they are building on different concepts.
YASMIN [3], OTOH was designed from scratch to support both event-based communication like WebSocket and postMessage(), as well as traditional request/response schemes.
Anders
1] https://tools.ietf.org/rfc/rfc6455.txt
2] https://en.wikipedia.org/wiki/Representational_state_transfer
https://cyberphone.github.io/doc/web/REST-in-peace.html
3] https://cyberphone.github.io/doc/web/yasmin.html
Re: YASMIN - Yet Another jSon Message notatIoN
Posted by Sergey Beryozkin <sb...@gmail.com>.
Sorry, will copy this to the JIRA :-)
thanks, Sergey
On 01/02/17 16:35, Sergey Beryozkin wrote:
> The question is, given a custom bean, like MyDocument (which may have
> some properties), how to intercept the JSON serialization process, so
> that the signature can be calculated on the flight and the payload be
> augmented with the @signature property.
>
> If MyDocument has JAXB annotations and depends on a JAXB XML to JSON
> conversions then perhaps we can register a JCS XMLStreamWriter (and
> XMLStreamReader on the read side) which is possible for ex with CXF
> JSONProvider (Jettison based).
>
> If Jackson allows to intercept the serialization process then perhaps it
> is possible to use Jackson.
>
> May be the simplest option to start, for POC, is to have CXF filters
> caching the stream, and then reading it, adding or validating the
> signature, and then letting the request flow.
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Re: YASMIN - Yet Another jSon Message notatIoN
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Anders,
On 01/02/17 14:11, Anders Rundgren wrote:
> Hi Sergey,
>
> Thank you very much for looking into this, I really appreciate it!
Np at all, many thanks for getting engaged with the CXF community :-)
>
> A snag is that JCS relies on ES6-compatible JSON serialization which is
> standard
> in the JavaScript world (Browsers and Node.js), but not (yet) in Java.
>
That is OK. The important thing is what goes on the wire and a given
Java based JSON parser (as long as it is Java based) can produce
whatever real JSON which is needed for some feature to interoperate with
the remote HTTP consumers/producers.
> Introducing yet another JSON parser/serializer [1] in the CXF package is
> probably
> not what people want so maybe I should start by creating JCS support for
> "Jackson"?
The question is, given a custom bean, like MyDocument (which may have
some properties), how to intercept the JSON serialization process, so
that the signature can be calculated on the flight and the payload be
augmented with the @signature property.
If MyDocument has JAXB annotations and depends on a JAXB XML to JSON
conversions then perhaps we can register a JCS XMLStreamWriter (and
XMLStreamReader on the read side) which is possible for ex with CXF
JSONProvider (Jettison based).
If Jackson allows to intercept the serialization process then perhaps it
is possible to use Jackson.
May be the simplest option to start, for POC, is to have CXF filters
caching the stream, and then reading it, adding or validating the
signature, and then letting the request flow.
>
> For YASMIN integration I'm thinking of something like the following:
> https://cyberphone.github.io/doc/web/yasmin.html#apimapping
> How you could add signature support through annotations is not entirely
> clear.
Sure that cab investigated later on...
Thanks, Sergey
>
> Cheers,
> Anders
>
> PS I will use the issue you created
> https://issues.apache.org/jira/browse/CXF-6532
> for future discussions on basic JCS integration.
>
> 1]
> https://cyberphone.github.io/doc/openkeystore/javaapi/org/webpki/json/package-summary.html
>
>
>
> On 2017-02-01 14:07, Sergey Beryozkin wrote:
>> Hi Anders
>>
>> Thanks for sharing the link to a new scheme :-)
>>
>> FYI, as far as CXF is concerned, CXF users do all sort of services,
>> SOAP, pure REST, or simply HTTP with whatever communication scheme they
>> prefer :-).
>>
>> As far as YASMIN is concerned from the prospect of having something like
>> that done in CXF, I'd like to consider it possibly done in 2 steps:
>>
>> 1. Support JCS - we'd let CXF users JCS-sign arbitrary JSON payloads,
>> they won't need to be YASMIN-bound. JCS allows for that, so we could
>> have a JAX-RS JCS filter or MessageBodyWriter which signs JSON.
>> 2. Offer some YASMIN-specific model support etc with the implicit
>> conversion of the custom data to YASMIN payloads.
>>
>> What do you think ? We can discuss 1. at
>> https://issues.apache.org/jira/browse/CXF-6532
>>
>> FYI a CXF JCS empty module (not included in the Maven build) is already
>> available in the source
>>
>> Thanks, Sergey
>>
>>
>> On 28/01/17 05:50, Anders Rundgren wrote:
>>> This is a considerably updated version of the scheme I sent earlier.
>>> Enjoy!
>>> -------------------------------------------------------------
>>>
>>> WebSocket [1] is claimed to be the most efficient communication method
>>> for interactive Web applications.
>>>
>>> REST [2] is essentially incompatible with WebSocket although some people
>>> try to merge them. That's IMO fairly pointless, since they are building
>>> on different concepts.
>>>
>>> YASMIN [3], OTOH was designed from scratch to support both event-based
>>> communication like WebSocket and postMessage(), as well as traditional
>>> request/response schemes.
>>>
>>> Anders
>>>
>>> 1] https://tools.ietf.org/rfc/rfc6455.txt
>>>
>>> 2] https://en.wikipedia.org/wiki/Representational_state_transfer
>>> https://cyberphone.github.io/doc/web/REST-in-peace.html
>>>
>>> 3] https://cyberphone.github.io/doc/web/yasmin.html
>>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Re: YASMIN - Yet Another jSon Message notatIoN
Posted by Anders Rundgren <an...@gmail.com>.
Hi Sergey,
Thank you very much for looking into this, I really appreciate it!
A snag is that JCS relies on ES6-compatible JSON serialization which is standard
in the JavaScript world (Browsers and Node.js), but not (yet) in Java.
Introducing yet another JSON parser/serializer [1] in the CXF package is probably
not what people want so maybe I should start by creating JCS support for "Jackson"?
For YASMIN integration I'm thinking of something like the following:
https://cyberphone.github.io/doc/web/yasmin.html#apimapping
How you could add signature support through annotations is not entirely clear.
Cheers,
Anders
PS I will use the issue you created https://issues.apache.org/jira/browse/CXF-6532
for future discussions on basic JCS integration.
1] https://cyberphone.github.io/doc/openkeystore/javaapi/org/webpki/json/package-summary.html
On 2017-02-01 14:07, Sergey Beryozkin wrote:
> Hi Anders
>
> Thanks for sharing the link to a new scheme :-)
>
> FYI, as far as CXF is concerned, CXF users do all sort of services,
> SOAP, pure REST, or simply HTTP with whatever communication scheme they
> prefer :-).
>
> As far as YASMIN is concerned from the prospect of having something like
> that done in CXF, I'd like to consider it possibly done in 2 steps:
>
> 1. Support JCS - we'd let CXF users JCS-sign arbitrary JSON payloads,
> they won't need to be YASMIN-bound. JCS allows for that, so we could
> have a JAX-RS JCS filter or MessageBodyWriter which signs JSON.
> 2. Offer some YASMIN-specific model support etc with the implicit
> conversion of the custom data to YASMIN payloads.
>
> What do you think ? We can discuss 1. at
> https://issues.apache.org/jira/browse/CXF-6532
>
> FYI a CXF JCS empty module (not included in the Maven build) is already
> available in the source
>
> Thanks, Sergey
>
>
> On 28/01/17 05:50, Anders Rundgren wrote:
>> This is a considerably updated version of the scheme I sent earlier.
>> Enjoy!
>> -------------------------------------------------------------
>>
>> WebSocket [1] is claimed to be the most efficient communication method
>> for interactive Web applications.
>>
>> REST [2] is essentially incompatible with WebSocket although some people
>> try to merge them. That's IMO fairly pointless, since they are building
>> on different concepts.
>>
>> YASMIN [3], OTOH was designed from scratch to support both event-based
>> communication like WebSocket and postMessage(), as well as traditional
>> request/response schemes.
>>
>> Anders
>>
>> 1] https://tools.ietf.org/rfc/rfc6455.txt
>>
>> 2] https://en.wikipedia.org/wiki/Representational_state_transfer
>> https://cyberphone.github.io/doc/web/REST-in-peace.html
>>
>> 3] https://cyberphone.github.io/doc/web/yasmin.html
>
Re: YASMIN - Yet Another jSon Message notatIoN
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Anders
Thanks for sharing the link to a new scheme :-)
FYI, as far as CXF is concerned, CXF users do all sort of services,
SOAP, pure REST, or simply HTTP with whatever communication scheme they
prefer :-).
As far as YASMIN is concerned from the prospect of having something like
that done in CXF, I'd like to consider it possibly done in 2 steps:
1. Support JCS - we'd let CXF users JCS-sign arbitrary JSON payloads,
they won't need to be YASMIN-bound. JCS allows for that, so we could
have a JAX-RS JCS filter or MessageBodyWriter which signs JSON.
2. Offer some YASMIN-specific model support etc with the implicit
conversion of the custom data to YASMIN payloads.
What do you think ? We can discuss 1. at
https://issues.apache.org/jira/browse/CXF-6532
FYI a CXF JCS empty module (not included in the Maven build) is already
available in the source
Thanks, Sergey
On 28/01/17 05:50, Anders Rundgren wrote:
> This is a considerably updated version of the scheme I sent earlier.
> Enjoy!
> -------------------------------------------------------------
>
> WebSocket [1] is claimed to be the most efficient communication method
> for interactive Web applications.
>
> REST [2] is essentially incompatible with WebSocket although some people
> try to merge them. That's IMO fairly pointless, since they are building
> on different concepts.
>
> YASMIN [3], OTOH was designed from scratch to support both event-based
> communication like WebSocket and postMessage(), as well as traditional
> request/response schemes.
>
> Anders
>
> 1] https://tools.ietf.org/rfc/rfc6455.txt
>
> 2] https://en.wikipedia.org/wiki/Representational_state_transfer
> https://cyberphone.github.io/doc/web/REST-in-peace.html
>
> 3] https://cyberphone.github.io/doc/web/yasmin.html