MuleClient vs. MuleEventContext

[dialsc]

hello,

i'm wondering if there is any difference between using MuleClient and MuleEventContext to send|dispatch messages|events from one service component to another from the performance point of view.

we're developing a mule based platform and make a lot of usage of the MuleClient in our services components in order to consume other services. as the documentation tells using the MuleClient is not such a good idea in generell, should we rather be using MuleEventContext for this?

greez,

dialsc

[Dirk Olmes]

dialsc wrote:

> hello,
>
> i'm wondering if there is any difference between using MuleClient and
> MuleEventContext to send|dispatch messages|events from one service component
> to another from the performance point of view.
>
> we're developing a mule based platform and make a lot of usage of the
> MuleClient in our services components in order to consume other services. as
> the documentation tells using the MuleClient is not such a good idea in
> generell, should we rather be using MuleEventContext for this?

http://www.mulesoft.org/display/MULE2USER/Using+the+Mule+Client states:

> When Not to Use the Mule Client
>
> It's generally not good practice to make calls using the Mule client
from your service objects or within extensions to Mule such as routers
or transformers.
>
> When you need to dispatch or request events in Mule, you should use
the current org.mule.api.MuleEventContext and call the
send/dispatch/request methods on the context instead.


If you're sending to endpoints from your service components, you should
rather use service bindings
(http://www.mulesoft.org/display/MULE2USER/Component+Configuration+Reference)

-dirk

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Mario Flores-4]

Hello.

Reviewing the documentarion that dialsc sends, I see that also the MuleClient has the sendAsync method.

Anyone know the sendAsync method of MuleClient? Is still there and is not deprecated. I think it do similar functionality as the dispatch method. Is there any bad issue using the sendAsync????

Regards and thanks in advance.

Mario

Dirk Olmes wrote:

dialsc wrote:
  

hello,

i'm wondering if there is any difference between using MuleClient and
MuleEventContext to send|dispatch messages|events from one service component
to another from the performance point of view.

we're developing a mule based platform and make a lot of usage of the
MuleClient in our services components in order to consume other services. as
the documentation tells using the MuleClient is not such a good idea in
generell, should we rather be using MuleEventContext for this?
    

http://www.mulesoft.org/display/MULE2USER/Using+the+Mule+Client states:

  

When Not to Use the Mule Client

It's generally not good practice to make calls using the Mule client
    

from your service objects or within extensions to Mule such as routers
or transformers.
  

When you need to dispatch or request events in Mule, you should use
    

the current org.mule.api.MuleEventContext and call the
send/dispatch/request methods on the context instead.


If you're sending to endpoints from your service components, you should
rather use service bindings
(http://www.mulesoft.org/display/MULE2USER/Component+Configuration+Reference)

-dirk

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email




  

[antoine.borg]

It's not quite the same - if you use dispatch () on a synchronous
endpoint you'll get an exception.  You must, therefore, use send().  
What if you want to invoke a synchronous endpoint but not wait for the
reply? You'd want to use send() but act in an asynchronous manner (fire
and forget) - therefore use sendAsync ()

:-)

HTH

A

Mario Flores wrote:

> Hello.
>
> Reviewing the documentarion that dialsc sends, I see that also the
> MuleClient has the sendAsync method.
>
> Anyone know the sendAsync method of MuleClient? Is still there and is
> not deprecated. I think it do similar functionality as the dispatch
> method. Is there any bad issue using the sendAsync????
>
> Regards and thanks in advance.
>
> Mario
>
> Dirk Olmes wrote:
>> dialsc wrote:
>>  
>>> hello,
>>>
>>> i'm wondering if there is any difference between using MuleClient and
>>> MuleEventContext to send|dispatch messages|events from one service component
>>> to another from the performance point of view.
>>>
>>> we're developing a mule based platform and make a lot of usage of the
>>> MuleClient in our services components in order to consume other services. as
>>> the documentation tells using the MuleClient is not such a good idea in
>>> generell, should we rather be using MuleEventContext for this?
>>>    
>>
>> http://www.mulesoft.org/display/MULE2USER/Using+the+Mule+Client states:
>>
>>  
>>> When Not to Use the Mule Client
>>>
>>> It's generally not good practice to make calls using the Mule client
>>>    
>> from your service objects or within extensions to Mule such as routers
>> or transformers.
>>  
>>> When you need to dispatch or request events in Mule, you should use
>>>    
>> the current org.mule.api.MuleEventContext and call the
>> send/dispatch/request methods on the context instead.
>>
>>
>> If you're sending to endpoints from your service components, you should
>> rather use service bindings
>> (http://www.mulesoft.org/display/MULE2USER/Component+Configuration+Reference)
>>
>> -dirk
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>     http://xircles.codehaus.org/manage_email
>>
>>
>>
>>
>>  
>

--

Antoine Borg , Director of Services | Tel: [phone]
ricston Ltd., BP 2, 1180 Uccle, Brussels, BELGIUM
See our full schedule of Mule and Android courses online: Ricston Course
Schedules <http://www.ricston.com/courses/schedules>
email: antoine.borg@... <mailto:antoine.borg@...> |
twitter: twitter.com/antoinericston <http://www.twitter.com/antoinericston>
----------
* Disclaimer* - This email and any files transmitted with it are
confidential and contain privileged or copyright information. You must
not present this message to another party without first gaining
permission from the sender. If you are not the intended recipient you
must not copy, distribute or use this email or the information contained
in it for any purpose other than to notify us. If you have received this
message in error, please notify the sender immediately and delete this
email from your system. We do not guarantee that this material is free
from viruses or any other defects although due care has been taken to
minimise the risk. Any views stated in this communication are those of
the actual sender and not necessarily those of Ricston Ltd. or its
subsidiaries.


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email