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 <
[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]
> Enviado el: viernes, 04 de abril de 2008 10:10
> Para: [email protected]
> 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/

Reply via email to