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 <[email protected]>:
>> 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 宓学强 <[email protected] <mailto:[email protected]>>
>>>>>
>>>>> I am more interested in Dynamic routes project!
>>>>>
>>>>> 2009/4/8 Hadrian Zbarcea <[email protected]
>>>>> <mailto:[email protected]>>:
>>>>> > 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.
>>>>> >>
>>>>> >>
>>>>> >> --
>>>>> >> 宓学强 [email protected] <mailto:[email protected]>
>>>>> >
>>>>> >
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Xueqiang Mi <[email protected] <mailto:[email protected]>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Cheers,
>>>>> Jon
>>>>>
>>>>> http://janstey.blogspot.com/
>>
>
>
>
