Yes, I think so.
But maybe we could have some common code / annotations which could be reused.
Especially if we try to put pitchfork (EJB3) in jsr181, which would
introduce some
annotations driven injection.
On 8/21/06, Philip Dodds <[EMAIL PROTECTED]> wrote:
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
>
--
Cheers,
Guillaume Nodet
