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>
