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
