You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Daniel Kulp <dk...@apache.org> on 2008/06/18 17:17:22 UTC
Ideas for 2.2
Now that 2.1.1 is being voted on, I'd like to step back a bit and talk
a little about ideas for the next versions.
First, most likely, we'll need to do a 2.1.2 release in about 6-8
weeks (and maybe 2.0.8 as well). We've done a very good job of
getting fixes out to our users in a timely manner and I'd like to keep
that up, but I also would like to think about 2.2 a bit as well. I
haven't created the 2.1.x fixes branch yet, but I probably will
shortly if we start doing some new stuff toward 2.2.
That said, here is my list of stuff that is "missing" and could be
considered for 2.2:
1) WS-Trust/WS-SecurePolicy/WS-SecureConversation stuff. Not
supporting these is becoming increasingly problematic. Most likely,
when I get back from my paternity leave, I'm going to start digging
into these a bit. I haven't really read up on these yet (in depth) so
any help would be greatly appreciated.
2) XMLBeans tooling - I started this a bit for 2.1.1. 2.1.1 now will
actually generate some interfaces for xmlbeans, but the sample clients/
servers are wrong (don't set the jaxb databinding) and I'm not sure if
the interfaces even work unless you use a jaxws customization to force
everything into bare mode. Cleaning this stuff up could be a 2.1.x
"fix" as well.
3) JIBX data binding - This is probably the last major thing not
ported from XFire. Not sure the demand on it though.
4) Extension via annotation - Benson and I have chatted about this off
and on. Basically, we'd like to add hooks into the
ReflectServiceFactoryBean so that registered listeners can get events
about when things happen. Like when an interface is mapped to a
ServiceInfo, a method is mapped to a OperaionInfo and
BingingOperationInfo, etc... The listeners can then examine the
Method object or Class object or whatever for any additional things
it's interested in at runtime. This would allow for some custom
annotations. Examples:
Configure some logging:
@Logging(in = "in.log", out = "out.log", fault = "<stderr>")
Configure and IDL location for the corba binding:
@IDLLocation("file:/foo.idl")
Add documentation to the wsdl:
@WSDLAnnotation("This operation does XXX")
etc...
Some of the stuff in the JAX-WS frontend could then be re-written to
use that. Processing of the @WebServiceFeature annotations and stuff
could be re-implemented that way. The main thing here is to make
some of the java-first things work a bit better/easier. (our own
@Features annotation could be deprecated in favor of explicit
annotations for the features we have)
5) OSGi stuff - I know there are some OSGi enhancements in the works
that could be pulled in:
a) osgi http transport - this currently lives in ServiceMix, but
could be pulled into CXF to work with other OSGi runtimes
b) Distributed OSGi (RFC 119) - there is work being done to
implement RFC 119 with CXF. There are some rules about releasing the
IP for this though that is being investigated.
6) JMS transport enhancements - I keep wanting to update this a bit to
leverage spring jms stuff a bit better to make it much easier to
configure.
7) JAX-RS updates - to 0.7 at least. Maybe later versions as they
come up with them.
8) Web site update? I'd like to possibly create a quick logo and
update the site a bit to look a bit less like confluence. This is a
"would be nice anytime, not just for 2.2" type thing.
I'm sure there will be a bunch of other enhancements as well. Stuff
like performance/memory enhancements, etc...
Anyway, thoughts? Other ideas? Comments?
---
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
Re: Ideas for 2.2
Posted by Daniel Kulp <dk...@apache.org>.
Adrian,
The first step is to really get the JMS transport into a state where it's
easily configurable and more easy to maintain and extend. As part of this,
it's also being converted from using pure JMS calls to using the Spring JMS
stuff. Currently, Christian Schneider has been submitting some patches to
move us in that direction. That really needs to be done first. (he's
doing an excellent job though)
Once that is done, the SOAP-over-JMS specification should become a bit easier
to implement. But step one above needs to get done first.
Dan
On Thursday 18 September 2008 12:12:47 pm Adrian Trenaman wrote:
> I'd lie to see us supporting the SOAP-over-JMS specification: MTOSI (from
> TMF) has WSDLs with SOAP-over-JMS semantics, but as the spec isn't
> finalized yet they're using "made-up" transport url
> ("http://schemas.xmlsoap.org/soap/jms") instead of the standardized
> "http://www.w3.org/2008/07/soap/bindings/JMS/".
>
> Right now, I'm working with a customer who adds the custom CXF
> <jms:address> element to the port type to MTOSI WSDL. Clearly, that's not
> desirable, as it means they have to maintain their own modified copy of the
> MTOSI WSDL; further, this WSDL is incompatible with non-CXF client
> technologies.
>
> @Dan: do you know if anyone has started work on implementing this spec?
>
> dkulp wrote:
> > Regarding JMS, the other thing that probably needs to be done is
> > investigating the SOAP over JMS spec submitted at:
> > http://www.w3.org/Submission/SOAPJMS/
> > and seeing how well that can fit in.
> >
> > Dan
> >
> > On Jun 18, 2008, at 7:34 PM, Christian Schneider wrote:
> >> I would really like to see good osgi integration as we plan to rely
> >> quite heavily on osgi in the future. But as I myself are only
> >> starting on this I don´t know much about the details. Basically I
> >> would like to be able to connect the osgi internal services with
> >> cxf to communicate with the outside world. So a client should be
> >> able to simply use an osgi service. The provider of the service
> >> could then be simply a local bundle or a cxf based kind of binding
> >> component that does the remoting. I hope somthing like this will
> >> come from servicemix.
> >>
> >> For the short term the jms enhancements are my favourite.
> >> Configuring the jms destination and jms conduit is really non
> >> intuitive and it does not follow spring standard procedures.
> >> The most important thing for me is externalising the
> >> ConnectionFactory. This should be defined in a separate bean and
> >> only be referenced from conduit and destination. I think there are
> >> two main
> >> use cases here.
> >>
> >> 1. You want to define the ConnectionFactory yourself. In a spearate
> >> bean this will be easy
> >>
> >> 2. You want to fetch the factory from jndi. In this case I would
> >> like to use the spring jee extensions or again a simple bean
> >>
> >> <jee:jndi-lookup id="myConnectionFactory" jndi-
> >> name="my.connection.Factory"
> >> <jee:environment>
> >>
> >> java
> >> .naming.factory.initial=weblogic.jndi.WLInitialContextFactory
> >> java.naming.provider.url=tcp://localhost:10001
> >> </jee:environment> </jee:jndi-lookup>
> >>
> >> The last thing about jms is that I would like to be able to select
> >> the connection and configure the queue and other settings in the
> >> address of the service. I really like the way camel handles
> >> jms. Perhaps this can be done like in camel. So perhaps it is
> >> possible to not need the jms destination and jms conduit configs at
> >> all.
> >>
> >> Best regards
> >>
> >> Christian
> >>
> >> Daniel Kulp schrieb:
> >>> Now that 2.1.1 is being voted on, I'd like to step back a bit and
> >>> talk a little about ideas for the next versions.
> >>>
> >>> First, most likely, we'll need to do a 2.1.2 release in about 6-8
> >>> weeks (and maybe 2.0.8 as well). We've done a very good job of
> >>> getting fixes out to our users in a timely manner and I'd like to
> >>> keep that up, but I also would like to think about 2.2 a bit as
> >>> well. I haven't created the 2.1.x fixes branch yet, but I
> >>> probably will shortly if we start doing some new stuff toward 2.2.
> >>>
> >>> That said, here is my list of stuff that is "missing" and could be
> >>> considered for 2.2:
> >>>
> >>>
> >>> 5) OSGi stuff - I know there are some OSGi enhancements in the
> >>> works that could be pulled in:
> >>> a) osgi http transport - this currently lives in ServiceMix, but
> >>> could be pulled into CXF to work with other OSGi runtimes
> >>> b) Distributed OSGi (RFC 119) - there is work being done to
> >>> implement RFC 119 with CXF. There are some rules about releasing
> >>> the IP for this though that is being investigated.
> >>>
> >>> 6) JMS transport enhancements - I keep wanting to update this a bit
> >>> to leverage spring jms stuff a bit better to make it much easier to
> >>> configure.
> >>>
> >>>
> >>> Anyway, thoughts? Other ideas? Comments?
> >
> > ---
> > Daniel Kulp
> > dkulp@apache.org
> > http://www.dankulp.com/blog
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
Re: Ideas for 2.2
Posted by Adrian Trenaman <ad...@googlemail.com>.
I'd lie to see us supporting the SOAP-over-JMS specification: MTOSI (from
TMF) has WSDLs with SOAP-over-JMS semantics, but as the spec isn't finalized
yet they're using "made-up" transport url
("http://schemas.xmlsoap.org/soap/jms") instead of the standardized
"http://www.w3.org/2008/07/soap/bindings/JMS/".
Right now, I'm working with a customer who adds the custom CXF <jms:address>
element to the port type to MTOSI WSDL. Clearly, that's not desirable, as it
means they have to maintain their own modified copy of the MTOSI WSDL;
further, this WSDL is incompatible with non-CXF client technologies.
@Dan: do you know if anyone has started work on implementing this spec?
dkulp wrote:
>
>
> Regarding JMS, the other thing that probably needs to be done is
> investigating the SOAP over JMS spec submitted at:
> http://www.w3.org/Submission/SOAPJMS/
> and seeing how well that can fit in.
>
> Dan
>
>
>
> On Jun 18, 2008, at 7:34 PM, Christian Schneider wrote:
>
>> I would really like to see good osgi integration as we plan to rely
>> quite heavily on osgi in the future. But as I myself are only
>> starting on this I don´t know much about the details. Basically I
>> would like to be able to connect the osgi internal services with
>> cxf to communicate with the outside world. So a client should be
>> able to simply use an osgi service. The provider of the service
>> could then be simply a local bundle or a cxf based kind of binding
>> component that does the remoting. I hope somthing like this will
>> come from servicemix.
>>
>> For the short term the jms enhancements are my favourite.
>> Configuring the jms destination and jms conduit is really non
>> intuitive and it does not follow spring standard procedures.
>> The most important thing for me is externalising the
>> ConnectionFactory. This should be defined in a separate bean and
>> only be referenced from conduit and destination. I think there are
>> two main
>> use cases here.
>>
>> 1. You want to define the ConnectionFactory yourself. In a spearate
>> bean this will be easy
>>
>> 2. You want to fetch the factory from jndi. In this case I would
>> like to use the spring jee extensions or again a simple bean
>>
>> <jee:jndi-lookup id="myConnectionFactory" jndi-
>> name="my.connection.Factory"
>> <jee:environment>
>>
>> java
>> .naming.factory.initial=weblogic.jndi.WLInitialContextFactory
>> java.naming.provider.url=tcp://localhost:10001
>> </jee:environment> </jee:jndi-lookup>
>>
>> The last thing about jms is that I would like to be able to select
>> the connection and configure the queue and other settings in the
>> address of the service. I really like the way camel handles
>> jms. Perhaps this can be done like in camel. So perhaps it is
>> possible to not need the jms destination and jms conduit configs at
>> all.
>>
>> Best regards
>>
>> Christian
>>
>>
>> Daniel Kulp schrieb:
>>>
>>> Now that 2.1.1 is being voted on, I'd like to step back a bit and
>>> talk a little about ideas for the next versions.
>>>
>>> First, most likely, we'll need to do a 2.1.2 release in about 6-8
>>> weeks (and maybe 2.0.8 as well). We've done a very good job of
>>> getting fixes out to our users in a timely manner and I'd like to
>>> keep that up, but I also would like to think about 2.2 a bit as
>>> well. I haven't created the 2.1.x fixes branch yet, but I
>>> probably will shortly if we start doing some new stuff toward 2.2.
>>>
>>> That said, here is my list of stuff that is "missing" and could be
>>> considered for 2.2:
>>>
>>>
>>> 5) OSGi stuff - I know there are some OSGi enhancements in the
>>> works that could be pulled in:
>>> a) osgi http transport - this currently lives in ServiceMix, but
>>> could be pulled into CXF to work with other OSGi runtimes
>>> b) Distributed OSGi (RFC 119) - there is work being done to
>>> implement RFC 119 with CXF. There are some rules about releasing
>>> the IP for this though that is being investigated.
>>>
>>> 6) JMS transport enhancements - I keep wanting to update this a bit
>>> to leverage spring jms stuff a bit better to make it much easier to
>>> configure.
>>>
>>>
>>> Anyway, thoughts? Other ideas? Comments?
>>>
>>>
>>>
>>>
>>
>
> ---
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>
>
>
>
>
>
--
View this message in context: http://www.nabble.com/Ideas-for-2.2-tp17985028p19556509.html
Sent from the cxf-dev mailing list archive at Nabble.com.
Re: Ideas for 2.2
Posted by Daniel Kulp <dk...@apache.org>.
Regarding JMS, the other thing that probably needs to be done is
investigating the SOAP over JMS spec submitted at:
http://www.w3.org/Submission/SOAPJMS/
and seeing how well that can fit in.
Dan
On Jun 18, 2008, at 7:34 PM, Christian Schneider wrote:
> I would really like to see good osgi integration as we plan to rely
> quite heavily on osgi in the future. But as I myself are only
> starting on this I don´t know much about the details. Basically I
> would like to be able to connect the osgi internal services with
> cxf to communicate with the outside world. So a client should be
> able to simply use an osgi service. The provider of the service
> could then be simply a local bundle or a cxf based kind of binding
> component that does the remoting. I hope somthing like this will
> come from servicemix.
>
> For the short term the jms enhancements are my favourite.
> Configuring the jms destination and jms conduit is really non
> intuitive and it does not follow spring standard procedures.
> The most important thing for me is externalising the
> ConnectionFactory. This should be defined in a separate bean and
> only be referenced from conduit and destination. I think there are
> two main
> use cases here.
>
> 1. You want to define the ConnectionFactory yourself. In a spearate
> bean this will be easy
>
> 2. You want to fetch the factory from jndi. In this case I would
> like to use the spring jee extensions or again a simple bean
>
> <jee:jndi-lookup id="myConnectionFactory" jndi-
> name="my.connection.Factory"
> <jee:environment>
>
> java
> .naming.factory.initial=weblogic.jndi.WLInitialContextFactory
> java.naming.provider.url=tcp://localhost:10001
> </jee:environment> </jee:jndi-lookup>
>
> The last thing about jms is that I would like to be able to select
> the connection and configure the queue and other settings in the
> address of the service. I really like the way camel handles
> jms. Perhaps this can be done like in camel. So perhaps it is
> possible to not need the jms destination and jms conduit configs at
> all.
>
> Best regards
>
> Christian
>
>
> Daniel Kulp schrieb:
>>
>> Now that 2.1.1 is being voted on, I'd like to step back a bit and
>> talk a little about ideas for the next versions.
>>
>> First, most likely, we'll need to do a 2.1.2 release in about 6-8
>> weeks (and maybe 2.0.8 as well). We've done a very good job of
>> getting fixes out to our users in a timely manner and I'd like to
>> keep that up, but I also would like to think about 2.2 a bit as
>> well. I haven't created the 2.1.x fixes branch yet, but I
>> probably will shortly if we start doing some new stuff toward 2.2.
>>
>> That said, here is my list of stuff that is "missing" and could be
>> considered for 2.2:
>>
>>
>> 5) OSGi stuff - I know there are some OSGi enhancements in the
>> works that could be pulled in:
>> a) osgi http transport - this currently lives in ServiceMix, but
>> could be pulled into CXF to work with other OSGi runtimes
>> b) Distributed OSGi (RFC 119) - there is work being done to
>> implement RFC 119 with CXF. There are some rules about releasing
>> the IP for this though that is being investigated.
>>
>> 6) JMS transport enhancements - I keep wanting to update this a bit
>> to leverage spring jms stuff a bit better to make it much easier to
>> configure.
>>
>>
>> Anyway, thoughts? Other ideas? Comments?
>>
>>
>>
>>
>
---
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
Re: Ideas for 2.2
Posted by Eoghan Glynn <eg...@iona.com>.
Christian Schneider wrote:
> I would really like to see good osgi integration as we plan to rely
> quite heavily on osgi in the future. But as I myself are only starting
> on this I don´t know much about the details. Basically I would like to
> be able to connect the osgi internal services with cxf to communicate
> with the outside world. So a client should be able to simply use an osgi
> service. The provider of the service could then be simply a local bundle
> or a cxf based kind of binding component that does the remoting. I hope
> somthing like this will come from servicemix.
Christian,
The scenario you mention - client just using OSGi services as it would
in a purely local case, but with CXF transparently providing the
remoting capability - is exactly what Distributed OSGi / RFC 119 is all
about.
So I think you're in luck :)
Cheers,
Eoghan
> Daniel Kulp schrieb:
>>
>> 5) OSGi stuff - I know there are some OSGi enhancements in the works
>> that could be pulled in:
>> a) osgi http transport - this currently lives in ServiceMix, but
>> could be pulled into CXF to work with other OSGi runtimes
>> b) Distributed OSGi (RFC 119) - there is work being done to
>> implement RFC 119 with CXF. There are some rules about releasing the
>> IP for this though that is being investigated.
Re: Ideas for 2.2
Posted by Christian Schneider <ch...@die-schneider.net>.
I would really like to see good osgi integration as we plan to rely
quite heavily on osgi in the future. But as I myself are only starting
on this I don´t know much about the details. Basically I would like to
be able to connect the osgi internal services with cxf to communicate
with the outside world. So a client should be able to simply use an osgi
service. The provider of the service could then be simply a local bundle
or a cxf based kind of binding component that does the remoting. I hope
somthing like this will come from servicemix.
For the short term the jms enhancements are my favourite. Configuring
the jms destination and jms conduit is really non intuitive and it does
not follow spring standard procedures.
The most important thing for me is externalising the ConnectionFactory.
This should be defined in a separate bean and only be referenced from
conduit and destination. I think there are two main
use cases here.
1. You want to define the ConnectionFactory yourself. In a spearate bean
this will be easy
2. You want to fetch the factory from jndi. In this case I would like to
use the spring jee extensions or again a simple bean
<jee:jndi-lookup id="myConnectionFactory" jndi-name="my.connection.Factory"
<jee:environment>
java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory
java.naming.provider.url=tcp://localhost:10001
</jee:environment>
</jee:jndi-lookup>
The last thing about jms is that I would like to be able to select the
connection and configure the queue and other settings in the address of
the service. I really like the way camel handles
jms. Perhaps this can be done like in camel. So perhaps it is possible
to not need the jms destination and jms conduit configs at all.
Best regards
Christian
Daniel Kulp schrieb:
>
> Now that 2.1.1 is being voted on, I'd like to step back a bit and talk
> a little about ideas for the next versions.
>
> First, most likely, we'll need to do a 2.1.2 release in about 6-8
> weeks (and maybe 2.0.8 as well). We've done a very good job of
> getting fixes out to our users in a timely manner and I'd like to keep
> that up, but I also would like to think about 2.2 a bit as well. I
> haven't created the 2.1.x fixes branch yet, but I probably will
> shortly if we start doing some new stuff toward 2.2.
>
> That said, here is my list of stuff that is "missing" and could be
> considered for 2.2:
>
>
> 5) OSGi stuff - I know there are some OSGi enhancements in the works
> that could be pulled in:
> a) osgi http transport - this currently lives in ServiceMix, but
> could be pulled into CXF to work with other OSGi runtimes
> b) Distributed OSGi (RFC 119) - there is work being done to
> implement RFC 119 with CXF. There are some rules about releasing the
> IP for this though that is being investigated.
>
> 6) JMS transport enhancements - I keep wanting to update this a bit to
> leverage spring jms stuff a bit better to make it much easier to
> configure.
>
>
> Anyway, thoughts? Other ideas? Comments?
>
>
>
>
Re: Ideas for 2.2
Posted by Benson Margulies <bi...@gmail.com>.
More on annotations.
The JavaScript generator wants to have some annotations. It gets into the
act after the RFSB is all gone. So it needs an annotation scheme that
recognizes some general schema for annotations on relevant items and hangs
them off of the service model.
Further, I think that all our 'proprietary' annotations should live in one
JAR, so that someone can easily include them in code when not deploying a
service.
Re: Ideas for 2.2
Posted by Fred Dushin <fr...@dushin.net>.
Hi Glen,
Thanks for the comments. Some responses in-line, though these are
more ramblings, than anything else. Please excuse any straw-man
arguments I make, as you may have already considered a lot of this.
On Jun 20, 2008, at 5:05 PM, Glen Mazza wrote:
> As for WS-SecureConversation, AFAICT it is just a generalization of
> WS-Security[1]--the tokens (of whatever type, Kerberos, SAML,
> UsernameToken,
> or whatever) are not continually regenerated/resent for each reply/
> request.
> It's primarily a performance issue--WS-SC makes things faster.
Well I suspect it does that, but WS-SecConv is really capable of more
than that (IMO). I think part of what you're saying is that the WS-
SecConv "protocol" (if you will) lets you set up security contexts, so
that you don't have to replay the same token over and over, and
instead you can maintain some sort of state between a client and
server. This makes perfect sense, and it's definitely something you'd
want to be able to do.
The question then becomes, okay, so now you have this session
identifier you can use, instead of a "real" credential. How do you
protect this session identifier, so that someone listening in can't
steal it and use it on your behalf?
Your answer might be, "just use SSL", but I submit while that's a
workable answer for some scenarios, it's actually a fairly weak story,
in the general case.
Here are a few reasons why I think this.
1. Your session/state management code is going to have to track
session ids against client identities; otherwise, you've really got no
guarantee that the client is really the client you think s/he is. You
might try to "wing it", and reason, "Hey, we're using SSL here, so
there's a good chance that the session identifiers have not been
disclosed". But that's putting a lot of trust in a system, not trust
inherent in the infrastructure, itself. I personally try to steer
clear of systems like that (knowing full well it's the kind of systems
our banking infrastructure is built on :)
2. If you're associating session ids with client identities, your
client identities are going to have to be based on some non-
repudiatable credential, and if we're talking SSL, then you're forced
to use client certificates for all your clients. Unfortunately, this
can get pretty expensive, if you're contraction out your certificate
management. It also means you have a real key distribution problem on
your hands (assuming lots of clients to relatively few servers).
There's a reason SSL defaults to server authentication only -- client
certs are simply a PITA, and no one I've worked with likes to deal
with them.
(It may be that for some narrowly constrained cases, like middle-tiers
talking to back-end services, that client certs makes sense, but in
general I would submit that SSL does not scale well, when it comes to
client certificates, despite the fact that public key crypto has been
billed as a scalable solution to symmetric key distribution)
3. SSL is point to point, not end to end. So if you have an
intermediate in your mix, like a JMS broker, then forget about client
and certificate authentication, all together. You can authenticate
your broker, but from a skeptical security professional's point of
view, BFD. That and a nickel will get you a cuppa joe.
4. Some transports simply don't support SSL. So, we have HTTP and
IIOP support, but CXF is supposed to be "oh so much more than that".
What happens if you have a protocol that just hasn't been implemented
over SSL? Then we're kinda stuck.
(Again, if the above is a straw-man, from your point of view, I
apologize, and let's just shelve the arguments as common understanding)
So, a nice alternative approach is to use WS-Security, itself, to do
what SSL would otherwise do, viz., to provide encryption
(confidentiality) and signing (integrity) support, at the SOAP layer,
rather than down at the transport. The nice thing about that is that
it's truly end-to-end, sort of like using GPG for email -- screw the
bloody MTAs and the NSA in between -- they can't crack the crypto in
the playload.
The problem then becomes, WS-Security typically is deployed (and CXF
uses it this way) as a public-key crypto engine (WSS4J is capable of
symmetric-key crypto -- more on that below); senders sign with private
keys and encrypt with public keys, and receivers verify with public
keys and decrypt with private keys. It works, but it's /painfully/
slow and inefficient.
So I think the other part of WS-SecConv is to allow session key
derivation from sent tokens (a password, for example). From these /
symmetric/ session keys, clients and servers can then exchange
messages in a manner that is a lot more efficient that they would
using public keys.
The question then becomes, what material is sufficient for the
generation of a session key? Must it be a secret (e.g., a password)?
If so, how does one protect its transmission?
There are clearly answers to this, but my personal feeling is, they
are more or less reinventions of what's already been done with
Kerberos, and don't make any significant contributions to the level of
protection already provided by it.
> So I'm not
> exactly clear when you write "I think the right way to tackle that
> is to
> integrate with Kerberos and the GSS-API"--I think, whatever you do
> WS-SC-wise, would need to be generalized for *all* token profiles,
> not just
> Kerberos. But I'm hardly the most knowledgable on this stuff.
The kerberos token profile, in WS-Security, provdies a standardized
slot for a GSS-Kerberos AP_REQ token to get sent through as WS-
Security header. The GSS-API is an API, combined with a specific
security mechanism, (like Kerberos -- though Kerberos is one of many),
for creating tokens appropriate for security context negotiation, and
the eventual creation of a security context (as a logical
abstraction), which in turn can be used to sign, encrypt, and
authenticate messages sent between two entities (a client and server,
for example).
So while I agree that most seem to think of a kerberos token as just
another kind of security token, to be used as evidence of client
identity, I think that approach severely overlooks and diminishes the
true power of the Needham-Shroeder authentication protocol. The
tokens you send through the WS-Security token profile are actually the
kinds of token that can and should be used as part of security context
establishment between clients and servers, per the WS-
SecureConversation spec.
It turns out that IBM has a paper on exactly how to do this:
http://www.ibm.com/developerworks/library/specification/ws-seckerb/
and IMO this is an incredibly powerful way to leverage the WS-
SecureConversation spec; you'd essentially achieve single sign-on into
your web services tier, based solely on your OS (or windows domain)
login, and not based on possession or even submission of a secret (to
wit, a password), and we all know how much passwords suck.
So, perhaps that's too a lofty goal for the CXF community -- perhaps
CXF developers are after smaller game, like leveraging WS-SecConv to
do key derivation, and symmetric key crypto from there. And that's
fine. But I personally think the value of that, while very good for
some scenarios, is still likely to be password-based, and therefore
weak, from a security point of view. Not bad. And maybe people will
even use it. But it's not as compelling a story as you could
otherwise tell.
-Fred
Re: Ideas for 2.2
Posted by Bharath Ganesh <bh...@gmail.com>.
On Sat, Jun 21, 2008 at 2:35 AM, Glen Mazza <gl...@gmail.com> wrote:
>
> >>BTW, Fred, I'm reading "SOA Security" by publisher Manning right now, it
> says
> >>WSS4J is for Axis 1.x while Rampart is for Axis 2.0. That doesn't seem
> >>correct--isn't WSS4J used with both Axis1 and Axis2? Or is it just that
> >>Rampart uses WSS4J internally?
Yes Rampart is an Axis2 module on top of WSS4J, with a WS-SecurityPolicy
implementation, some features to send parts of message by MTOM and some
other additional configurations.
Thanks
Bharath
http://thoughts.bharathganesh.com
>
>
> As for the caching of the nonces, don't Axis 1 and Axis2 handle that
> themselves (because WSS4J can't do it itself right now, perhaps)? You want
> to make sure that if Client X made a request with nonce = 4, no more
> requests of X with that nonce value within the timeout period are made, so
> that offhand would appear to be something that the web service provider can
> handle. Then again, maybe this caching can be handled by WSS4J--less work
> for us.
>
> As for WS-SecureConversation, AFAICT it is just a generalization of
> WS-Security[1]--the tokens (of whatever type, Kerberos, SAML,
> UsernameToken,
> or whatever) are not continually regenerated/resent for each reply/request.
> It's primarily a performance issue--WS-SC makes things faster. So I'm not
> exactly clear when you write "I think the right way to tackle that is to
> integrate with Kerberos and the GSS-API"--I think, whatever you do
> WS-SC-wise, would need to be generalized for *all* token profiles, not just
> Kerberos. But I'm hardly the most knowledgable on this stuff.
>
> Regards,
> Glen
>
> [1] http://blogs.sun.com/trustjdg/entry/metro_and_netbeans_for_secure
>
>
>
> Fred Dushin-3 wrote:
> >
> > I think the right place for nonce support is in WSS4J, itself, though
> > honestly, a lot of work needs to be done to WSS4J to get it "up to
> > snuff" with CXF. (Java5, JaxB support, maven, etc etc)
> >
> > I'd like to get a sense of what people need, in terms of WS-
> > SecureConversation and WS-Trust support. What are the real use-cases
> > people need these specs for? Could we talk about specific interop
> > scenarios, for example? (WCF and Cardspace are fertile ground)
> >
> > As far as SAML support in WSS4J, yes, there is some support for this
> > profile, but we've run into a few issues:
> >
> > 1. It's using an outdated version of the opensaml libraries, and the
> > opensaml team is reluctant to support the version WSS4J is using;
> > 2. WSS4J doesn't provide much more than parsing support (using non-
> > standard representation of SAML data types) and signature support.
> > There is no support, AFAIK, of the various subject confirmation method
> > processing requirements dictated by the WS-Security SAML profile,
> > which is really the only guarantee of security (if you care about that
> > kind of thing).
> > 3. The opensaml folks seem reluctant to use JAX-B types for the
> > represenation of SAML Assertions.
> >
> > WS-SecureConversation is a big topic, and as I've discussed before in
> > this forum, I think the right way to tackle that is to integrate with
> > Kerberos and the GSS-API. Otherwise, we'd probably find ourselves re-
> > inventing the kerberos authentication protocol, and chances are, we'd
> > get it wrong. Why not tie in to a KDC, be it MIT'a, Heimdal'a, or
> > even, dare I even say it, ActiveDirectory? (Personally, my feeling is
> > that this sort of feature would have the most real value to users, as
> > it would give you integrated SSO into your web services, based simply
> > on your windows domain -- or PAM -- login. Death to passwords.)
> >
> > I'd also vote for client-side support for WS-SecurityPolicy. That's a
> > big requirement for interop with WCF, for example, and it should help
> > to simplify config a lot.
> >
> > -Fred
> >
> > On Jun 18, 2008, at 9:32 PM, Glen Mazza wrote:
> >
> >> I think our WSS4J interceptors really need to support "nonces"--IIRC
> >> according to WS-Security w/UsernameToken profile web service calls
> >> aren't really secure if those aren't included with the username,
> >> password, and timestamp. I am still not sure if WSS4J supports the
> >> SAML
> >> Token Profile, but that would also something we probably need. Having
> >> WS-SecureConversation would not be very meaningful for either SAML or
> >> UsernameTokens if we don't have the latter two working yet. (The
> >> other
> >> profile--X.509--I don't know how well that is supported presently, but
> >> if working, WS-SecureConversation then becomes sensible.)
> >>
> >> Possibly also, an ability to support Sun's XWSS product in addition to
> >> WSS4J (although I'm aware of the performance issues you had mentioned
> >> earlier), a nice-to-have since Spring-WS apparently supports both.
> >>
> >> Perhaps also WSDL 2.0?
> >>
> >> Glen
> >>
> >>
> >> 2008-06-18 Daniel Kulp wrote:
> >>> Now that 2.1.1 is being voted on, I'd like to step back a bit and
> >>> talk
> >>> a little about ideas for the next versions.
> >>>
> >>> First, most likely, we'll need to do a 2.1.2 release in about 6-8
> >>> weeks (and maybe 2.0.8 as well). We've done a very good job of
> >>> getting fixes out to our users in a timely manner and I'd like to
> >>> keep
> >>> that up, but I also would like to think about 2.2 a bit as well. I
> >>> haven't created the 2.1.x fixes branch yet, but I probably will
> >>> shortly if we start doing some new stuff toward 2.2.
> >>>
> >>> That said, here is my list of stuff that is "missing" and could be
> >>> considered for 2.2:
> >>>
> >>> 1) WS-Trust/WS-SecurePolicy/WS-SecureConversation stuff. Not
> >>> supporting these is becoming increasingly problematic. Most likely,
> >>> when I get back from my paternity leave, I'm going to start digging
> >>> into these a bit. I haven't really read up on these yet (in depth)
> >>> so
> >>> any help would be greatly appreciated.
> >>>
> >>> 2) XMLBeans tooling - I started this a bit for 2.1.1. 2.1.1 now
> >>> will
> >>> actually generate some interfaces for xmlbeans, but the sample
> >>> clients/
> >>> servers are wrong (don't set the jaxb databinding) and I'm not sure
> >>> if
> >>> the interfaces even work unless you use a jaxws customization to
> >>> force
> >>> everything into bare mode. Cleaning this stuff up could be a 2.1.x
> >>> "fix" as well.
> >>>
> >>> 3) JIBX data binding - This is probably the last major thing not
> >>> ported from XFire. Not sure the demand on it though.
> >>>
> >>> 4) Extension via annotation - Benson and I have chatted about this
> >>> off
> >>> and on. Basically, we'd like to add hooks into the
> >>> ReflectServiceFactoryBean so that registered listeners can get events
> >>> about when things happen. Like when an interface is mapped to a
> >>> ServiceInfo, a method is mapped to a OperaionInfo and
> >>> BingingOperationInfo, etc... The listeners can then examine the
> >>> Method object or Class object or whatever for any additional things
> >>> it's interested in at runtime. This would allow for some custom
> >>> annotations. Examples:
> >>> Configure some logging:
> >>> @Logging(in = "in.log", out = "out.log", fault = "<stderr>")
> >>> Configure and IDL location for the corba binding:
> >>> @IDLLocation("file:/foo.idl")
> >>> Add documentation to the wsdl:
> >>> @WSDLAnnotation("This operation does XXX")
> >>> etc...
> >>> Some of the stuff in the JAX-WS frontend could then be re-written to
> >>> use that. Processing of the @WebServiceFeature annotations and
> >>> stuff
> >>> could be re-implemented that way. The main thing here is to make
> >>> some of the java-first things work a bit better/easier. (our own
> >>> @Features annotation could be deprecated in favor of explicit
> >>> annotations for the features we have)
> >>>
> >>> 5) OSGi stuff - I know there are some OSGi enhancements in the works
> >>> that could be pulled in:
> >>> a) osgi http transport - this currently lives in ServiceMix, but
> >>> could be pulled into CXF to work with other OSGi runtimes
> >>> b) Distributed OSGi (RFC 119) - there is work being done to
> >>> implement RFC 119 with CXF. There are some rules about releasing
> >>> the
> >>> IP for this though that is being investigated.
> >>>
> >>> 6) JMS transport enhancements - I keep wanting to update this a bit
> >>> to
> >>> leverage spring jms stuff a bit better to make it much easier to
> >>> configure.
> >>>
> >>> 7) JAX-RS updates - to 0.7 at least. Maybe later versions as they
> >>> come up with them.
> >>>
> >>> 8) Web site update? I'd like to possibly create a quick logo and
> >>> update the site a bit to look a bit less like confluence. This is a
> >>> "would be nice anytime, not just for 2.2" type thing.
> >>>
> >>>
> >>> I'm sure there will be a bunch of other enhancements as well.
> >>> Stuff
> >>> like performance/memory enhancements, etc...
> >>>
> >>> Anyway, thoughts? Other ideas? Comments?
> >>>
> >>>
> >>> ---
> >>> Daniel Kulp
> >>> dkulp@apache.org
> >>> http://www.dankulp.com/blog
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Ideas-for-2.2-tp17985028p18037357.html
> Sent from the cxf-dev mailing list archive at Nabble.com.
>
>
Re: Ideas for 2.2
Posted by Glen Mazza <gl...@gmail.com>.
BTW, Fred, I'm reading "SOA Security" by publisher Manning right now, it says
WSS4J is for Axis 1.x while Rampart is for Axis 2.0. That doesn't seem
correct--isn't WSS4J used with both Axis1 and Axis2? Or is it just that
Rampart uses WSS4J internally? I'm trying to get a feel for how up-to-date
WSS4J is.
As for the caching of the nonces, don't Axis 1 and Axis2 handle that
themselves (because WSS4J can't do it itself right now, perhaps)? You want
to make sure that if Client X made a request with nonce = 4, no more
requests of X with that nonce value within the timeout period are made, so
that offhand would appear to be something that the web service provider can
handle. Then again, maybe this caching can be handled by WSS4J--less work
for us.
As for WS-SecureConversation, AFAICT it is just a generalization of
WS-Security[1]--the tokens (of whatever type, Kerberos, SAML, UsernameToken,
or whatever) are not continually regenerated/resent for each reply/request.
It's primarily a performance issue--WS-SC makes things faster. So I'm not
exactly clear when you write "I think the right way to tackle that is to
integrate with Kerberos and the GSS-API"--I think, whatever you do
WS-SC-wise, would need to be generalized for *all* token profiles, not just
Kerberos. But I'm hardly the most knowledgable on this stuff.
Regards,
Glen
[1] http://blogs.sun.com/trustjdg/entry/metro_and_netbeans_for_secure
Fred Dushin-3 wrote:
>
> I think the right place for nonce support is in WSS4J, itself, though
> honestly, a lot of work needs to be done to WSS4J to get it "up to
> snuff" with CXF. (Java5, JaxB support, maven, etc etc)
>
> I'd like to get a sense of what people need, in terms of WS-
> SecureConversation and WS-Trust support. What are the real use-cases
> people need these specs for? Could we talk about specific interop
> scenarios, for example? (WCF and Cardspace are fertile ground)
>
> As far as SAML support in WSS4J, yes, there is some support for this
> profile, but we've run into a few issues:
>
> 1. It's using an outdated version of the opensaml libraries, and the
> opensaml team is reluctant to support the version WSS4J is using;
> 2. WSS4J doesn't provide much more than parsing support (using non-
> standard representation of SAML data types) and signature support.
> There is no support, AFAIK, of the various subject confirmation method
> processing requirements dictated by the WS-Security SAML profile,
> which is really the only guarantee of security (if you care about that
> kind of thing).
> 3. The opensaml folks seem reluctant to use JAX-B types for the
> represenation of SAML Assertions.
>
> WS-SecureConversation is a big topic, and as I've discussed before in
> this forum, I think the right way to tackle that is to integrate with
> Kerberos and the GSS-API. Otherwise, we'd probably find ourselves re-
> inventing the kerberos authentication protocol, and chances are, we'd
> get it wrong. Why not tie in to a KDC, be it MIT'a, Heimdal'a, or
> even, dare I even say it, ActiveDirectory? (Personally, my feeling is
> that this sort of feature would have the most real value to users, as
> it would give you integrated SSO into your web services, based simply
> on your windows domain -- or PAM -- login. Death to passwords.)
>
> I'd also vote for client-side support for WS-SecurityPolicy. That's a
> big requirement for interop with WCF, for example, and it should help
> to simplify config a lot.
>
> -Fred
>
> On Jun 18, 2008, at 9:32 PM, Glen Mazza wrote:
>
>> I think our WSS4J interceptors really need to support "nonces"--IIRC
>> according to WS-Security w/UsernameToken profile web service calls
>> aren't really secure if those aren't included with the username,
>> password, and timestamp. I am still not sure if WSS4J supports the
>> SAML
>> Token Profile, but that would also something we probably need. Having
>> WS-SecureConversation would not be very meaningful for either SAML or
>> UsernameTokens if we don't have the latter two working yet. (The
>> other
>> profile--X.509--I don't know how well that is supported presently, but
>> if working, WS-SecureConversation then becomes sensible.)
>>
>> Possibly also, an ability to support Sun's XWSS product in addition to
>> WSS4J (although I'm aware of the performance issues you had mentioned
>> earlier), a nice-to-have since Spring-WS apparently supports both.
>>
>> Perhaps also WSDL 2.0?
>>
>> Glen
>>
>>
>> 2008-06-18 Daniel Kulp wrote:
>>> Now that 2.1.1 is being voted on, I'd like to step back a bit and
>>> talk
>>> a little about ideas for the next versions.
>>>
>>> First, most likely, we'll need to do a 2.1.2 release in about 6-8
>>> weeks (and maybe 2.0.8 as well). We've done a very good job of
>>> getting fixes out to our users in a timely manner and I'd like to
>>> keep
>>> that up, but I also would like to think about 2.2 a bit as well. I
>>> haven't created the 2.1.x fixes branch yet, but I probably will
>>> shortly if we start doing some new stuff toward 2.2.
>>>
>>> That said, here is my list of stuff that is "missing" and could be
>>> considered for 2.2:
>>>
>>> 1) WS-Trust/WS-SecurePolicy/WS-SecureConversation stuff. Not
>>> supporting these is becoming increasingly problematic. Most likely,
>>> when I get back from my paternity leave, I'm going to start digging
>>> into these a bit. I haven't really read up on these yet (in depth)
>>> so
>>> any help would be greatly appreciated.
>>>
>>> 2) XMLBeans tooling - I started this a bit for 2.1.1. 2.1.1 now
>>> will
>>> actually generate some interfaces for xmlbeans, but the sample
>>> clients/
>>> servers are wrong (don't set the jaxb databinding) and I'm not sure
>>> if
>>> the interfaces even work unless you use a jaxws customization to
>>> force
>>> everything into bare mode. Cleaning this stuff up could be a 2.1.x
>>> "fix" as well.
>>>
>>> 3) JIBX data binding - This is probably the last major thing not
>>> ported from XFire. Not sure the demand on it though.
>>>
>>> 4) Extension via annotation - Benson and I have chatted about this
>>> off
>>> and on. Basically, we'd like to add hooks into the
>>> ReflectServiceFactoryBean so that registered listeners can get events
>>> about when things happen. Like when an interface is mapped to a
>>> ServiceInfo, a method is mapped to a OperaionInfo and
>>> BingingOperationInfo, etc... The listeners can then examine the
>>> Method object or Class object or whatever for any additional things
>>> it's interested in at runtime. This would allow for some custom
>>> annotations. Examples:
>>> Configure some logging:
>>> @Logging(in = "in.log", out = "out.log", fault = "<stderr>")
>>> Configure and IDL location for the corba binding:
>>> @IDLLocation("file:/foo.idl")
>>> Add documentation to the wsdl:
>>> @WSDLAnnotation("This operation does XXX")
>>> etc...
>>> Some of the stuff in the JAX-WS frontend could then be re-written to
>>> use that. Processing of the @WebServiceFeature annotations and
>>> stuff
>>> could be re-implemented that way. The main thing here is to make
>>> some of the java-first things work a bit better/easier. (our own
>>> @Features annotation could be deprecated in favor of explicit
>>> annotations for the features we have)
>>>
>>> 5) OSGi stuff - I know there are some OSGi enhancements in the works
>>> that could be pulled in:
>>> a) osgi http transport - this currently lives in ServiceMix, but
>>> could be pulled into CXF to work with other OSGi runtimes
>>> b) Distributed OSGi (RFC 119) - there is work being done to
>>> implement RFC 119 with CXF. There are some rules about releasing
>>> the
>>> IP for this though that is being investigated.
>>>
>>> 6) JMS transport enhancements - I keep wanting to update this a bit
>>> to
>>> leverage spring jms stuff a bit better to make it much easier to
>>> configure.
>>>
>>> 7) JAX-RS updates - to 0.7 at least. Maybe later versions as they
>>> come up with them.
>>>
>>> 8) Web site update? I'd like to possibly create a quick logo and
>>> update the site a bit to look a bit less like confluence. This is a
>>> "would be nice anytime, not just for 2.2" type thing.
>>>
>>>
>>> I'm sure there will be a bunch of other enhancements as well.
>>> Stuff
>>> like performance/memory enhancements, etc...
>>>
>>> Anyway, thoughts? Other ideas? Comments?
>>>
>>>
>>> ---
>>> Daniel Kulp
>>> dkulp@apache.org
>>> http://www.dankulp.com/blog
>>>
>>>
>>>
>>>
>>
>>
>
>
>
--
View this message in context: http://www.nabble.com/Ideas-for-2.2-tp17985028p18037357.html
Sent from the cxf-dev mailing list archive at Nabble.com.
Re: Ideas for 2.2
Posted by Fred Dushin <fr...@dushin.net>.
I think the right place for nonce support is in WSS4J, itself, though
honestly, a lot of work needs to be done to WSS4J to get it "up to
snuff" with CXF. (Java5, JaxB support, maven, etc etc)
I'd like to get a sense of what people need, in terms of WS-
SecureConversation and WS-Trust support. What are the real use-cases
people need these specs for? Could we talk about specific interop
scenarios, for example? (WCF and Cardspace are fertile ground)
As far as SAML support in WSS4J, yes, there is some support for this
profile, but we've run into a few issues:
1. It's using an outdated version of the opensaml libraries, and the
opensaml team is reluctant to support the version WSS4J is using;
2. WSS4J doesn't provide much more than parsing support (using non-
standard representation of SAML data types) and signature support.
There is no support, AFAIK, of the various subject confirmation method
processing requirements dictated by the WS-Security SAML profile,
which is really the only guarantee of security (if you care about that
kind of thing).
3. The opensaml folks seem reluctant to use JAX-B types for the
represenation of SAML Assertions.
WS-SecureConversation is a big topic, and as I've discussed before in
this forum, I think the right way to tackle that is to integrate with
Kerberos and the GSS-API. Otherwise, we'd probably find ourselves re-
inventing the kerberos authentication protocol, and chances are, we'd
get it wrong. Why not tie in to a KDC, be it MIT'a, Heimdal'a, or
even, dare I even say it, ActiveDirectory? (Personally, my feeling is
that this sort of feature would have the most real value to users, as
it would give you integrated SSO into your web services, based simply
on your windows domain -- or PAM -- login. Death to passwords.)
I'd also vote for client-side support for WS-SecurityPolicy. That's a
big requirement for interop with WCF, for example, and it should help
to simplify config a lot.
-Fred
On Jun 18, 2008, at 9:32 PM, Glen Mazza wrote:
> I think our WSS4J interceptors really need to support "nonces"--IIRC
> according to WS-Security w/UsernameToken profile web service calls
> aren't really secure if those aren't included with the username,
> password, and timestamp. I am still not sure if WSS4J supports the
> SAML
> Token Profile, but that would also something we probably need. Having
> WS-SecureConversation would not be very meaningful for either SAML or
> UsernameTokens if we don't have the latter two working yet. (The
> other
> profile--X.509--I don't know how well that is supported presently, but
> if working, WS-SecureConversation then becomes sensible.)
>
> Possibly also, an ability to support Sun's XWSS product in addition to
> WSS4J (although I'm aware of the performance issues you had mentioned
> earlier), a nice-to-have since Spring-WS apparently supports both.
>
> Perhaps also WSDL 2.0?
>
> Glen
>
>
> 2008-06-18 Daniel Kulp wrote:
>> Now that 2.1.1 is being voted on, I'd like to step back a bit and
>> talk
>> a little about ideas for the next versions.
>>
>> First, most likely, we'll need to do a 2.1.2 release in about 6-8
>> weeks (and maybe 2.0.8 as well). We've done a very good job of
>> getting fixes out to our users in a timely manner and I'd like to
>> keep
>> that up, but I also would like to think about 2.2 a bit as well. I
>> haven't created the 2.1.x fixes branch yet, but I probably will
>> shortly if we start doing some new stuff toward 2.2.
>>
>> That said, here is my list of stuff that is "missing" and could be
>> considered for 2.2:
>>
>> 1) WS-Trust/WS-SecurePolicy/WS-SecureConversation stuff. Not
>> supporting these is becoming increasingly problematic. Most likely,
>> when I get back from my paternity leave, I'm going to start digging
>> into these a bit. I haven't really read up on these yet (in depth)
>> so
>> any help would be greatly appreciated.
>>
>> 2) XMLBeans tooling - I started this a bit for 2.1.1. 2.1.1 now
>> will
>> actually generate some interfaces for xmlbeans, but the sample
>> clients/
>> servers are wrong (don't set the jaxb databinding) and I'm not sure
>> if
>> the interfaces even work unless you use a jaxws customization to
>> force
>> everything into bare mode. Cleaning this stuff up could be a 2.1.x
>> "fix" as well.
>>
>> 3) JIBX data binding - This is probably the last major thing not
>> ported from XFire. Not sure the demand on it though.
>>
>> 4) Extension via annotation - Benson and I have chatted about this
>> off
>> and on. Basically, we'd like to add hooks into the
>> ReflectServiceFactoryBean so that registered listeners can get events
>> about when things happen. Like when an interface is mapped to a
>> ServiceInfo, a method is mapped to a OperaionInfo and
>> BingingOperationInfo, etc... The listeners can then examine the
>> Method object or Class object or whatever for any additional things
>> it's interested in at runtime. This would allow for some custom
>> annotations. Examples:
>> Configure some logging:
>> @Logging(in = "in.log", out = "out.log", fault = "<stderr>")
>> Configure and IDL location for the corba binding:
>> @IDLLocation("file:/foo.idl")
>> Add documentation to the wsdl:
>> @WSDLAnnotation("This operation does XXX")
>> etc...
>> Some of the stuff in the JAX-WS frontend could then be re-written to
>> use that. Processing of the @WebServiceFeature annotations and
>> stuff
>> could be re-implemented that way. The main thing here is to make
>> some of the java-first things work a bit better/easier. (our own
>> @Features annotation could be deprecated in favor of explicit
>> annotations for the features we have)
>>
>> 5) OSGi stuff - I know there are some OSGi enhancements in the works
>> that could be pulled in:
>> a) osgi http transport - this currently lives in ServiceMix, but
>> could be pulled into CXF to work with other OSGi runtimes
>> b) Distributed OSGi (RFC 119) - there is work being done to
>> implement RFC 119 with CXF. There are some rules about releasing
>> the
>> IP for this though that is being investigated.
>>
>> 6) JMS transport enhancements - I keep wanting to update this a bit
>> to
>> leverage spring jms stuff a bit better to make it much easier to
>> configure.
>>
>> 7) JAX-RS updates - to 0.7 at least. Maybe later versions as they
>> come up with them.
>>
>> 8) Web site update? I'd like to possibly create a quick logo and
>> update the site a bit to look a bit less like confluence. This is a
>> "would be nice anytime, not just for 2.2" type thing.
>>
>>
>> I'm sure there will be a bunch of other enhancements as well.
>> Stuff
>> like performance/memory enhancements, etc...
>>
>> Anyway, thoughts? Other ideas? Comments?
>>
>>
>> ---
>> Daniel Kulp
>> dkulp@apache.org
>> http://www.dankulp.com/blog
>>
>>
>>
>>
>
>
Re: Ideas for 2.2
Posted by Glen Mazza <gl...@verizon.net>.
I think our WSS4J interceptors really need to support "nonces"--IIRC
according to WS-Security w/UsernameToken profile web service calls
aren't really secure if those aren't included with the username,
password, and timestamp. I am still not sure if WSS4J supports the SAML
Token Profile, but that would also something we probably need. Having
WS-SecureConversation would not be very meaningful for either SAML or
UsernameTokens if we don't have the latter two working yet. (The other
profile--X.509--I don't know how well that is supported presently, but
if working, WS-SecureConversation then becomes sensible.)
Possibly also, an ability to support Sun's XWSS product in addition to
WSS4J (although I'm aware of the performance issues you had mentioned
earlier), a nice-to-have since Spring-WS apparently supports both.
Perhaps also WSDL 2.0?
Glen
2008-06-18 Daniel Kulp wrote:
> Now that 2.1.1 is being voted on, I'd like to step back a bit and talk
> a little about ideas for the next versions.
>
> First, most likely, we'll need to do a 2.1.2 release in about 6-8
> weeks (and maybe 2.0.8 as well). We've done a very good job of
> getting fixes out to our users in a timely manner and I'd like to keep
> that up, but I also would like to think about 2.2 a bit as well. I
> haven't created the 2.1.x fixes branch yet, but I probably will
> shortly if we start doing some new stuff toward 2.2.
>
> That said, here is my list of stuff that is "missing" and could be
> considered for 2.2:
>
> 1) WS-Trust/WS-SecurePolicy/WS-SecureConversation stuff. Not
> supporting these is becoming increasingly problematic. Most likely,
> when I get back from my paternity leave, I'm going to start digging
> into these a bit. I haven't really read up on these yet (in depth) so
> any help would be greatly appreciated.
>
> 2) XMLBeans tooling - I started this a bit for 2.1.1. 2.1.1 now will
> actually generate some interfaces for xmlbeans, but the sample clients/
> servers are wrong (don't set the jaxb databinding) and I'm not sure if
> the interfaces even work unless you use a jaxws customization to force
> everything into bare mode. Cleaning this stuff up could be a 2.1.x
> "fix" as well.
>
> 3) JIBX data binding - This is probably the last major thing not
> ported from XFire. Not sure the demand on it though.
>
> 4) Extension via annotation - Benson and I have chatted about this off
> and on. Basically, we'd like to add hooks into the
> ReflectServiceFactoryBean so that registered listeners can get events
> about when things happen. Like when an interface is mapped to a
> ServiceInfo, a method is mapped to a OperaionInfo and
> BingingOperationInfo, etc... The listeners can then examine the
> Method object or Class object or whatever for any additional things
> it's interested in at runtime. This would allow for some custom
> annotations. Examples:
> Configure some logging:
> @Logging(in = "in.log", out = "out.log", fault = "<stderr>")
> Configure and IDL location for the corba binding:
> @IDLLocation("file:/foo.idl")
> Add documentation to the wsdl:
> @WSDLAnnotation("This operation does XXX")
> etc...
> Some of the stuff in the JAX-WS frontend could then be re-written to
> use that. Processing of the @WebServiceFeature annotations and stuff
> could be re-implemented that way. The main thing here is to make
> some of the java-first things work a bit better/easier. (our own
> @Features annotation could be deprecated in favor of explicit
> annotations for the features we have)
>
> 5) OSGi stuff - I know there are some OSGi enhancements in the works
> that could be pulled in:
> a) osgi http transport - this currently lives in ServiceMix, but
> could be pulled into CXF to work with other OSGi runtimes
> b) Distributed OSGi (RFC 119) - there is work being done to
> implement RFC 119 with CXF. There are some rules about releasing the
> IP for this though that is being investigated.
>
> 6) JMS transport enhancements - I keep wanting to update this a bit to
> leverage spring jms stuff a bit better to make it much easier to
> configure.
>
> 7) JAX-RS updates - to 0.7 at least. Maybe later versions as they
> come up with them.
>
> 8) Web site update? I'd like to possibly create a quick logo and
> update the site a bit to look a bit less like confluence. This is a
> "would be nice anytime, not just for 2.2" type thing.
>
>
> I'm sure there will be a bunch of other enhancements as well. Stuff
> like performance/memory enhancements, etc...
>
> Anyway, thoughts? Other ideas? Comments?
>
>
> ---
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>
>
>
>
Re: Ideas for 2.2
Posted by Eoghan Glynn <eg...@iona.com>.
Daniel Kulp wrote:
>
> 5) OSGi stuff - I know there are some OSGi enhancements in the works
> that could be pulled in:
> a) osgi http transport - this currently lives in ServiceMix, but
> could be pulled into CXF to work with other OSGi runtimes
> b) Distributed OSGi (RFC 119) - there is work being done to implement
> RFC 119 with CXF. There are some rules about releasing the IP for this
> though that is being investigated.
Sergey and myself have been working on a CXF-based reference
implementation of RFC 119, and we'd be on for contributing this to CXF
once the IP is cleared by the OGSi expert group. Hopefuly this will
happen within the next month or so.
Cheers,
Eoghan
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: Ideas for 2.2
Posted by Richard Opalka <ro...@redhat.com>.
What about folks to spend some time on JBossWS integration issues
http://issues.apache.org/jira/browse/CXF-1243 ?
Richard
Daniel Kulp wrote:
>
> Now that 2.1.1 is being voted on, I'd like to step back a bit and talk
> a little about ideas for the next versions.
>
> First, most likely, we'll need to do a 2.1.2 release in about 6-8
> weeks (and maybe 2.0.8 as well). We've done a very good job of
> getting fixes out to our users in a timely manner and I'd like to keep
> that up, but I also would like to think about 2.2 a bit as well. I
> haven't created the 2.1.x fixes branch yet, but I probably will
> shortly if we start doing some new stuff toward 2.2.
>
> That said, here is my list of stuff that is "missing" and could be
> considered for 2.2:
>
> 1) WS-Trust/WS-SecurePolicy/WS-SecureConversation stuff. Not
> supporting these is becoming increasingly problematic. Most likely,
> when I get back from my paternity leave, I'm going to start digging
> into these a bit. I haven't really read up on these yet (in depth) so
> any help would be greatly appreciated.
>
> 2) XMLBeans tooling - I started this a bit for 2.1.1. 2.1.1 now will
> actually generate some interfaces for xmlbeans, but the sample
> clients/servers are wrong (don't set the jaxb databinding) and I'm not
> sure if the interfaces even work unless you use a jaxws customization
> to force everything into bare mode. Cleaning this stuff up could be
> a 2.1.x "fix" as well.
>
> 3) JIBX data binding - This is probably the last major thing not
> ported from XFire. Not sure the demand on it though.
>
> 4) Extension via annotation - Benson and I have chatted about this off
> and on. Basically, we'd like to add hooks into the
> ReflectServiceFactoryBean so that registered listeners can get events
> about when things happen. Like when an interface is mapped to a
> ServiceInfo, a method is mapped to a OperaionInfo and
> BingingOperationInfo, etc... The listeners can then examine the
> Method object or Class object or whatever for any additional things
> it's interested in at runtime. This would allow for some custom
> annotations. Examples:
> Configure some logging:
> @Logging(in = "in.log", out = "out.log", fault = "<stderr>")
> Configure and IDL location for the corba binding:
> @IDLLocation("file:/foo.idl")
> Add documentation to the wsdl:
> @WSDLAnnotation("This operation does XXX")
> etc...
> Some of the stuff in the JAX-WS frontend could then be re-written to
> use that. Processing of the @WebServiceFeature annotations and stuff
> could be re-implemented that way. The main thing here is to make
> some of the java-first things work a bit better/easier. (our own
> @Features annotation could be deprecated in favor of explicit
> annotations for the features we have)
>
> 5) OSGi stuff - I know there are some OSGi enhancements in the works
> that could be pulled in:
> a) osgi http transport - this currently lives in ServiceMix, but
> could be pulled into CXF to work with other OSGi runtimes
> b) Distributed OSGi (RFC 119) - there is work being done to
> implement RFC 119 with CXF. There are some rules about releasing the
> IP for this though that is being investigated.
>
> 6) JMS transport enhancements - I keep wanting to update this a bit to
> leverage spring jms stuff a bit better to make it much easier to
> configure.
>
> 7) JAX-RS updates - to 0.7 at least. Maybe later versions as they
> come up with them.
>
> 8) Web site update? I'd like to possibly create a quick logo and
> update the site a bit to look a bit less like confluence. This is a
> "would be nice anytime, not just for 2.2" type thing.
>
>
> I'm sure there will be a bunch of other enhancements as well. Stuff
> like performance/memory enhancements, etc...
>
> Anyway, thoughts? Other ideas? Comments?
>
>
> ---
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>
>
>
>
--
B.Sc. Richard Opalka
Senior Software Engineer
JBoss, a division of Red Hat
Mobile: +420 731 186 942
Mail: ropalka@redhat.com
Re: Ideas for 2.2
Posted by javian <ja...@gmx.net>.
Are the annotations for the WSDL documentation (and logging, .... of course)
intended for the use with the AEGIS binding as well? Or will it only work
with the JAXB binding?
We are generating our sources with AndroMDA, so another possibility is the
use of *.doc.xml files that were used by XFire, these files can easily be
generated ...
Additionally, it would be great to document all parts of the WSDL:
operations, parameters, types, type parameter, responses, exceptions ...
Cheers, Juergen
On Wed, 2008-06-18 at 11:17 -0400, Daniel Kulp wrote:
...
> 4) Extension via annotation - Benson and I have chatted about this off
> and on. Basically, we'd like to add hooks into the
> ReflectServiceFactoryBean so that registered listeners can get events
> about when things happen. Like when an interface is mapped to a
> ServiceInfo, a method is mapped to a OperaionInfo and
> BingingOperationInfo, etc... The listeners can then examine the
> Method object or Class object or whatever for any additional things
> it's interested in at runtime. This would allow for some custom
> annotations. Examples:
> Configure some logging:
> @Logging(in = "in.log", out = "out.log", fault = "<stderr>")
> Configure and IDL location for the corba binding:
> @IDLLocation("file:/foo.idl")
> Add documentation to the wsdl:
> @WSDLAnnotation("This operation does XXX")
> etc...
> Some of the stuff in the JAX-WS frontend could then be re-written to
> use that. Processing of the @WebServiceFeature annotations and stuff
> could be re-implemented that way. The main thing here is to make
> some of the java-first things work a bit better/easier. (our own
> @Features annotation could be deprecated in favor of explicit
> annotations for the features we have)
...
--
View this message in context: http://www.nabble.com/Ideas-for-2.2-tp17985028p17998530.html
Sent from the cxf-dev mailing list archive at Nabble.com.
Re: Ideas for 2.2
Posted by Eric Johnson <er...@iona.com>.
I like the idea of custom annotations for making the Java-first stuff
work better.
On Wed, 2008-06-18 at 11:17 -0400, Daniel Kulp wrote:
> Now that 2.1.1 is being voted on, I'd like to step back a bit and talk
> a little about ideas for the next versions.
>
> First, most likely, we'll need to do a 2.1.2 release in about 6-8
> weeks (and maybe 2.0.8 as well). We've done a very good job of
> getting fixes out to our users in a timely manner and I'd like to keep
> that up, but I also would like to think about 2.2 a bit as well. I
> haven't created the 2.1.x fixes branch yet, but I probably will
> shortly if we start doing some new stuff toward 2.2.
>
> That said, here is my list of stuff that is "missing" and could be
> considered for 2.2:
>
> 1) WS-Trust/WS-SecurePolicy/WS-SecureConversation stuff. Not
> supporting these is becoming increasingly problematic. Most likely,
> when I get back from my paternity leave, I'm going to start digging
> into these a bit. I haven't really read up on these yet (in depth) so
> any help would be greatly appreciated.
>
> 2) XMLBeans tooling - I started this a bit for 2.1.1. 2.1.1 now will
> actually generate some interfaces for xmlbeans, but the sample clients/
> servers are wrong (don't set the jaxb databinding) and I'm not sure if
> the interfaces even work unless you use a jaxws customization to force
> everything into bare mode. Cleaning this stuff up could be a 2.1.x
> "fix" as well.
>
> 3) JIBX data binding - This is probably the last major thing not
> ported from XFire. Not sure the demand on it though.
>
> 4) Extension via annotation - Benson and I have chatted about this off
> and on. Basically, we'd like to add hooks into the
> ReflectServiceFactoryBean so that registered listeners can get events
> about when things happen. Like when an interface is mapped to a
> ServiceInfo, a method is mapped to a OperaionInfo and
> BingingOperationInfo, etc... The listeners can then examine the
> Method object or Class object or whatever for any additional things
> it's interested in at runtime. This would allow for some custom
> annotations. Examples:
> Configure some logging:
> @Logging(in = "in.log", out = "out.log", fault = "<stderr>")
> Configure and IDL location for the corba binding:
> @IDLLocation("file:/foo.idl")
> Add documentation to the wsdl:
> @WSDLAnnotation("This operation does XXX")
> etc...
> Some of the stuff in the JAX-WS frontend could then be re-written to
> use that. Processing of the @WebServiceFeature annotations and stuff
> could be re-implemented that way. The main thing here is to make
> some of the java-first things work a bit better/easier. (our own
> @Features annotation could be deprecated in favor of explicit
> annotations for the features we have)
>
> 5) OSGi stuff - I know there are some OSGi enhancements in the works
> that could be pulled in:
> a) osgi http transport - this currently lives in ServiceMix, but
> could be pulled into CXF to work with other OSGi runtimes
> b) Distributed OSGi (RFC 119) - there is work being done to
> implement RFC 119 with CXF. There are some rules about releasing the
> IP for this though that is being investigated.
>
> 6) JMS transport enhancements - I keep wanting to update this a bit to
> leverage spring jms stuff a bit better to make it much easier to
> configure.
>
> 7) JAX-RS updates - to 0.7 at least. Maybe later versions as they
> come up with them.
>
> 8) Web site update? I'd like to possibly create a quick logo and
> update the site a bit to look a bit less like confluence. This is a
> "would be nice anytime, not just for 2.2" type thing.
>
>
> I'm sure there will be a bunch of other enhancements as well. Stuff
> like performance/memory enhancements, etc...
>
> Anyway, thoughts? Other ideas? Comments?
>
>
> ---
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>
>
>