You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Dan Becker <da...@gmail.com> on 2008/10/24 16:11:39 UTC

[BRAINSTORM] Future improvements for Tuscany databinding framework - MIME/binary support

I'd like to follow up and further refine some ideas about data binding 
improvements. Much of this was published by Raymond on the wiki road map 
page [1] and on earlier dev list discussions [2].

I am especially interested in the areas regarding MIME type and binary 
data support given here. I think these 3 facets are related.
- Use MIME types to model the databinding ids (for example, application/xml,
application/x-java-serialized-object, image/jpeg)
- Support MIME based binary data types (incuding the xmime extensions in
WSDL/XSD)
- Support annotations of a java type (for example, an InputStream can be
used to contain different formats of data) to further constrain the data
type (We could use the JAXB annotation for this purpose)

Earlier this week I put together a customer scenario that I thought 
would benefit from this kind of feature. I imagined an auto insurance 
claim business service where customers could submit claims (simple Java 
beans with info) along with digital images of receipts. I thought the 
images could be provided as an InputStream or byte[]. Something like this:
    <service name="ClaimService">
       <interface.java interface="insurance.ClaimService" />
       <binding.ws uri="http://localhost:8080/insurance/ClaimService"/> 

    </service>
And the claim service would be something like this:
    @Remotable
    public interface ClaimService {
       boolean submit( Claim claim, InputStream [] receiptImages );
    }

Here is where I run into a junction, and I would like to open up the 
discussion to other Tuscany developers. Ideally I would like the 
interface to be generic, so as not to constrain the data to one image 
type. Allow JPGs, GIFs, PNGs, and future image types. On the other hand, 
I would not like to saddle clients with lots of digging, testing, and 
formatting work to fit into a more specific data type on the interface. 
MIME types seem a useful means of conveying what is in the binary 
InputStream. However, I'd like to know the best place to specify this. 
Put it on the service interface? As an extra method input? As a generic? 
  Some other form of annotation?

This same sort of content discussion also applies to Strings. What is in 
that String you are passing? Text? HTML? XML? Other? How should one 
specify it so that clients are services don't have to do lots of digging 
and testing on the String?

What do users think would be an improvement over passing unlabeled blobs 
(InputStream, byte [], String, etc.) around?

[1] http://cwiki.apache.org/confluence/x/oU8B
[2] http://markmail.org/message/4iazlvo23qq3tho4

-- 
Thanks, Dan Becker

Re: [BRAINSTORM] Future improvements for Tuscany databinding framework - MIME/binary support

Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Tue, Oct 28, 2008 at 2:03 PM, Dan Becker <da...@gmail.com> wrote:
> Very useful ideas. I agreed with the notion of content transfer encoding as
> well. Thanks.

(short guide to MIME typing)

there are 6 base MIME headers (see RFC 2045)

MIME-Version (in practice always 1.0)
Content-Type (media type and subtype eg image/png)
Content-Transfer-Encoding (eg BASE64)
Content-ID (used for referencing)
Content-Description (not machine readable)

plus any number of standard extensions

in addition to media type and subtype, any number of parameters may be
included in the Content-Type header value. may parameters are
standards for example:

Content-Type: text/plain; charset=us-ascii

media type and subtype are - in general - too broad to allow decoding
without magic without parameters. for example, a document which is
uses charset shift-jis cannot be decoded just from text/plain. another
example - a multipart messages cannot be decoded without it's boundary
parameters.

full support for MIME typing requires meta-data support (headers) but
Content-Transfer-Encoding and Content-Type should satisfy most common
cases.

- robert

Re: [BRAINSTORM] Future improvements for Tuscany databinding framework - MIME/binary support

Posted by Dan Becker <da...@gmail.com>.
Very useful ideas. I agreed with the notion of content transfer encoding 
as well. Thanks.

Raymond, can you suggest where to place the annotation in the example? A 
property on the interface specification in the composite?

 >>>        <interface.java interface="insurance.ClaimService" />


