Not sure about ServiceMix but on the Ode side we could retain attachments somewhere and pass them on for invocations occurring in the same request/response interaction. These could be either persisted as a message exchange property for example or maintained in memory. However the in-memory alternative would forbid too big attachments.
None of that is implemented for now anyway... Matthieu On 3/28/07, Dan <[EMAIL PROTECTED]> wrote:
I'm working on a related usage model. I would like to use ODE (on top of servicemix) to correlate several asynchronous responses to an initial client request. The responses will be SOAP with a mixture of text properties and binary attachments. I don't need to manipulate those responses but I do need to correlate them and return them to the client as it requests them. Performance is important to this application, so I would like to avoid thrashing the database and unnecessarily copying between spaces. Is there a recommended approach for using ODE/ServiceMix for this type of correlation? Thanks, Dan On 3/27/07, wolfgang10 <[EMAIL PROTECTED]> wrote: > > > I don´t need to transform the attachment in the bpel process, but would > like > to forward a let´s say image to another party. Although technically > possible > modifying the original message and adding a base64 encoded image before it > is passed on to ode is nothing I really want do do. It simply seems to be > too much effort just for forwarding an attachment. I understand that bpel > does not have the concept of a normalized message such as servicemix, but > that means that it is questionable whether ode is the right choice for me > to > run processes on the esb. It´s probable better to stick with the means > that > servicemix provides. For instance the eip patterns. > > Wolfgang > > > Alex Boisvert wrote: > > > > If you attachments are reasonably sized (smaller than available RAM), > then > > there should not be an issue carrying them in the message payload. If > > you're worried about performance, I would consider that transforming > > attachments is probably insignificant compared to the cost of storing > them > > in the database. > > > > Starting with the most important question, do you need to access or > > transform the attachments in your BPEL process? The reason I ask is > > because BPEL does not offer much support for accessing and manipulating > > large binary objects. Moreover, the Ode architecture is not optimized > for > > handling such large objects -- it does not use streaming APIs -- so I > > believe you would be better off managing them outside of the engine. > > > > alex > > > > > > On 3/27/07, wolfgang10 <[EMAIL PROTECTED]> wrote: > >> > >> > >> Do I understand you right that there is no way to access the properties > >> or > >> attachments of the normalized message within ode? > >> I guess the bpel engine would really be a bottleneck then in many > >> scenarios. > >> Every time I passed around a normalized message I would have to > transfer > >> the > >> properties and attachments in one of the ways you mentioned. This would > >> require amending the original message and adding the required data at > >> each > >> boundary of servicemix and ode. > >> > >> Is there no better way? > >> > >> Wolfgang > >> > >> > >> Alex Boisvert wrote: > >> > > >> > There are a few options.... > >> > > >> > 1) Use Base64-encoded values in your message payload > >> > 2) Pass around HTTP URLs pointing to your attachment > >> > 3) Use the ESB's handler chains to bind your attachments to the > message > >> on > >> > its way out. > >> > > >> > alex > >> > > >> > > >> > On 3/27/07, wolfgang10 <[EMAIL PROTECTED]> wrote: > >> >> > >> >> > >> >> Hello, > >> >> > >> >> Is it possible to process attachments in ode? > >> >> Assume I use ode-jbi in servicemix. I receive a message which is > sent > >> >> over > >> >> the esb as a normalized message. That is, it has an xml part and a > >> binary > >> >> attachment. What if I want to send the attachment to an external > party > >> >> using > >> >> bpel. Is that possible? > >> >> > >> >> Thanks > >> >> Wolfgang > >> >> -- > >> >> View this message in context: > >> >> http://www.nabble.com/Attachment-tf3474259.html#a9696340 > >> >> Sent from the Apache Ode User mailing list archive at Nabble.com. > >> >> > >> >> > >> > > >> > > >> > >> -- > >> View this message in context: > >> http://www.nabble.com/Attachment-tf3474259.html#a9697138 > >> Sent from the Apache Ode User mailing list archive at Nabble.com. > >> > >> > > > > > > -- > View this message in context: > http://www.nabble.com/Attachment-tf3474259.html#a9699010 > Sent from the Apache Ode User mailing list archive at Nabble.com. > >
