So just so I get it - are we still thinking of two engines? The reason I ask is I'm not sure about an uber-engine that does everything - simply because it sort of breaks that whole SE flexbiity and also makes understanding it all a little more tricky.
I'm going to try and update the page today with some of the discussion here so we can track where we are going :) P On 8/21/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
I do think we agree ;) The only thing i meant, was that this new component should focus on: * messaging style (asynchronous) * xml payload * closer to jbi whereas jsr181 is good for web service stuff (completely hiding jbi, doing xml/java marshalling, rpc, etc..). Stating that provides imho a clear difference between the two components. On 8/21/06, Philip Dodds <[EMAIL PROTECTED]> wrote: > 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 @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