When we used Mina, we didn't find big performance issues.
Only a small problem:The performance will start to fall off after we
connect more that 30 cilents, i think that's bacause Mina maintains
long connections to the clients.
2009/4/11 Willem Jiang <willem.ji...@gmail.com>:
> Sorry, My first question should be
> 1. Which kind of the performance issue that you met when you used
> *Mina* as the communication component in the Mule ESB ?
>
> Willem
>
> Xueqiang Mi wrote:
>> Re Q1. One performance issure is of the XML parsing component. When we
>> transform one message type into others,especially on XML related
>> messages, the performance is undesirable. I think this problem is
>> ubiquitous in the Web Services integration or orchestration. We solve
>> it using the distributed Mule nodes to solve it.
>>
>> ReQ2.
>> Definition 1 Application Pattern defines a set of abstract services
>> and their running order in this pattern.
>> AP : = <id, cbr_ stamp, service_order, { service | where service is a
>> Service instance}>,
>> where
>> a) id is the identity of a pattern.
>> b) cbr_stamp presents the accepted message type of this pattern.
>> It can be configured by a simple expression, a Java class or an xml
>> file, e.g., message/header/request='travelAgency'.
>> c) service_order gives the invoking order of the services, using
>> service id and several symbols to express the running order, e.g., (0,
>> 1,),((0, 1) -> 2).
>> d) {service} lists all the services used by this pattern.
>> Definition 2 Service defines an abstract service, in which all
>> information of a service is maintained, such as input type, output
>> type, service address and the related transformer.
>> Service : = < id, input, output, spec, {transformer | where
>> transformer is a Transformer instance}>,
>> where
>> a) id is the identity of a service.
>> b) input specifies the request message type of this service.
>> c) output specifies the response message type.
>> d) {spec} contains the information of the service, such as the service
>> name and address, and it can be extended in specific application.
>> e) {transformer} lists all the transformers that may be used by this
>> service.
>> When receiving a message, PBDR will select an AP instance to process
>> it. The AP matching in PBDR is based on content-based routing. PBDR
>> will apply a matching expression to the messages to judge whether the
>> AP instance is fit. After an AP instance is selected, a service
>> executor module will invoke the related services by the order
>> confirmed in AP.
>>
>>
>>
>> 2009/4/11 Willem Jiang <willem.ji...@gmail.com>:
>>> Hi Xueqiang,
>>>
>>> Nice to talked with you through the Phone.
>>> I'm happy with you can devote next 4 month full work time for the GSoC.
>>> But I found you may mix up the Content Base Routing and Dynamical Routing.
>>>
>>> Can you answer me two questions ?
>>> 1. Which kind of the performance issue that you met when you used it as
>>> the communication component in the Mule ESB ?
>>>
>>> 2. Can you give me more information about the AP (Application Pattern)
>>> of your paper of "PBDR", how do you define the AP in the ESB?
>>>
>>> BTW,
>>>
>>> Since you may take some time to studey Groovy first, please add it in
>>> the time line of your proposal.
>>>
>>>
>>> Thanks,
>>>
>>> Willem
>>>
>>> The Abstract of PBDR: Pattern-Based Dynamic Routing
>>>
>>> Abstract - This paper proposes a pattern-based dynamic
>>> routing (PBDR) framework, which can support message
>>> routing not only by analyzing the message content, but also
>>> by referring to the application pattern (AP) defined on
>>> Enterprise Service Bus (ESB). PBDR can apply to many types
>>> of services or legacy systems, while current content-based
>>> routing (CBR) mechanisms only support standard Web
>>> Services.
>>> The PBDR framework introduces an AP concept into ESB for
>>> dynamic routing. Generally, PBDR maintains several APs at
>>> runtime, and by analyzing a request message, it will choose
>>> an appropriate one and invoke it to process the message.
>>> PBDR supplies workflow layer with independent services and
>>> supports application related routing by extending CBR with
>>> the AP concept.
>>>
>>>
>>>
>>> Hadrian Zbarcea wrote:
>>>> Willem, given the time zone difference could you please try to have an
>>>> interview with Xuegiang Mi?
>>>> Xuegiang Mi, could you please try to contact one of us?
>>>>
>>>> Thanks
>>>> Hadrian
>>>>
>>>> On Apr 10, 2009, at 11:16 AM, Hadrian Zbarcea wrote:
>>>>
>>>>> Xueqiang Mi, we need to have an interview. We would need to know more
>>>>> about you and it affects your score. Please try to find us either on
>>>>> irc or skype (if you use skipe you can paste your skype id here, or
>>>>> you can send me and/or Jon a private message with your id). You could
>>>>> also post here or in a private message a phone number and I could call
>>>>> you on a regular phone. Please let us know when it would be
>>>>> convenient for you to have such an interview (and keep in mind that we
>>>>> are in the US, at GMT-5).
>>>>>
>>>>> Please respond as soon as you can.
>>>>> Hadrian
>>>>>
>>>>> On Apr 8, 2009, at 9:34 AM, Jon Anstey wrote:
>>>>>
>>>>>> Cool stuff. So I guess you should start with Groovy for the dynamic
>>>>>> routing extension to the web console. Also, over the next few days (I
>>>>>> have until the 15th of April) I'll add the extra ranking points to
>>>>>> your proposal.
>>>>>>
>>>>>>
>>>>>> 2009/4/8 宓学强 <allo...@gmail.com <mailto:allo...@gmail.com>>
>>>>>>
>>>>>> I am more interested in Dynamic routes project!
>>>>>>
>>>>>> 2009/4/8 Hadrian Zbarcea <hzbar...@gmail.com
>>>>>> <mailto:hzbar...@gmail.com>>:
>>>>>> > I think we should start with Groovy, Python and Ruby. It's
>>>>>> hard to decide
>>>>>> > on priorities, every time I try to, I feel like changing the
>>>>>> order. If you
>>>>>> > have a preference please let us know. After we get the AST it
>>>>>> should be all
>>>>>> > the same.
>>>>>> >
>>>>>> > Btw, one of the first things we need to do is decide which of
>>>>>> the 2 projects
>>>>>> > is of more interest to you so we would know how to rank it.
>>>>>> >
>>>>>> > You can find me (and others) online on the #camel channel at
>>>>>> > irc.codehaus.org <http://irc.codehaus.org> if you'd like to
>>>>>> chat about it.
>>>>>> >
>>>>>> > Cheers
>>>>>> > Hadrian
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > On Apr 6, 2009, at 9:55 AM, 宓学强 wrote:
>>>>>> >
>>>>>> >> I wonder which dynamic language should we add for the Dynamic
>>>>>> route
>>>>>> >> support,Groovy,Ruby,Python or Scala?
>>>>>> >> Hope every one can give the opinion and we can negotiate to
>>>>>> decide that.
>>>>>> >>
>>>>>> >>
>>>>>> >> --
>>>>>> >> 宓学强 allo...@gmail.com <mailto:allo...@gmail.com>
>>>>>> >
>>>>>> >
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Xueqiang Mi <allo...@gmail.com <mailto:allo...@gmail.com>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Cheers,
>>>>>> Jon
>>>>>>
>>>>>> http://janstey.blogspot.com/
>>>
>>
>>
>>
>
>
--
Xueqiang Mi <allo...@gmail.com>
