You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@servicemix.apache.org by Raul Kripalani <ra...@atosorigin.com> on 2008/04/02 18:57:18 UTC
Creating mediation flows in ServiceMix
Hi,
I have a question regarding the creation of "mediation flows" within
ServiceMix, that is, chaining together validations, transformations,
mediations, aggregations, etc. in a sequence. I am aware this messaging
route can be achieved using the EIP Static Routing Slip pattern,
specifying the endpoints or services through which the message should
pass before reaching the final destination.
However I have noticed that every single validation, transformation or
mediation service needs to essentially be exposed as a *service* on the
ESB. Instead of having to do so, does ServiceMix offer a mechanism to
embed the different activities inside a mediation flow in an anonymous
manner, without having to expose each single activity as a service? I am
thinking of something equivalent to what Synapse/WSO2 calls "sequences".
The thing is that in my opinion, exposing each single activity or step
as a service on the bus kind of "clutters" the ESB, because in most
scenarios the activities not be reusable in other mediation flows, and,
on the other hand, architecturally speaking, they are too fine-grained
to be offered as services.
Apologies if I have got wrong information...
Thanks a lot,
Raul.
------------------------------------------------------------------
This e-mail and the documents attached are confidential and intended solely
for the addressee; it may also be privileged. If you receive this e-mail
in error, please notify the sender immediately and destroy it.
As its integrity cannot be secured on the Internet, the Atos Origin group
liability cannot be triggered for the message content. Although the
sender endeavours to maintain a computer virus-free network, the sender does
not warrant that this transmission is virus-free and will not be liable for
any damages resulting from any virus transmitted.
Este mensaje y los ficheros adjuntos pueden contener informacion
confidencial destinada solamente a la(s) persona(s) mencionadas
anteriormente. Pueden estar protegidos por secreto profesional Si usted
recibe este correo electronico por error, gracias de informar inmediatamente
al remitente y destruir el mensaje.
Al no estar asegurada la integridad de este mensaje sobre la red, Atos
Origin no se hace responsable por su contenido. Su contenido no constituye
ningun compromiso para el grupo Atos Origin, salvo ratificacion escrita por
ambas partes.
Aunque se esfuerza al maximo por mantener su red libre de virus, el emisor
no puede garantizar nada al respecto y no sera responsable de cualesquiera
danos que puedan resultar de una transmision de virus
------------------------------------------------------------------
Re: Creating mediation flows in ServiceMix
Posted by Gert Vanthienen <ge...@skynet.be>.
Raul,
That would be one approach for sure, but I was thinking you can also add
your bean and XSL file to the Camel SU and have Camel access it directly
instead of going over the ESB for them. As an example, have a look at
http://activemq.apache.org/camel/xslt.html. This shows you a route that
does XSL transformation without the need to address another service on
the ESB. You could also add your validation bean in a similar way using
Camel's bean component http://activemq.apache.org/camel/bean.html. If
you use these, you can avoid having to expose XSL/Bean services to the
ESB directly. You just expose the Camel route as a whole to the ESB to
make it available afterwards.
Does this clarify things?
Gert
Raul Kripalani wrote:
> Hi Gert,
>
> I understand your approach. However, say that if for validation I use a
> bean and for transformation I use a Saxon SU, each of these activities
> that is part of the mediation flow (which in turn are chained together
> using a Camel pipeline) will have to be exposed as an individual service
> on the ESB. Is this correct?
>
> Thanks,
>
> Raul.
>
> -----Mensaje original-----
> De: Gert Vanthienen [mailto:gert.vanthienen@skynet.be]
> Enviado el: viernes, 04 de abril de 2008 10:10
> Para: users@servicemix.apache.org
> Asunto: Re: Creating mediation flows in ServiceMix
>
> Raulvk,
>
> You could use Camel inside ServiceMix. Camel allows you to specify
> these flows in a Java DSL or XML format and you can expose the entire
> flow to the ESB as a single service by starting it with
> from("jbi:service:...") as is shown in this tutorial:
> http://servicemix.apache.org/3-beginner-using-apache-camel-inside-servic
> emix.html.
>
> Camel itself supports the EIP patterns and has a wide range of
> components available (including validation, transformation and
> logging). More information about Camel can be found at
> http://activemq.apache.org/camel
>
> Hth,
>
> Gert
>
>
> raulvk wrote:
>
>> Hi,
>>
>> Can someone give me a hand with this, please? Basically, what I would
>>
> like
>
>> to achieve is for each activity that is part of a mediation flow
>> (validation, transformation, logging, etc.), not to be exposed as
>>
> individual
>
>> services, but to be chained anonymously in a flow instead. Is this
>>
> possible
>
>> in ServiceMix?
>>
>> Thank you.
>>
>>
>> raulvk wrote:
>>
>>
>>> Hi,
>>>
>>>
>>>
>>> I have a question regarding the creation of "mediation flows" within
>>> ServiceMix, that is, chaining together validations, transformations,
>>> mediations, aggregations, etc. in a sequence. I am aware this
>>>
> messaging
>
>>> route can be achieved using the EIP Static Routing Slip pattern,
>>> specifying the endpoints or services through which the message should
>>> pass before reaching the final destination.
>>>
>>>
>>>
>>> However I have noticed that every single validation, transformation
>>>
> or
>
>>> mediation service needs to essentially be exposed as a *service* on
>>>
> the
>
>>> ESB. Instead of having to do so, does ServiceMix offer a mechanism to
>>> embed the different activities inside a mediation flow in an
>>>
> anonymous
>
>>> manner, without having to expose each single activity as a service? I
>>>
> am
>
>>> thinking of something equivalent to what Synapse/WSO2 calls
>>>
> "sequences".
>
>>>
>>>
>>> The thing is that in my opinion, exposing each single activity or
>>>
> step
>
>>> as a service on the bus kind of "clutters" the ESB, because in most
>>> scenarios the activities not be reusable in other mediation flows,
>>>
> and,
>
>>> on the other hand, architecturally speaking, they are too
>>>
> fine-grained
>
>>> to be offered as services.
>>>
>>>
>>>
>>> Apologies if I have got wrong information...
>>>
>>>
>>>
>>> Thanks a lot,
>>>
>>>
>>>
>>> Raul.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------
>>> This e-mail and the documents attached are confidential and intended
>>> solely
>>> for the addressee; it may also be privileged. If you receive this
>>>
> e-mail
>
>>> in error, please notify the sender immediately and destroy it.
>>> As its integrity cannot be secured on the Internet, the Atos Origin
>>>
> group
>
>>> liability cannot be triggered for the message content. Although the
>>> sender endeavours to maintain a computer virus-free network, the
>>>
> sender
>
>>> does
>>> not warrant that this transmission is virus-free and will not be
>>>
> liable
>
>>> for
>>> any damages resulting from any virus transmitted.
>>>
>>> Este mensaje y los ficheros adjuntos pueden contener informacion
>>> confidencial destinada solamente a la(s) persona(s) mencionadas
>>> anteriormente. Pueden estar protegidos por secreto profesional Si
>>>
> usted
>
>>> recibe este correo electronico por error, gracias de informar
>>> inmediatamente
>>> al remitente y destruir el mensaje.
>>> Al no estar asegurada la integridad de este mensaje sobre la red,
>>>
> Atos
>
>>> Origin no se hace responsable por su contenido. Su contenido no
>>>
> constituye
>
>>> ningun compromiso para el grupo Atos Origin, salvo ratificacion
>>>
> escrita
>
>>> por
>>> ambas partes.
>>> Aunque se esfuerza al maximo por mantener su red libre de virus, el
>>>
> emisor
>
>>> no puede garantizar nada al respecto y no sera responsable de
>>>
> cualesquiera
>
>>> danos que puedan resultar de una transmision de virus
>>> ------------------------------------------------------------------
>>>
>>>
>>>
>>>
>>
>>
>
>
>
> ------------------------------------------------------------------
> This e-mail and the documents attached are confidential and intended solely
> for the addressee; it may also be privileged. If you receive this e-mail
> in error, please notify the sender immediately and destroy it.
> As its integrity cannot be secured on the Internet, the Atos Origin group
> liability cannot be triggered for the message content. Although the
> sender endeavours to maintain a computer virus-free network, the sender does
> not warrant that this transmission is virus-free and will not be liable for
> any damages resulting from any virus transmitted.
>
> Este mensaje y los ficheros adjuntos pueden contener informacion
> confidencial destinada solamente a la(s) persona(s) mencionadas
> anteriormente. Pueden estar protegidos por secreto profesional Si usted
> recibe este correo electronico por error, gracias de informar inmediatamente
> al remitente y destruir el mensaje.
> Al no estar asegurada la integridad de este mensaje sobre la red, Atos
> Origin no se hace responsable por su contenido. Su contenido no constituye
> ningun compromiso para el grupo Atos Origin, salvo ratificacion escrita por
> ambas partes.
> Aunque se esfuerza al maximo por mantener su red libre de virus, el emisor
> no puede garantizar nada al respecto y no sera responsable de cualesquiera
> danos que puedan resultar de una transmision de virus
> ------------------------------------------------------------------
>
>
Re: Creating mediation flows in ServiceMix
Posted by Guillaume Nodet <gn...@gmail.com>.
This is correct, however they are only exposed internally, meaning there's
no way to access it unless they are explicitely exposed to the outside world
using a known protocol like HTTP or JMS. So from the service consumer point
of view, they are not really exposed.
On Fri, Apr 4, 2008 at 11:17 AM, Raul Kripalani <
raul.kripalani@atosorigin.com> wrote:
> Hi Gert,
>
> I understand your approach. However, say that if for validation I use a
> bean and for transformation I use a Saxon SU, each of these activities
> that is part of the mediation flow (which in turn are chained together
> using a Camel pipeline) will have to be exposed as an individual service
> on the ESB. Is this correct?
>
> Thanks,
>
> Raul.
>
> -----Mensaje original-----
> De: Gert Vanthienen [mailto:gert.vanthienen@skynet.be]
> Enviado el: viernes, 04 de abril de 2008 10:10
> Para: users@servicemix.apache.org
> Asunto: Re: Creating mediation flows in ServiceMix
>
> Raulvk,
>
> You could use Camel inside ServiceMix. Camel allows you to specify
> these flows in a Java DSL or XML format and you can expose the entire
> flow to the ESB as a single service by starting it with
> from("jbi:service:...") as is shown in this tutorial:
> http://servicemix.apache.org/3-beginner-using-apache-camel-inside-servic
> emix.html<http://servicemix.apache.org/3-beginner-using-apache-camel-inside-servicemix.html>
> .
>
> Camel itself supports the EIP patterns and has a wide range of
> components available (including validation, transformation and
> logging). More information about Camel can be found at
> http://activemq.apache.org/camel
>
> Hth,
>
> Gert
>
>
> raulvk wrote:
> > Hi,
> >
> > Can someone give me a hand with this, please? Basically, what I would
> like
> > to achieve is for each activity that is part of a mediation flow
> > (validation, transformation, logging, etc.), not to be exposed as
> individual
> > services, but to be chained anonymously in a flow instead. Is this
> possible
> > in ServiceMix?
> >
> > Thank you.
> >
> >
> > raulvk wrote:
> >
> >> Hi,
> >>
> >>
> >>
> >> I have a question regarding the creation of "mediation flows" within
> >> ServiceMix, that is, chaining together validations, transformations,
> >> mediations, aggregations, etc. in a sequence. I am aware this
> messaging
> >> route can be achieved using the EIP Static Routing Slip pattern,
> >> specifying the endpoints or services through which the message should
> >> pass before reaching the final destination.
> >>
> >>
> >>
> >> However I have noticed that every single validation, transformation
> or
> >> mediation service needs to essentially be exposed as a *service* on
> the
> >> ESB. Instead of having to do so, does ServiceMix offer a mechanism to
> >> embed the different activities inside a mediation flow in an
> anonymous
> >> manner, without having to expose each single activity as a service? I
> am
> >> thinking of something equivalent to what Synapse/WSO2 calls
> "sequences".
> >>
> >>
> >>
> >> The thing is that in my opinion, exposing each single activity or
> step
> >> as a service on the bus kind of "clutters" the ESB, because in most
> >> scenarios the activities not be reusable in other mediation flows,
> and,
> >> on the other hand, architecturally speaking, they are too
> fine-grained
> >> to be offered as services.
> >>
> >>
> >>
> >> Apologies if I have got wrong information...
> >>
> >>
> >>
> >> Thanks a lot,
> >>
> >>
> >>
> >> Raul.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> ------------------------------------------------------------------
> >> This e-mail and the documents attached are confidential and intended
> >> solely
> >> for the addressee; it may also be privileged. If you receive this
> e-mail
> >> in error, please notify the sender immediately and destroy it.
> >> As its integrity cannot be secured on the Internet, the Atos Origin
> group
> >> liability cannot be triggered for the message content. Although the
> >> sender endeavours to maintain a computer virus-free network, the
> sender
> >> does
> >> not warrant that this transmission is virus-free and will not be
> liable
> >> for
> >> any damages resulting from any virus transmitted.
> >>
> >> Este mensaje y los ficheros adjuntos pueden contener informacion
> >> confidencial destinada solamente a la(s) persona(s) mencionadas
> >> anteriormente. Pueden estar protegidos por secreto profesional Si
> usted
> >> recibe este correo electronico por error, gracias de informar
> >> inmediatamente
> >> al remitente y destruir el mensaje.
> >> Al no estar asegurada la integridad de este mensaje sobre la red,
> Atos
> >> Origin no se hace responsable por su contenido. Su contenido no
> constituye
> >> ningun compromiso para el grupo Atos Origin, salvo ratificacion
> escrita
> >> por
> >> ambas partes.
> >> Aunque se esfuerza al maximo por mantener su red libre de virus, el
> emisor
> >> no puede garantizar nada al respecto y no sera responsable de
> cualesquiera
> >> danos que puedan resultar de una transmision de virus
> >> ------------------------------------------------------------------
> >>
> >>
> >>
> >
> >
>
>
>
> ------------------------------------------------------------------
> This e-mail and the documents attached are confidential and intended
> solely
> for the addressee; it may also be privileged. If you receive this e-mail
> in error, please notify the sender immediately and destroy it.
> As its integrity cannot be secured on the Internet, the Atos Origin group
> liability cannot be triggered for the message content. Although the
> sender endeavours to maintain a computer virus-free network, the sender
> does
> not warrant that this transmission is virus-free and will not be liable
> for
> any damages resulting from any virus transmitted.
>
> Este mensaje y los ficheros adjuntos pueden contener informacion
> confidencial destinada solamente a la(s) persona(s) mencionadas
> anteriormente. Pueden estar protegidos por secreto profesional Si usted
> recibe este correo electronico por error, gracias de informar
> inmediatamente
> al remitente y destruir el mensaje.
> Al no estar asegurada la integridad de este mensaje sobre la red, Atos
> Origin no se hace responsable por su contenido. Su contenido no constituye
> ningun compromiso para el grupo Atos Origin, salvo ratificacion escrita
> por
> ambas partes.
> Aunque se esfuerza al maximo por mantener su red libre de virus, el emisor
> no puede garantizar nada al respecto y no sera responsable de cualesquiera
> danos que puedan resultar de una transmision de virus
> ------------------------------------------------------------------
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
RE: Creating mediation flows in ServiceMix
Posted by Raul Kripalani <ra...@atosorigin.com>.
Hi Gert,
I understand your approach. However, say that if for validation I use a
bean and for transformation I use a Saxon SU, each of these activities
that is part of the mediation flow (which in turn are chained together
using a Camel pipeline) will have to be exposed as an individual service
on the ESB. Is this correct?
Thanks,
Raul.
-----Mensaje original-----
De: Gert Vanthienen [mailto:gert.vanthienen@skynet.be]
Enviado el: viernes, 04 de abril de 2008 10:10
Para: users@servicemix.apache.org
Asunto: Re: Creating mediation flows in ServiceMix
Raulvk,
You could use Camel inside ServiceMix. Camel allows you to specify
these flows in a Java DSL or XML format and you can expose the entire
flow to the ESB as a single service by starting it with
from("jbi:service:...") as is shown in this tutorial:
http://servicemix.apache.org/3-beginner-using-apache-camel-inside-servic
emix.html.
Camel itself supports the EIP patterns and has a wide range of
components available (including validation, transformation and
logging). More information about Camel can be found at
http://activemq.apache.org/camel
Hth,
Gert
raulvk wrote:
> Hi,
>
> Can someone give me a hand with this, please? Basically, what I would
like
> to achieve is for each activity that is part of a mediation flow
> (validation, transformation, logging, etc.), not to be exposed as
individual
> services, but to be chained anonymously in a flow instead. Is this
possible
> in ServiceMix?
>
> Thank you.
>
>
> raulvk wrote:
>
>> Hi,
>>
>>
>>
>> I have a question regarding the creation of "mediation flows" within
>> ServiceMix, that is, chaining together validations, transformations,
>> mediations, aggregations, etc. in a sequence. I am aware this
messaging
>> route can be achieved using the EIP Static Routing Slip pattern,
>> specifying the endpoints or services through which the message should
>> pass before reaching the final destination.
>>
>>
>>
>> However I have noticed that every single validation, transformation
or
>> mediation service needs to essentially be exposed as a *service* on
the
>> ESB. Instead of having to do so, does ServiceMix offer a mechanism to
>> embed the different activities inside a mediation flow in an
anonymous
>> manner, without having to expose each single activity as a service? I
am
>> thinking of something equivalent to what Synapse/WSO2 calls
"sequences".
>>
>>
>>
>> The thing is that in my opinion, exposing each single activity or
step
>> as a service on the bus kind of "clutters" the ESB, because in most
>> scenarios the activities not be reusable in other mediation flows,
and,
>> on the other hand, architecturally speaking, they are too
fine-grained
>> to be offered as services.
>>
>>
>>
>> Apologies if I have got wrong information...
>>
>>
>>
>> Thanks a lot,
>>
>>
>>
>> Raul.
>>
>>
>>
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------
>> This e-mail and the documents attached are confidential and intended
>> solely
>> for the addressee; it may also be privileged. If you receive this
e-mail
>> in error, please notify the sender immediately and destroy it.
>> As its integrity cannot be secured on the Internet, the Atos Origin
group
>> liability cannot be triggered for the message content. Although the
>> sender endeavours to maintain a computer virus-free network, the
sender
>> does
>> not warrant that this transmission is virus-free and will not be
liable
>> for
>> any damages resulting from any virus transmitted.
>>
>> Este mensaje y los ficheros adjuntos pueden contener informacion
>> confidencial destinada solamente a la(s) persona(s) mencionadas
>> anteriormente. Pueden estar protegidos por secreto profesional Si
usted
>> recibe este correo electronico por error, gracias de informar
>> inmediatamente
>> al remitente y destruir el mensaje.
>> Al no estar asegurada la integridad de este mensaje sobre la red,
Atos
>> Origin no se hace responsable por su contenido. Su contenido no
constituye
>> ningun compromiso para el grupo Atos Origin, salvo ratificacion
escrita
>> por
>> ambas partes.
>> Aunque se esfuerza al maximo por mantener su red libre de virus, el
emisor
>> no puede garantizar nada al respecto y no sera responsable de
cualesquiera
>> danos que puedan resultar de una transmision de virus
>> ------------------------------------------------------------------
>>
>>
>>
>
>
------------------------------------------------------------------
This e-mail and the documents attached are confidential and intended solely
for the addressee; it may also be privileged. If you receive this e-mail
in error, please notify the sender immediately and destroy it.
As its integrity cannot be secured on the Internet, the Atos Origin group
liability cannot be triggered for the message content. Although the
sender endeavours to maintain a computer virus-free network, the sender does
not warrant that this transmission is virus-free and will not be liable for
any damages resulting from any virus transmitted.
Este mensaje y los ficheros adjuntos pueden contener informacion
confidencial destinada solamente a la(s) persona(s) mencionadas
anteriormente. Pueden estar protegidos por secreto profesional Si usted
recibe este correo electronico por error, gracias de informar inmediatamente
al remitente y destruir el mensaje.
Al no estar asegurada la integridad de este mensaje sobre la red, Atos
Origin no se hace responsable por su contenido. Su contenido no constituye
ningun compromiso para el grupo Atos Origin, salvo ratificacion escrita por
ambas partes.
Aunque se esfuerza al maximo por mantener su red libre de virus, el emisor
no puede garantizar nada al respecto y no sera responsable de cualesquiera
danos que puedan resultar de una transmision de virus
------------------------------------------------------------------
Re: Creating mediation flows in ServiceMix
Posted by Gert Vanthienen <ge...@skynet.be>.
Raulvk,
You could use Camel inside ServiceMix. Camel allows you to specify
these flows in a Java DSL or XML format and you can expose the entire
flow to the ESB as a single service by starting it with
from("jbi:service:...") as is shown in this tutorial:
http://servicemix.apache.org/3-beginner-using-apache-camel-inside-servicemix.html.
Camel itself supports the EIP patterns and has a wide range of
components available (including validation, transformation and
logging). More information about Camel can be found at
http://activemq.apache.org/camel
Hth,
Gert
raulvk wrote:
> Hi,
>
> Can someone give me a hand with this, please? Basically, what I would like
> to achieve is for each activity that is part of a mediation flow
> (validation, transformation, logging, etc.), not to be exposed as individual
> services, but to be chained anonymously in a flow instead. Is this possible
> in ServiceMix?
>
> Thank you.
>
>
> raulvk wrote:
>
>> Hi,
>>
>>
>>
>> I have a question regarding the creation of "mediation flows" within
>> ServiceMix, that is, chaining together validations, transformations,
>> mediations, aggregations, etc. in a sequence. I am aware this messaging
>> route can be achieved using the EIP Static Routing Slip pattern,
>> specifying the endpoints or services through which the message should
>> pass before reaching the final destination.
>>
>>
>>
>> However I have noticed that every single validation, transformation or
>> mediation service needs to essentially be exposed as a *service* on the
>> ESB. Instead of having to do so, does ServiceMix offer a mechanism to
>> embed the different activities inside a mediation flow in an anonymous
>> manner, without having to expose each single activity as a service? I am
>> thinking of something equivalent to what Synapse/WSO2 calls "sequences".
>>
>>
>>
>> The thing is that in my opinion, exposing each single activity or step
>> as a service on the bus kind of "clutters" the ESB, because in most
>> scenarios the activities not be reusable in other mediation flows, and,
>> on the other hand, architecturally speaking, they are too fine-grained
>> to be offered as services.
>>
>>
>>
>> Apologies if I have got wrong information...
>>
>>
>>
>> Thanks a lot,
>>
>>
>>
>> Raul.
>>
>>
>>
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------
>> This e-mail and the documents attached are confidential and intended
>> solely
>> for the addressee; it may also be privileged. If you receive this e-mail
>> in error, please notify the sender immediately and destroy it.
>> As its integrity cannot be secured on the Internet, the Atos Origin group
>> liability cannot be triggered for the message content. Although the
>> sender endeavours to maintain a computer virus-free network, the sender
>> does
>> not warrant that this transmission is virus-free and will not be liable
>> for
>> any damages resulting from any virus transmitted.
>>
>> Este mensaje y los ficheros adjuntos pueden contener informacion
>> confidencial destinada solamente a la(s) persona(s) mencionadas
>> anteriormente. Pueden estar protegidos por secreto profesional Si usted
>> recibe este correo electronico por error, gracias de informar
>> inmediatamente
>> al remitente y destruir el mensaje.
>> Al no estar asegurada la integridad de este mensaje sobre la red, Atos
>> Origin no se hace responsable por su contenido. Su contenido no constituye
>> ningun compromiso para el grupo Atos Origin, salvo ratificacion escrita
>> por
>> ambas partes.
>> Aunque se esfuerza al maximo por mantener su red libre de virus, el emisor
>> no puede garantizar nada al respecto y no sera responsable de cualesquiera
>> danos que puedan resultar de una transmision de virus
>> ------------------------------------------------------------------
>>
>>
>>
>
>
Re: Creating mediation flows in ServiceMix
Posted by raulvk <ra...@atosorigin.com>.
Hi,
Can someone give me a hand with this, please? Basically, what I would like
to achieve is for each activity that is part of a mediation flow
(validation, transformation, logging, etc.), not to be exposed as individual
services, but to be chained anonymously in a flow instead. Is this possible
in ServiceMix?
Thank you.
raulvk wrote:
>
> Hi,
>
>
>
> I have a question regarding the creation of "mediation flows" within
> ServiceMix, that is, chaining together validations, transformations,
> mediations, aggregations, etc. in a sequence. I am aware this messaging
> route can be achieved using the EIP Static Routing Slip pattern,
> specifying the endpoints or services through which the message should
> pass before reaching the final destination.
>
>
>
> However I have noticed that every single validation, transformation or
> mediation service needs to essentially be exposed as a *service* on the
> ESB. Instead of having to do so, does ServiceMix offer a mechanism to
> embed the different activities inside a mediation flow in an anonymous
> manner, without having to expose each single activity as a service? I am
> thinking of something equivalent to what Synapse/WSO2 calls "sequences".
>
>
>
> The thing is that in my opinion, exposing each single activity or step
> as a service on the bus kind of "clutters" the ESB, because in most
> scenarios the activities not be reusable in other mediation flows, and,
> on the other hand, architecturally speaking, they are too fine-grained
> to be offered as services.
>
>
>
> Apologies if I have got wrong information...
>
>
>
> Thanks a lot,
>
>
>
> Raul.
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------
> This e-mail and the documents attached are confidential and intended
> solely
> for the addressee; it may also be privileged. If you receive this e-mail
> in error, please notify the sender immediately and destroy it.
> As its integrity cannot be secured on the Internet, the Atos Origin group
> liability cannot be triggered for the message content. Although the
> sender endeavours to maintain a computer virus-free network, the sender
> does
> not warrant that this transmission is virus-free and will not be liable
> for
> any damages resulting from any virus transmitted.
>
> Este mensaje y los ficheros adjuntos pueden contener informacion
> confidencial destinada solamente a la(s) persona(s) mencionadas
> anteriormente. Pueden estar protegidos por secreto profesional Si usted
> recibe este correo electronico por error, gracias de informar
> inmediatamente
> al remitente y destruir el mensaje.
> Al no estar asegurada la integridad de este mensaje sobre la red, Atos
> Origin no se hace responsable por su contenido. Su contenido no constituye
> ningun compromiso para el grupo Atos Origin, salvo ratificacion escrita
> por
> ambas partes.
> Aunque se esfuerza al maximo por mantener su red libre de virus, el emisor
> no puede garantizar nada al respecto y no sera responsable de cualesquiera
> danos que puedan resultar de una transmision de virus
> ------------------------------------------------------------------
>
>
--
View this message in context: http://www.nabble.com/Creating-mediation-flows-in-ServiceMix-tp16456270p16489239.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.