Raymond Feng wrote:
> Good point. It would be helpful to support the content transfer encoding 
> as well. Is it possible or wise to accept it as a parameter in the MIME 
> type, for example, "image/png; encoding=Base64"?
> 
> JAXB defines an annotation @XmlMimeType to associate the MIME type that 
> controls the XML representation of the property. This annotation is used 
> in conjunction with datatypes such as Image or Source that are bound to 
> base64-encoded binary in XML. It always assume base64 as the encoding.
> 
> [1] 
> http://java.sun.com/javase/6/docs/api/javax/xml/bind/annotation/XmlMimeType.html 
> 
> --------------------------------------------------
> From: "Robert Burrell Donkin" <ro...@gmail.com>
> Sent: Saturday, October 25, 2008 2:22 AM
> To: <de...@tuscany.apache.org>
> Subject: Re: [BRAINSTORM] Future improvements for Tuscany databinding 
> framework - MIME/binary support
> 
>> On 10/24/08, Dan Becker <da...@gmail.com> wrote:
>>> I'd like to follow up and further refine some ideas about data binding
>>> improvements. Much of this was published by Raymond on the wiki road map
>>> page [1] and on earlier dev list discussions [2].
>>>
>>> I am especially interested in the areas regarding MIME type and binary
>>> data support given here. I think these 3 facets are related.
>>> - Use MIME types to model the databinding ids (for example, 
>>> application/xml,
>>> application/x-java-serialized-object, image/jpeg)
>>> - Support MIME based binary data types (incuding the xmime extensions in
>>> WSDL/XSD)
>>> - Support annotations of a java type (for example, an InputStream can be
>>> used to contain different formats of data) to further constrain the data
>>> type (We could use the JAXB annotation for this purpose)
>>>
>>> Earlier this week I put together a customer scenario that I thought
>>> would benefit from this kind of feature. I imagined an auto insurance
>>> claim business service where customers could submit claims (simple Java
>>> beans with info) along with digital images of receipts. I thought the
>>> images could be provided as an InputStream or byte[]. Something like 
>>> this:
>>>     <service name="ClaimService">
>>>        <interface.java interface="insurance.ClaimService" />
>>>        <binding.ws uri="http://localhost:8080/insurance/ClaimService"/>
>>>
>>>     </service>
>>> And the claim service would be something like this:
>>>     @Remotable
>>>     public interface ClaimService {
>>>        boolean submit( Claim claim, InputStream [] receiptImages );
>>>     }
>>>
>>> Here is where I run into a junction, and I would like to open up the
>>> discussion to other Tuscany developers. Ideally I would like the
>>> interface to be generic, so as not to constrain the data to one image
>>> type. Allow JPGs, GIFs, PNGs, and future image types. On the other hand,
>>> I would not like to saddle clients with lots of digging, testing, and
>>> formatting work to fit into a more specific data type on the interface.
>>> MIME types seem a useful means of conveying what is in the binary
>>> InputStream. However, I'd like to know the best place to specify this.
>>> Put it on the service interface? As an extra method input? As a generic?
>>>   Some other form of annotation?
>>>
>>> This same sort of content discussion also applies to Strings. What is in
>>> that String you are passing? Text? HTML? XML? Other? How should one
>>> specify it so that clients are services don't have to do lots of digging
>>> and testing on the String?
>>>
>>> What do users think would be an improvement over passing unlabeled blobs
>>> (InputStream, byte [], String, etc.) around?
>>
>> In general, to understand a MIME encoded document, a single type
>> string is not sufficient. An image typed image/png but this may be
>> transfer encoded BASE64, quoted-printable, native etc. To decode
>> without magic, it's neccessary to allow multiple MIME headers.
>>
>> IMHO it would therefore be better to allow general text based meta 
>> data headers
>>
>> Robert
>>
>>>
>>> [1] http://cwiki.apache.org/confluence/x/oU8B
>>> [2] http://markmail.org/message/4iazlvo23qq3tho4
>>>

-- 
Thanks, Dan Becker

Re: [BRAINSTORM] Future improvements for Tuscany databinding framework - MIME/binary support

Posted by Raymond Feng <en...@gmail.com>.
Hi,

Good point. It would be helpful to support the content transfer encoding as 
well. Is it possible or wise to accept it as a parameter in the MIME type, 
for example, "image/png; encoding=Base64"?

JAXB defines an annotation @XmlMimeType to associate the MIME type that 
controls the XML representation of the property. This annotation is used in 
conjunction with datatypes such as Image or Source that are bound to 
base64-encoded binary in XML. It always assume base64 as the encoding.

[1] 
http://java.sun.com/javase/6/docs/api/javax/xml/bind/annotation/XmlMimeType.html

Thanks,
Raymond
--------------------------------------------------
From: "Robert Burrell Donkin" <ro...@gmail.com>
Sent: Saturday, October 25, 2008 2:22 AM
To: <de...@tuscany.apache.org>
Subject: Re: [BRAINSTORM] Future improvements for Tuscany databinding 
framework - MIME/binary support

