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/
