Wrote a blog entry about this too if anyone was interested...
http://netzooid.com/blog/2007/01/04/the-ws-i-attachmentsprofile-is-a-sham/
Cheers,
Dan
On 1/4/07, Dan Diephouse <dan_at_envoisolutions.com> wrote:
>
> Unfortunately this "profile" has absolutely no connection to reality and
> what the old SwA spec was like. The SwA Profile invented a completely new
> CID format and a completely new way to reference attachments in a wsdl. So
> when the SwA profile came out there were in fact no frameworks which
> conformed to it. How is that a profile? (not that you have to answer, I'm
> just upset....)
>
> It seems the WSDL spec doesn't really specify how attachments are to be
> referenced well so all we have are implementations (like Axis 1.x) which
> just don't allow actually referencing the attachment in the schema AFAIK.
>
> MIME binding: http://www.w3.org/TR/wsdl#_Toc492291084
>
> *sigh*
>
> Here is a complete example from Axis that many people support:
>
>
> http://svn.apache.org/viewvc/webservices/axis/trunk/java/samples/swa/swa.wsdl?revision=264831&view=markup
>
> I may just force users to add the SWA attachment into the JAX-WS
> attachment map unless someone has better ideas. Thanks,
>
> - Dan
>
> On 1/4/07, Simeon Greene <simeon.m.greene_at_oracle.com> wrote:
> >
> > This is not a swaRef WSDL. It is Soap With Attachments and is purely an
> > artifact of WSD MIME binding and not represented in XML schema (unlike
> > MTOM and SwaRef). That would make it unsupported by JAXB IMO. For
> > further reference see the WS-I Attachments Profile
> > (http://www.ws-i.org/Profiles/AttachmentsProfile-1.0.html), where this
> > MIME binding support is described.
> >
> > -Simeon
> >
> > Kohsuke Kawaguchi wrote:
> > > Dan Diephouse wrote:
> > >> Hiya,
> > >>
> > >> I'm looking for a way to use JAXB with a legacy WSDL which doesn't
> > >> use the
> > >> wsi:swaRef type. Here's what the message looks like:
> > >>
> > >> <wsdl:message name="echoDataRequest">
> > >> <wsdl:part name="text" type="xsd:string" />
> > >> <wsdl:part name="data" type="xsd:base64Binary" />
> > >> </wsdl:message>
> > >>
> > >> And my binding:operation:
> > >>
> > >> <wsdl:operation name="echoData">
> > >> <soap:operation soapAction="" style="literal" />
> > >> <wsdl:input>
> > >> <mime:multipartRelated>
> > >> <mime:part name="body">
> > >> <soap:body parts="text" use="literal" />
> > >> </mime:part>
> > >> <mime:part name="data">
> > >> <mime:content part="data" type="application/octet-stream"
> > />
> > >> </mime:part>
> > >> </mime:multipartRelated>
> > >> </wsdl:input>
> > >> <wsdl:output>
> > >> <mime:multipartRelated>
> > >> <mime:part name="body">
> > >> <soap:body parts="text" use="literal" />
> > >> </mime:part>
> > >> <mime:part name="data">
> > >> <mime:content part="data" type="application/octet-stream"
> > />
> > >> </mime:part>
> > >> </mime:multipartRelated>
> > >> </wsdl:output>
> > >> </wsdl:operation>
> > >>
> > >> Now the issue here seems to be that JAXB requires swaRef to read in
> > an
> > >> attachment. On my incoming message I have this:
> > >>
> > >> <text>Hello</text>
> > >> <data href="cid:....."/>
> > >>
> > >> Is there any way to get JAXB to recognize that data is in fact an
> > >> attachment
> > >> without reworking my schema?
> > >
> > > Hmm. I don't think it works. As far as JAXB can tell, @href is just
> > > invalid and it will simply ignore that, and consider "" to match
> > > bas64Binary, hence length-0 binary data.
> > >
> > > Did some spec at point advocated this kind of swaRef support? If so,
> > > we can consider handling this. But if this is invented by this
> > > particular appliation, I don't think we can afford to handle such
> > cases.
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe_at_jaxb.dev.java.net
> > For additional commands, e-mail: users-help_at_jaxb.dev.java.net
> >
> >
>
>
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog
>
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog