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/
