cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <...@envoisolutions.com>
Subject APP & CXF [was Re: 2.1 thoughts......]
Date Tue, 07 Aug 2007 17:18:51 GMT
Hi James,

I've thought about APP and CXF a bit, and I've not yet seen a great way to
bring the two together. The way you design & model your services is
completely different. Can you go into more detail about how you see the two
coming together?

I thought Sanjiva from Axis2 actually had a good summary recently of why
bringing together the RESTful and operation/WSDL oriented approach is quite
tricky: http://www.bloglines.com/blog/sanjiva?id=227. I've also written
about it before:
http://netzooid.com/blog/2006/12/07/resource-vs-service-oriented-data-design/

- Dan

On 8/7/07, James Strachan <james.strachan@gmail.com> wrote:
>
> I'd love to see AtomPub support as a new kinda front end / binding.
> http://atompub.org/rfc4287.html
>
> I've had brief conversations in bars in various coutries in the past
> with DanD about this - previously we looked at some annotations to
> expose RESTful resources using individual annotations on operations;
> to bind a specific method/property to a URI etc.
>
> Am wondering if an AtomPub binding could be simpler and a little
> cleverer; as AtomPub automatically understands collections &
> navigations through types together with the basic operations. e.g.
> relationships, collections, add/remove/update semantics etc.
>
>
> Another thing I'd like to see is some tooling/maven plugins/whatever
> so folks can do contract first development, but instead of having to
> edit WSDL, they could just edit RelaxNG Compact Syntax to define the
> structure of messages; which then could auto-generate the XSD / WSDL.
> Or even supply some example XML documents - which by using Trang could
> then generate the XSD/WSDL. For more background see...
>
> http://www.nabble.com/contract-first-using-either-XSD-or-XML-plus-Trang-tf3679800.html#a10288179
>
>
> On 8/7/07, Daniel Kulp <dkulp@apache.org> wrote:
> >
> > With 2.0.1 almost out the door (getting votes when everyone is on
> > vacation sucks), I'd like to take a minute to think about what should go
> > into 2.1.   We've tossed around a bunch of ideas and I'd like to get
> > them written down.   I'll probably start a "wish list" wiki page once
> > the ideas get flowing, but for now, here's my list of stuff I've seen
> > floating around:
> >
> > 1) JAX-WS 2.1/JAXB 2.1 - this is a fairly large amount of work as there
> > are  some very significant changes that will involve code generation
> > changes, java -> wsdl  changes, runtime support changes, etc....
> >
> > 2) Data bindings - XmlBeans and JIBX have been on the list for a while
> > and I'm sure more XFire folks could find CXF more useful if we got those
> > working.    There are two parts: runtime and tooling.
> >
> > 3) JavaScript stuff - the javascript frontend needs some refactoring to
> > allow calling other services with it, make it not dependent on the jaxws
> > frontend, etc....   Also the js donation from Basis Tech would be great
> > to get wired in.   (if we can get the grant set, too many people on
> > vacation)
> >
> > 4) Rest stuff - all the buzzword compatible stuff.   :-)
> >
> > 5) WS-* specs - do we have time to tackle any more of these at this
> > point?   Which ones should we prioritize?
> >
> > 6) OSGI bundling - I think adding simple OSGI manifests for our jars
> > would be fairly easy.    However, should we create some "bundles" to
> > represent common functionality?  (like JAX-WS/SOAP/HTTP bundle)
> >
> >
> > I hate to ask for more ideas as that alone is a TON of work, but at this
> > point, let's get the ideas flowing.   :-)
> >
> > --
> > J. Daniel Kulp
> > Principal Engineer
> > IONA
> > P: 781-902-8727    C: 508-380-7194
> > daniel.kulp@iona.com
> > http://www.dankulp.com/blog
> >
>
>
> --
> James
> -------
> http://macstrac.blogspot.com/
>



-- 
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message