On 8/21/06, Philip Dodds <[EMAIL PROTECTED]> wrote:
I suppose the more important question is how to implement stateful
POJO's - what demarcates the life of a POJO if it is stateful?
Do we assume that there is an InOut at the begining and therefore when
the POJO replies to the original message is life is complete?
That was my thought. It' s the same thing for a bpel process instance.
The instance is created when receiving an incoming request and can be
persisted for long-running workflows.
I'm
still not sure about stateful POJO's in the ESB?
SCA also defines statefull POJOs. AFAIK, sca defines several scopes:
* stateless
* request
* session
* module
I would like to see what people think in a large context about this?
I think that stateful pojo are about ease of use for the end user.
Of course, you can achieve the same thing using a stateless pojo and
some maps as done in the EIP patterns.
P
On 8/21/06, James Strachan <[EMAIL PROTECTED]> wrote:
> I guess you could reuse the EJB3 annotations for stateless / stateful
metadata?
>
> On 8/21/06, Philip Dodds <[EMAIL PROTECTED]> wrote:
> > The destination annotation looks great ! I assume the main body of the
> > JBI POJO here is the request/answer annotations.
> >
> > What I'm not sure about here is the use of fields - so this is a
> > stateful class? I was thinking that async would be a hybrid of the
> > destination and the processor?
> >
> > public class Example1 {
> >
> > @Destination(uri="service:urn:service", request="myFirstRequest")
> > private Destination service1;
> >
> > public void sendRequest() {
> > service1.send(new Message());
> > }
> >
> > @ExchangeProcessor(request="myFirstRequest")
> > public void sendRequest(@MessageContent Document in) {
> > // Got response
> > }
> >
> > }
> >
> > The premise being that if you have a async reply then you need to be
stateless?
> >
> > P
> >
> >
> > 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 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/
> > > > >
> > > >
> > > >
> > > > --
> > > > Cheers,
> > > > Guillaume Nodet
> > > >
> > >
> > >
> > > --
> > > Cheers,
> > > Guillaume Nodet
> > >
> >
>
>
> --
>
> James
> -------
> http://radio.weblogs.com/0112098/
>
--
Cheers,
Guillaume Nodet
