Conversational POJOs (was Re: Thoughts on a JBI POJO Engine
Just another brainstorm; I thought we should split this thread into
two; one for POJOs mapping to JBI/JSR 181/AnDI and another to doing
conversations/orchestration/workflow.
So we've got BeanFlow for writing POJO based workflows; I was
wondering about how we could link that to JBI POJOS (supporting JBI /
JSR 181 / AnDI annotations etc).
Here's a quick brainstorm. The basic idea is to introduce a little
POJO wrapper for an asynchronous JBI message exchange (a
request-response or one way which could take time to complete etc).
This POJO would implement the Activity interface from BeanFlow so we
could easily use it in a full workflow if desired. Then this POJO
would also be tied to a specific Destination. Also this POJO would be
injected by the container.
Many workflows only require making a single request on a number of
different endpoints - e.g. the following example talks to A, then
after thats complete, talks to B and C in parallel then when both of
those complete we talk to D. If we need to keep re-requesting services
we could reset the ExchangeActivity maybe (or just go back to using
the Destination directly).
So here's a little example...
public class MyWorkflow {
@Endpoint(service:foo) ExchangeActivity a;
@Endpoint(jms://activemq/foo.bar) ExchangeActivity b;
@Endpoint(service:bar) ExchangeActivity c;
@Endpoint(service:xyz) ExchangeActivity d;
@PostConstruct
public void start() {
NormalizedMessage message = a.createInMessage();
message.setContent(new StringSource(helloworld!/hello));
...
a.request(message);
}
@Join
public void onJoin(Activity exchange) {
if (exchange == a) {
// lets fire off to be and c
b.request(createRequestB());
c.request(createRequestC());
}
else if (b.isComplete() c.isComplete()) {
d.request(createRequestD());
}
}
So requests are all asynchronous and we get a join callback when any
of the exchanges (or other arbirary activities) change
(complete/fail/timeout) so we can perform whatever join conditions we
need.
I did ponder about using annotations to create methods for
'aComplete()' and 'bAndCComplete()' but it seems easier to use Java
code for boolean logic. The downside of this though is its not easily
possible to create tooling visualisations of this workflow.
We could use some kind of join language though so we could rewrite the
join logic as
@Join(a)
public void completedA() {
b.request(createRequestB());
c.request(createRequestC());
}
@Join(b and c)
public void completedBandC() {
d.request(createRequestD());
}
where the of a, b, c would resolve to properties or fields which must
return instances of type Activity from BeanFlow.
The nice thing about this use of @Join is that it would work with any
BeanFlow construct, JBI or otherwise. Then we are only really
introducing a POJO ExchangeActivity and an annotation to inject it
based on a destination URI (@Endpoint).
Am not particularly wedded to the names of ExchangeActivity and
@Endpoint but it was the best I could come up with without having too
much coffee yet. We might want to split @Endpoint into a couple of
tags as we might want to include both the endpoint URI and the type of
the request, InOut/InOnly etc.
Thoughts?
--
James
---
http://radio.weblogs.com/0112098/
Re: Thoughts on a JBI POJO Engine
James,
I like the idea of sticking to the JSR's where possible - and in fact
I'll run over JSR-250 to see what we can use. Also I agree that the
EJB3/SCA style resource injection might be better - one of the reasons
for the more verbal example was just to make it clear a little more
clear what was going on :)
As for the exchange processor mapping I think that the second option,
with annotated parameters looks sweet, and would also give us a
little room for doing some neat mapping stuff like -
@ExchangeProcessor
public void foo(@MessageContentXPath(\customer\name) String name)
{
}
This this would allow mapping of a payload to a method, however
when if comes to JAXB2 type mappings and the SomeResponse/SomeRequest
example you put in - I'm not sure that this isn't stepping on the toes
of the SCA/JSR-181 Service Engines? I suppose one of the things here
was providing:
a) a clean mechanism for writing POJO's that what to interact with the
JBI infrastructure and have been specifically implemented to do so
b) POJO's that what to interact with messaging (not XML-RPC) but more
akin to legacy messaging structures that are being passed around and
allowing you to persist them.
However, I can see that the JAXB example would be interesting since
you could generate any structure. Also in the second example when you
use the mapping approach - how do you know which MEP's the POJO can
handle?
P
On 8/21/06, James Strachan [EMAIL PROTECTED] wrote:
Just a bit of brainstorming of ideas here.
I was looking at this example
@ExchangeProcessor(patterns = { MessageExchangePattern.INOUT },
parameterMappings = { ParameterMapping.IN_MESSAGE_CONTENT })
public void myInOutProcessor(MessageExchange me) {
// Do something here
}
@ExchangeProcessor(patterns = { MessageExchangePattern.INONLY,
MessageExchangePattern.ROBUSTINOULY },
parameterMappings = {
ParameterMapping.IN_MESSAGE_CONTENT })
public void myInOnlyProcessor(Source payload) {
// Do something here
}
and wondering how to simplify a little.
My first thought was to use an annotation for each kind of exchange to
be supported...
@InOnlyExchange @RobustInOnlyExchange
public void foo(MessageExchange exchange) {
}
(I realised we'd get class name clashes so added the 'Exchange'
postfix to the annotation names. Then I figured it might be simpler to
just use a typesafe API...
@ExchangeProcessor
public void foo(InOnly exchange) {
}
@ExchangeProcessor
public void bar(RobustInOnly exchange) {
}
I guess sometimes folks might not want to see/use the exchange or
might wish to support multiple patterns for one method so some kinda
annotation to indicate the exchange pattern is still useful.
Also how about annotating parameters as being bound to the exchange...
@ExchangeProcessor
public void foo(@MessageProperty('cheese') String foo,
@ExchangeProperty(beer) Integer bar, @MessageContent Source payload)
{
}
While the @MessageContent may at first not appear that useful, we
could allow some automatic tranformations from common types to message
contents such as DOM or JAXB marshalling etc
e.g.
@ExchangeProcessor
public SomeResponse doSomething(@MessageBody SomeRequest foo) { ... }
where SomeRequest and SomeResponse could be marshalled to/from Source via JAXB2.
This would allow folks to process exchanges without using any of the
JBI APIs if they wish - or inject a MessageExchange or
NormalizedMessage into a parameter if required.
On 8/21/06, James Strachan [EMAIL PROTECTED] wrote:
Great stuff Philip!
More feedback as I start digesting this fully and reading this whole
thread but my first reaction is could we try to stick to standard
annotations where possible - such as those defined in JSR 250? e.g.
http://geronimo.apache.org/xbean/annotation-based-dependency-injection.html
so
@ServiceStartup - @PostConstruct
@ServiceShutdown - @PreDestroy
am also wondering how many of the other annotations are really
required on injected fields - could we just use @Resource to indicate
stuff that is mandatory to be dependency injected (like EJB3s). I'm
sure some of the annotations are required though; am just wondering
how many of them are
On 8/18/06, Philip Dodds [EMAIL PROTECTED] wrote:
I have knocked up some thoughts on a JBI POJO engine that could be
used to provide a mechanism for annotating POJO specifically for more
messaging level operations that the JSR181 service engine is aimed
for.
The idea is to provide a simple framework to replace the Spring Client
Toolkit that is now defunt.
Have a look at the idea -
http://goopen.org/confluence/display/SM/JBI+Pojo+Service+Engine
And all comments/thoughts are welcome!!
P
--
James
---
http://radio.weblogs.com/0112098/
--
James
---
http://radio.weblogs.com/0112098/
Re: Thoughts on a JBI POJO Engine
On 8/21/06, Philip Dodds [EMAIL PROTECTED] wrote:
James,
I like the idea of sticking to the JSR's where possible - and in fact
I'll run over JSR-250 to see what we can use. Also I agree that the
EJB3/SCA style resource injection might be better - one of the reasons
for the more verbal example was just to make it clear a little more
clear what was going on :)
Agreed. I think some of the resources injected will need their own
annotations. EJB3 does this for a few kinds of resources too. I'd be
cool if we could avoid custom annotations where possible though.
There seems to be some inconsistency in the use of annotations in this
area - some specs insist on new annotations others just use @Resource
- i've never quite figured out the reasoning behind the difference :).
As for the exchange processor mapping I think that the second option,
with annotated parameters looks sweet, and would also give us a
little room for doing some neat mapping stuff like -
@ExchangeProcessor
public void foo(@MessageContentXPath(\customer\name) String name)
{
}
Ooh thats neat - I like that! :)
This this would allow mapping of a payload to a method, however
when if comes to JAXB2 type mappings and the SomeResponse/SomeRequest
example you put in - I'm not sure that this isn't stepping on the toes
of the SCA/JSR-181 Service Engines?
Yeah.
I guess ultimately I'd like application developers to not have to
mentally think about switching from SCA ot JSR 181 to JBI too much;
they should hopefully have similar look and feels. It'd be nice to
have a kinda unified set of annotations to use or at least share as
many as possible. So hopefully we could reuse JAXB2 across all 3
models; SCA, JBI and JSR 181.
So for mapping the content of a NormalizedMessage it'd be good to support
* Source
* DOM / dom4j / XOM et al
* SDO
* JAXB2/XStream
* maybe text?
e.g. if using the JBI annotations I don't see why we can't also use
the JAXB2 mapping stuff.
We might wanna use XPath with JAXB2 as well...
I suppose one of the things here
was providing:
a) a clean mechanism for writing POJO's that what to interact with the
JBI infrastructure and have been specifically implemented to do so
b) POJO's that what to interact with messaging (not XML-RPC) but more
akin to legacy messaging structures that are being passed around and
allowing you to persist them.
However, I can see that the JAXB example would be interesting since
you could generate any structure. Also in the second example when you
use the mapping approach - how do you know which MEP's the POJO can
handle?
I figured if a result is returned then it'd be an InOut by default
unless an annotation is added to explicitly specify the MEP such as
InOptionalOut
So we could write an InOut processor as
@ExchangeProcessor
public Document foo(Document in, @MessageParam String foo) {... }
--
James
---
http://radio.weblogs.com/0112098/
Re: Thoughts on a JBI POJO Engine
Brainstorming again - here's some thoughts on some sensible defaults
we could use for MEPs to keep things as simple as possible...
By default methods which are void are InOnly and methods that are
non-void are InOut unless there is a typesafe MessageExchange
parameter or an annotation used to overload things.
e.g. these are InOnly...
@ExchangeProcessor
void foo(MessageExchange e) {}
@ExchangeProcessor
void foo(InOnly e) {}
@ExchangeProcessor
void foo(@MessageContent Document doc) {}
// these are InOut
@ExchangeProcessor
void foo(InOut e) {}
@ExchangeProcessor
Document foo(@MessageContent Document doc) {}
@ExchangeProcessor(pattern=Pattern.IN_OUT)
void foo(MessageExchange e) {}
etc
I wonder if we should support parameters for the in and out values? e.g.
@ExchangeProcessor
void foo(@In NormalizedMessage in, @Out NormalizedMessage) {}
or
@ExchangeProcessor
void foo(@MessageContent Document in, @OutMessageContent Document out) {}
On 8/21/06, James Strachan [EMAIL PROTECTED] wrote:
On 8/21/06, Philip Dodds [EMAIL PROTECTED] wrote:
James,
I like the idea of sticking to the JSR's where possible - and in fact
I'll run over JSR-250 to see what we can use. Also I agree that the
EJB3/SCA style resource injection might be better - one of the reasons
for the more verbal example was just to make it clear a little more
clear what was going on :)
Agreed. I think some of the resources injected will need their own
annotations. EJB3 does this for a few kinds of resources too. I'd be
cool if we could avoid custom annotations where possible though.
There seems to be some inconsistency in the use of annotations in this
area - some specs insist on new annotations others just use @Resource
- i've never quite figured out the reasoning behind the difference :).
As for the exchange processor mapping I think that the second option,
with annotated parameters looks sweet, and would also give us a
little room for doing some neat mapping stuff like -
@ExchangeProcessor
public void foo(@MessageContentXPath(\customer\name) String name)
{
}
Ooh thats neat - I like that! :)
This this would allow mapping of a payload to a method, however
when if comes to JAXB2 type mappings and the SomeResponse/SomeRequest
example you put in - I'm not sure that this isn't stepping on the toes
of the SCA/JSR-181 Service Engines?
Yeah.
I guess ultimately I'd like application developers to not have to
mentally think about switching from SCA ot JSR 181 to JBI too much;
they should hopefully have similar look and feels. It'd be nice to
have a kinda unified set of annotations to use or at least share as
many as possible. So hopefully we could reuse JAXB2 across all 3
models; SCA, JBI and JSR 181.
So for mapping the content of a NormalizedMessage it'd be good to support
* Source
* DOM / dom4j / XOM et al
* SDO
* JAXB2/XStream
* maybe text?
e.g. if using the JBI annotations I don't see why we can't also use
the JAXB2 mapping stuff.
We might wanna use XPath with JAXB2 as well...
I suppose one of the things here
was providing:
a) a clean mechanism for writing POJO's that what to interact with the
JBI infrastructure and have been specifically implemented to do so
b) POJO's that what to interact with messaging (not XML-RPC) but more
akin to legacy messaging structures that are being passed around and
allowing you to persist them.
However, I can see that the JAXB example would be interesting since
you could generate any structure. Also in the second example when you
use the mapping approach - how do you know which MEP's the POJO can
handle?
I figured if a result is returned then it'd be an InOut by default
unless an annotation is added to explicitly specify the MEP such as
InOptionalOut
So we could write an InOut processor as
@ExchangeProcessor
public Document foo(Document in, @MessageParam String foo) {... }
--
James
---
http://radio.weblogs.com/0112098/
--
James
---
http://radio.weblogs.com/0112098/
Re: Thoughts on a JBI POJO Engine
Guillaume,
I agree that we need to define the difference between components more
clearly - I suppose in my mind the JBI component under discussion here
is basically a mechanism when you are focussing on XML messaging in a
format that can not be changed or where you want to interact with the
JBI message bus to provide either InOnly reciept of messages or to
build a consumer that will run through a provided WorkManager.
The JSR181 components to be have always had explicit business
interfaces and work more akin to Web Services or EJB's then MDB's
(sorry for the switching back to the old days). I was hoping that
people building integration service units would simply want to be
playing with payloads or mapping in some specific bits of information
from an XML document (people who would be familiar familiar with XPath
and DOM say) and would want to act on that information and reply with
a Document or create an exchange to another service. While I suppose
IMHO the JSR181 is more for people wishing to expose Business Services
to the bus, and would be used by people designing application
endpoints - which would be defining the payload of the messages not
simply being given the payload?
The different would be in the purposing and flexibilty of the POJO's -
the JBI would be quick (and maybe a little dirty) which it could work
on any payload of message etc and could interact with a InOut
exchange, get the property from the exchange, update the Fault and
Error etc. While the JSR181 would be a way to expose business
services to the bus (whereby your focus is on WSDL, and structured
data).
I realize you can do any payload in JSR181 but I'm wondering whether
that is simply pushing the JSR181 container into doing more than it is
best suited?
P
On 8/21/06, Guillaume Nodet [EMAIL PROTECTED] wrote:
While I fully agree to simplify the annotations used,
if you begin to map parameters to properties or xml content,
you end up to jsr181 component.
I have already planned to add annotations a la jaxws to allow
properties to be mapped to parameters in jsr181. A kind of
JBI annotations set for jaxws (compared to the existing SOAP annotations).
But if we begin to handle xml mapping here, we would end
with 2 components with little differences.
For example, the
@ExchangeProcessor
public SomeResponse doSomething(@MessageBody SomeRequest foo) { ... }
could be further simplified to
@WebMethod
public SomeResponse doSomething(@WebParam SomeRequest foo) { ... }
which is exactly what the jsr181 component do ;)
Note that the jsr181 component should already by able to
handle Source types as a parameter (which would map to
the full payload), and we should be able to add a MessageExchange
parameter which would receive the exchange without disturbing
other parameters (xfire already does that for xfire specific
classes, such as the context).
We need to clearly agree on what we want to show and hide from
the jbi spec in this component. I don't think we need another SE
that do xml marshalling (we'd better enhance the existing one).
The main things to define imho are:
* how to return the answer if using an InOut
* when the pojo acts as a consumer, how will it receive the answer
from an InOut exchange it has previsouly sent
I really think there is something to do with beanflow.
I will try to think about that a bit more.
On 8/21/06, James Strachan [EMAIL PROTECTED] wrote:
Just a bit of brainstorming of ideas here.
I was looking at this example
@ExchangeProcessor(patterns = { MessageExchangePattern.INOUT },
parameterMappings = { ParameterMapping.IN_MESSAGE_CONTENT })
public void myInOutProcessor(MessageExchange me) {
// Do something here
}
@ExchangeProcessor(patterns = { MessageExchangePattern.INONLY,
MessageExchangePattern.ROBUSTINOULY },
parameterMappings = {
ParameterMapping.IN_MESSAGE_CONTENT })
public void myInOnlyProcessor(Source payload) {
// Do something here
}
and wondering how to simplify a little.
My first thought was to use an annotation for each kind of exchange to
be supported...
@InOnlyExchange @RobustInOnlyExchange
public void foo(MessageExchange exchange) {
}
(I realised we'd get class name clashes so added the 'Exchange'
postfix to the annotation names. Then I figured it might be simpler to
just use a typesafe API...
@ExchangeProcessor
public void foo(InOnly exchange) {
}
@ExchangeProcessor
public void bar(RobustInOnly exchange) {
}
I guess sometimes folks might not want to see/use the exchange or
might wish to support multiple patterns for one method so some kinda
annotation to indicate the exchange pattern is still useful.
Also how about annotating parameters as being bound to the exchange...
@ExchangeProcessor
public void foo(@MessageProperty('cheese') String foo,
@ExchangeProperty(beer) Integer bar, @MessageContent Source payload)
{
}
While the
Re: Thoughts on a JBI POJO Engine
I like the logic - also I like the idea that a service could annotate
two methods and thus end up with the ability to process an InOut and a
InOnly via two different methods on the same class. The only question
I suppose it what happens if you want to be able to provide both from
the same method - say a file reading service that gets the filename in
an XML path and then reading and passing the file to a providing
service then can either return an XML representing the number of
records or not (depending on the MEP?).
Just a thought
P
On 8/21/06, James Strachan [EMAIL PROTECTED] wrote:
Brainstorming again - here's some thoughts on some sensible defaults
we could use for MEPs to keep things as simple as possible...
By default methods which are void are InOnly and methods that are
non-void are InOut unless there is a typesafe MessageExchange
parameter or an annotation used to overload things.
e.g. these are InOnly...
@ExchangeProcessor
void foo(MessageExchange e) {}
@ExchangeProcessor
void foo(InOnly e) {}
@ExchangeProcessor
void foo(@MessageContent Document doc) {}
// these are InOut
@ExchangeProcessor
void foo(InOut e) {}
@ExchangeProcessor
Document foo(@MessageContent Document doc) {}
@ExchangeProcessor(pattern=Pattern.IN_OUT)
void foo(MessageExchange e) {}
etc
I wonder if we should support parameters for the in and out values? e.g.
@ExchangeProcessor
void foo(@In NormalizedMessage in, @Out NormalizedMessage) {}
or
@ExchangeProcessor
void foo(@MessageContent Document in, @OutMessageContent Document out) {}
On 8/21/06, James Strachan [EMAIL PROTECTED] wrote:
On 8/21/06, Philip Dodds [EMAIL PROTECTED] wrote:
James,
I like the idea of sticking to the JSR's where possible - and in fact
I'll run over JSR-250 to see what we can use. Also I agree that the
EJB3/SCA style resource injection might be better - one of the reasons
for the more verbal example was just to make it clear a little more
clear what was going on :)
Agreed. I think some of the resources injected will need their own
annotations. EJB3 does this for a few kinds of resources too. I'd be
cool if we could avoid custom annotations where possible though.
There seems to be some inconsistency in the use of annotations in this
area - some specs insist on new annotations others just use @Resource
- i've never quite figured out the reasoning behind the difference :).
As for the exchange processor mapping I think that the second option,
with annotated parameters looks sweet, and would also give us a
little room for doing some neat mapping stuff like -
@ExchangeProcessor
public void foo(@MessageContentXPath(\customer\name) String name)
{
}
Ooh thats neat - I like that! :)
This this would allow mapping of a payload to a method, however
when if comes to JAXB2 type mappings and the SomeResponse/SomeRequest
example you put in - I'm not sure that this isn't stepping on the toes
of the SCA/JSR-181 Service Engines?
Yeah.
I guess ultimately I'd like application developers to not have to
mentally think about switching from SCA ot JSR 181 to JBI too much;
they should hopefully have similar look and feels. It'd be nice to
have a kinda unified set of annotations to use or at least share as
many as possible. So hopefully we could reuse JAXB2 across all 3
models; SCA, JBI and JSR 181.
So for mapping the content of a NormalizedMessage it'd be good to support
* Source
* DOM / dom4j / XOM et al
* SDO
* JAXB2/XStream
* maybe text?
e.g. if using the JBI annotations I don't see why we can't also use
the JAXB2 mapping stuff.
We might wanna use XPath with JAXB2 as well...
I suppose one of the things here
was providing:
a) a clean mechanism for writing POJO's that what to interact with the
JBI infrastructure and have been specifically implemented to do so
b) POJO's that what to interact with messaging (not XML-RPC) but more
akin to legacy messaging structures that are being passed around and
allowing you to persist them.
However, I can see that the JAXB example would be interesting since
you could generate any structure. Also in the second example when you
use the mapping approach - how do you know which MEP's the POJO can
handle?
I figured if a result is returned then it'd be an InOut by default
unless an annotation is added to explicitly specify the MEP such as
InOptionalOut
So we could write an InOut processor as
@ExchangeProcessor
public Document foo(Document in, @MessageParam String foo) {... }
--
James
---
http://radio.weblogs.com/0112098/
--
James
---
http://radio.weblogs.com/0112098/
Re: Thoughts on a JBI POJO Engine
I would love that, but such annotations are forbidden :(
Only primitive types, string, class, enums, annotations (or arrays of these)
can be used as annotations attributes.
On 8/21/06, James Strachan [EMAIL PROTECTED] wrote:
Interesting! I really love the @Destination injection BTW :)
I wonder about using futures a little more to make the code a little
simpler. Something like the following - where we wrap up an async
request-response as a child Step or Future...
public class MyWorkflow {
Message request;
FutureMessage answer1;
FutureMessage answer2;
@Destination(uri=service:urn:service)
private Destination service1;
@Destination(uri=service:urn:service)
private Destination service2;
@Request
public void receiveRequest(Message message) throws Exception {
request = message;
answer1 = service1.sendAsync(copy(request));
answer2 = service2.sendAsync(copy(request));
}
@Join(futures = { answer1, answer2 })
@Answer()
public Message answer() {
Message m1 = answer1.get();
Message m2 = answer2.get();
// Do something with answer1 and answer2
return new Message()
}
}
On 8/21/06, Guillaume Nodet [EMAIL PROTECTED] wrote:
Here is something i'd like to be able to do.
This is really pseudo code, and some kind of beanflow oriented annotations.
This service would simply send two concurrent requests and wait for their
answers to reply to the main request. Of course, this would be much easier
if you use syncSend but you would not have a real workflow ;)
public class MyWorkflow {
Message request;
Message answer1;
Message answer2;
@Destination(uri=service:urn:service)
private Destination service1;
@Destination(uri=service:urn:service)
private Destination service2;
@Request
@NextStep(steps = { invokeService, invokerService2 }) // This
would auto-fork
public void receiveRequest(Message message) throws Exception {
request = message;
}
@NextStep(step = receiveService1)
public void invokeService1() {
service1.send(copy(request));
// return response to receiveService1
}
public void receiveService1(Message message) {
answer1 = message;
}
@NextStep(step = receiveService2)
public void invokeService2() {
service2.send(copy(request));
}
public void receiveService2(Message message) {
answer2 = message;
}
@Join(steps = { receiveService1, receiveService2 })
@Answer()
public void answer() {
// Do something with answer1 and answer2
return new Message()
}
}
On 8/21/06, Guillaume Nodet [EMAIL PROTECTED] wrote:
While I fully agree to simplify the annotations used,
if you begin to map parameters to properties or xml content,
you end up to jsr181 component.
I have already planned to add annotations a la jaxws to allow
properties to be mapped to parameters in jsr181. A kind of
JBI annotations set for jaxws (compared to the existing SOAP annotations).
But if we begin to handle xml mapping here, we would end
with 2 components with little differences.
For example, the
@ExchangeProcessor
public SomeResponse doSomething(@MessageBody SomeRequest foo) { ... }
could be further simplified to
@WebMethod
public SomeResponse doSomething(@WebParam SomeRequest foo) { ... }
which is exactly what the jsr181 component do ;)
Note that the jsr181 component should already by able to
handle Source types as a parameter (which would map to
the full payload), and we should be able to add a MessageExchange
parameter which would receive the exchange without disturbing
other parameters (xfire already does that for xfire specific
classes, such as the context).
We need to clearly agree on what we want to show and hide from
the jbi spec in this component. I don't think we need another SE
that do xml marshalling (we'd better enhance the existing one).
The main things to define imho are:
* how to return the answer if using an InOut
* when the pojo acts as a consumer, how will it receive the answer
from an InOut exchange it has previsouly sent
I really think there is something to do with beanflow.
I will try to think about that a bit more.
On 8/21/06, James Strachan [EMAIL PROTECTED] wrote:
Just a bit of brainstorming of ideas here.
I was looking at this example
@ExchangeProcessor(patterns = { MessageExchangePattern.INOUT },
parameterMappings = { ParameterMapping.IN_MESSAGE_CONTENT })
public void myInOutProcessor(MessageExchange me) {
// Do something here
}
@ExchangeProcessor(patterns = { MessageExchangePattern.INONLY,
MessageExchangePattern.ROBUSTINOULY },
parameterMappings = {
ParameterMapping.IN_MESSAGE_CONTENT })
public void
Re: Thoughts on a JBI POJO Engine
On 8/21/06, Guillaume Nodet [EMAIL PROTECTED] wrote:
I would love that, but such annotations are forbidden :(
Only primitive types, string, class, enums, annotations (or arrays of these)
can be used as annotations attributes.
Yeah - we could use the String names of fields/properties which are
futures / steps.
@Join(futures = { answer1, answer2 })
@Answer()
public Message answer() {
Message m1 = answer1.get();
Message m2 = answer2.get();
...
}
Or the join could be done programatically
@Request
public void receiveRequest(Message message) throws Exception {
request = message;
answer1 = service1.sendAsync(copy(request));
answer2 = service2.sendAsync(copy(request));
// call the answer method when we have both futures joined
join(answer, answer1, answer2);
}
But the annotation based one is cleaner and more loosly coupled
On 8/21/06, James Strachan [EMAIL PROTECTED] wrote:
Interesting! I really love the @Destination injection BTW :)
I wonder about using futures a little more to make the code a little
simpler. Something like the following - where we wrap up an async
request-response as a child Step or Future...
public class MyWorkflow {
Message request;
FutureMessage answer1;
FutureMessage answer2;
@Destination(uri=service:urn:service)
private Destination service1;
@Destination(uri=service:urn:service)
private Destination service2;
@Request
public void receiveRequest(Message message) throws Exception {
request = message;
answer1 = service1.sendAsync(copy(request));
answer2 = service2.sendAsync(copy(request));
}
@Join(futures = { answer1, answer2 })
@Answer()
public Message answer() {
Message m1 = answer1.get();
Message m2 = answer2.get();
// Do something with answer1 and answer2
return new Message()
}
}
On 8/21/06, Guillaume Nodet [EMAIL PROTECTED] wrote:
Here is something i'd like to be able to do.
This is really pseudo code, and some kind of beanflow oriented annotations.
This service would simply send two concurrent requests and wait for their
answers to reply to the main request. Of course, this would be much easier
if you use syncSend but you would not have a real workflow ;)
public class MyWorkflow {
Message request;
Message answer1;
Message answer2;
@Destination(uri=service:urn:service)
private Destination service1;
@Destination(uri=service:urn:service)
private Destination service2;
@Request
@NextStep(steps = { invokeService, invokerService2 }) // This
would auto-fork
public void receiveRequest(Message message) throws Exception {
request = message;
}
@NextStep(step = receiveService1)
public void invokeService1() {
service1.send(copy(request));
// return response to receiveService1
}
public void receiveService1(Message message) {
answer1 = message;
}
@NextStep(step = receiveService2)
public void invokeService2() {
service2.send(copy(request));
}
public void receiveService2(Message message) {
answer2 = message;
}
@Join(steps = { receiveService1, receiveService2 })
@Answer()
public void answer() {
// Do something with answer1 and answer2
return new Message()
}
}
On 8/21/06, Guillaume Nodet [EMAIL PROTECTED] wrote:
While I fully agree to simplify the annotations used,
if you begin to map parameters to properties or xml content,
you end up to jsr181 component.
I have already planned to add annotations a la jaxws to allow
properties to be mapped to parameters in jsr181. A kind of
JBI annotations set for jaxws (compared to the existing SOAP annotations).
But if we begin to handle xml mapping here, we would end
with 2 components with little differences.
For example, the
@ExchangeProcessor
public SomeResponse doSomething(@MessageBody SomeRequest foo) { ... }
could be further simplified to
@WebMethod
public SomeResponse doSomething(@WebParam SomeRequest foo) { ... }
which is exactly what the jsr181 component do ;)
Note that the jsr181 component should already by able to
handle Source types as a parameter (which would map to
the full payload), and we should be able to add a MessageExchange
parameter which would receive the exchange without disturbing
other parameters (xfire already does that for xfire specific
classes, such as the context).
We need to clearly agree on what we want to show and hide from
the jbi spec in this component. I don't think we need another SE
that do xml marshalling (we'd better enhance the existing one).
The main things to define imho are:
* how to return the answer if using an InOut
* when the pojo acts as a consumer, how will