> On 10/24/08, Dan Becker <da...@gmail.com> wrote:
>> I'd like to follow up and further refine some ideas about data binding
>> improvements. Much of this was published by Raymond on the wiki road map
>> page [1] and on earlier dev list discussions [2].
>>
>> I am especially interested in the areas regarding MIME type and binary
>> data support given here. I think these 3 facets are related.
>> - Use MIME types to model the databinding ids (for example, 
>> application/xml,
>> application/x-java-serialized-object, image/jpeg)
>> - Support MIME based binary data types (incuding the xmime extensions in
>> WSDL/XSD)
>> - Support annotations of a java type (for example, an InputStream can be
>> used to contain different formats of data) to further constrain the data
>> type (We could use the JAXB annotation for this purpose)
>>
>> Earlier this week I put together a customer scenario that I thought
>> would benefit from this kind of feature. I imagined an auto insurance
>> claim business service where customers could submit claims (simple Java
>> beans with info) along with digital images of receipts. I thought the
>> images could be provided as an InputStream or byte[]. Something like 
>> this:
>>     <service name="ClaimService">
>>        <interface.java interface="insurance.ClaimService" />
>>        <binding.ws uri="http://localhost:8080/insurance/ClaimService"/>
>>
>>     </service>
>> And the claim service would be something like this:
>>     @Remotable
>>     public interface ClaimService {
>>        boolean submit( Claim claim, InputStream [] receiptImages );
>>     }
>>
>> Here is where I run into a junction, and I would like to open up the
>> discussion to other Tuscany developers. Ideally I would like the
>> interface to be generic, so as not to constrain the data to one image
>> type. Allow JPGs, GIFs, PNGs, and future image types. On the other hand,
>> I would not like to saddle clients with lots of digging, testing, and
>> formatting work to fit into a more specific data type on the interface.
>> MIME types seem a useful means of conveying what is in the binary
>> InputStream. However, I'd like to know the best place to specify this.
>> Put it on the service interface? As an extra method input? As a generic?
>>   Some other form of annotation?
>>
>> This same sort of content discussion also applies to Strings. What is in
>> that String you are passing? Text? HTML? XML? Other? How should one
>> specify it so that clients are services don't have to do lots of digging
>> and testing on the String?
>>
>> What do users think would be an improvement over passing unlabeled blobs
>> (InputStream, byte [], String, etc.) around?
>
> In general, to understand a MIME encoded document, a single type
> string is not sufficient. An image typed image/png but this may be
> transfer encoded BASE64, quoted-printable, native etc. To decode
> without magic, it's neccessary to allow multiple MIME headers.
>
> IMHO it would therefore be better to allow general text based meta data 
> headers
>
> Robert
>
>>
>> [1] http://cwiki.apache.org/confluence/x/oU8B
>> [2] http://markmail.org/message/4iazlvo23qq3tho4
>>
>> --
>> Thanks, Dan Becker
>>

Re: [BRAINSTORM] Future improvements for Tuscany databinding framework - MIME/binary support

Posted by Robert Burrell Donkin <ro...@gmail.com>.
On 10/24/08, Dan Becker <da...@gmail.com> wrote:
> I'd like to follow up and further refine some ideas about data binding
> improvements. Much of this was published by Raymond on the wiki road map
> page [1] and on earlier dev list discussions [2].
>
> I am especially interested in the areas regarding MIME type and binary
> data support given here. I think these 3 facets are related.
> - Use MIME types to model the databinding ids (for example, application/xml,
> application/x-java-serialized-object, image/jpeg)
> - Support MIME based binary data types (incuding the xmime extensions in
> WSDL/XSD)
> - Support annotations of a java type (for example, an InputStream can be
> used to contain different formats of data) to further constrain the data
> type (We could use the JAXB annotation for this purpose)
>
> Earlier this week I put together a customer scenario that I thought
> would benefit from this kind of feature. I imagined an auto insurance
> claim business service where customers could submit claims (simple Java
> beans with info) along with digital images of receipts. I thought the
> images could be provided as an InputStream or byte[]. Something like this:
>     <service name="ClaimService">
>        <interface.java interface="insurance.ClaimService" />
>        <binding.ws uri="http://localhost:8080/insurance/ClaimService"/>
>
>     </service>
> And the claim service would be something like this:
>     @Remotable
>     public interface ClaimService {
>        boolean submit( Claim claim, InputStream [] receiptImages );
>     }
>
> Here is where I run into a junction, and I would like to open up the
> discussion to other Tuscany developers. Ideally I would like the
> interface to be generic, so as not to constrain the data to one image
> type. Allow JPGs, GIFs, PNGs, and future image types. On the other hand,
> I would not like to saddle clients with lots of digging, testing, and
> formatting work to fit into a more specific data type on the interface.
> MIME types seem a useful means of conveying what is in the binary
> InputStream. However, I'd like to know the best place to specify this.
> Put it on the service interface? As an extra method input? As a generic?
>   Some other form of annotation?
>
> This same sort of content discussion also applies to Strings. What is in
> that String you are passing? Text? HTML? XML? Other? How should one
> specify it so that clients are services don't have to do lots of digging
> and testing on the String?
>
> What do users think would be an improvement over passing unlabeled blobs
> (InputStream, byte [], String, etc.) around?

In general, to understand a MIME encoded document, a single type
string is not sufficient. An image typed image/png but this may be
transfer encoded BASE64, quoted-printable, native etc. To decode
without magic, it's neccessary to allow multiple MIME headers.

IMHO it would therefore be better to allow general text based meta data headers

Robert

>
> [1] http://cwiki.apache.org/confluence/x/oU8B
> [2] http://markmail.org/message/4iazlvo23qq3tho4
>
> --
> Thanks, Dan Becker
>