Thank you Thomas, unfortunately my emails are bounced from the jbossws-dev mailing list. So I hope that whomever is listening in on that channel isn't getting confused by the disjointed conversation. Many responses below. Thomas Diesler wrote: > Hi Burr, > > Please see my response inlined. > > Burr Sutter wrote: >> Was that answer the same as the one below. :-) >> >> It seems that based on the current answer we are moving forward with >> JBossWS Native for AS 5, EAP 5 and SOA Platform 4.3. >> So the following are current & planned for "missing" items (I'm just >> trying to make sure that I have my story straight) >> - While WS-RM is a new feature, it appears to not be making it into >> AS 5.0, EAP 5 > > Yes, it will be in AS50 (release date 1-Apr) > > http://jira.jboss.org/jira/browse/JBWS?report=com.atlassian.jira.plugin.s... > Excellent news. Thank you. It was unclear to me which version of JBossWS had WS-RM support and which one would make it into AS5/EAP5. This is worthy of some marketing attention in either a future ESB or AS release. It looks like docs are here: http://jbws.dyndns.org/mediawiki/index.php?title=WS_Reliable_Messaging Let me ask the stupid marketing guy question: Is there anything in WS-RM that works like a JMS topic? Something where I can "broadcast" or "push" out a message to N receivers (e.g. VB WinForm app) who have a background thread waiting on this event? Or is that more what WS-Eventing and WS-Notification are for? I ask this question because this specific use case has been requested before. Mostly in the context of ESB. ServiceMix seems to achieve this via WS-Notification.

> >> - An incomplete WS-Security offering (I can't remember which features >> are considered to be "incomplete" - this comment was from a customer) >> - No AtomicTransaction >> - No BusinessActivity >> - No Coordination > > You can monitor > http://jira.jboss.org/jira/browse/JBWS-461 I've added myself as a watcher. > >> - No Trust >> - No SecureConversation >> - No REST (not necessarily tied to JBossWS but falls in the same >> category) > > We try to unlock these from jbossws-metro I assume having Metro integrated with AS/EAP to support these features is much easier than trying to recreate them in our own native codebase.

CXF via JBossWS that we'll get some of these more "advanced" WS-* checkboxes/tick marks much more easily than trying to build them wholly on our own. This has come up in a few different sales situations recently. > >> - No non-HTTP transports > > We have jms transport I've just noticed we added some JAX-WS docs around this capability at http://jbws.dyndns.org/mediawiki/index.php?title=JAX-WS_User_Guide#JMS_Tr.... Before it was only documented as a JAX-RPC feature hence the belief that it didn't exist in the JAX-WS world (from a presales perspective). I should sit down and re-read everything in the JBossWS wiki and work with the sales team to get this updated. :-)

>> - No tooling in JBDS ( a recent complaint from a few customers, JBDS >> ships with Axis tooling and not SoapUI) - we'd like both contract >> first & pojo-first tooing > > Tooling is indeed a very weak spot. AFAIK, we don't even have a > strategy for that since SoapUI is out (without replacement nor my > consent). I'll try to bring this up with the JBDS folks. I don't believe we should ship a tool that targets a server-side component that directly competes with our own. For instance, we wouldn't have TopLink tooling in JBDS instead of Hibernate. Is that an apt analogy? > >> - No Notification (I'm aware that this is a dead standard, but people >> like it in the ServiceMix & CXF worlds) >> - No Spring integration (more people are adopting the Spring-way of >> "wiring" & configuration) >> - No JON, SOA Software & Amberpoint properly integrated for runtime >> monitoring/management/governance > > Not on the roadmap, if not provided by metro/cxf JON integration needs to be a priority. The current information and capabilities which show up in the current jmx-console & the stuff shown at http://localhost:8080/jbossws needs to also be available in JON. We also need to help Amberpoint finish their integration but the majority of the work is on them with us support them, fixing whatever issues they encounter. Governance is a "big deal" in 2008 and SOA Software/Amberpoint are the best ways for us to get there. > >> >> How about WSDL 2.0? I'm drawing a blank on where that one stands but >> I think it is a No as well. > > WSDL-2.0 is practically irrelevant AFAICT Good point. Customers do ask but if .NET can't consume it or produce it then it is irrelevant. Does anyone know if .NET supports it? > >> >> From my "marketing" perspective, that is a lot of NOs at this point >> in the overall game. BEA, Oracle & IBM are "hurting" us in this >> area. Luckily our customers haven't widely adopted WS-* overall but >> if we wish to be taken seriously in the SOA space, we'll need to at >> least keep up with the other open source engines (Glassfish, >> Geronimo, Mule, ServiceMix). > > With the current resource situation we can allocate 25% (i.e. one guy > to metro/cxf integration) Based on this comment and Mark's previous one suggesting 10 more people be found, it sounds like in order to make CXF or Metro a "first class citizens" and fully supported on EAP and/or SOA-P we would need to ramp up dramatically on the JBossWS team, at least temporarily. In your estimation, is it really 10 new senior developers for 10 more months to get ourselves as a committer to Metro or CXF and to make it "feel" like a native component of EAP/SOA-P and have it fully supported for customers? Assuming 100% WS-* and interop capabilities are inherited by us via this effort?

> >> >> >> >> Mark Little wrote: >>> We answered this already, right? >>> >>> Mark. >>> >>> >>> On 10 Mar 2008, at 13:53, Thomas Diesler wrote: >>> >>>> Hi Folks, >>>> >>>> We discussed this topic on Friday last week during our internal >>>> team workshop. As a result we came up with the idea of defining the >>>> set of required functionality for an enterprise ready web service >>>> stack and compare what we currently have in all three stacks. The >>>> result of this comparison would give us a clearer idea of how we >>>> want to move forward and how we distribute our available resources. >>>> >>>> http://jbws.dyndns.org/mediawiki/index.php?title=JBossWSSupportedStackCom... >>>> >>>> >>>> Native is the only certified stack, integration work for WS-TX >>>> pending, weak in the tools area. >>>> >>>> CXF has javaee5 certification pending, integration and >>>> documentation of extended functionality pending. >>>> >>>> Metro has javaee5 certification pending, integration and >>>> documentation of extended functionality pending. Metro is also >>>> considering their offer complete. >>>> >>>> My preferred strategy would be to gradually unlock more of the >>>> Metro/CXF functionality (maybe 20% of our time) and start the TCK >>>> effort for one of the stacks when/if we decide to replace our >>>> default stack. But instead of jumping to a conclusion, I would like >>>> to bounce this back to you for feedback. >>>> >>>> cheers >>>> -thomas >>>> >>>> >>>> Mark Little wrote: >>>>> I would have thought that JBossWS-native is the tier 1 because we >>>>> know we can support it now and then Metro and CXF as tier 2/3. >>>>> Obviously things may change in subsequent releases, as long as >>>>> backward compatibility isn't broken. >>>>> Mark. >>>>> On 6 Mar 2008, at 22:16, Andrig T Miller wrote: >>>>>> Mark and Thomas, >>>>>> >>>>>> Since we all are now on the same page about what version of >>>>>> our WS stack is in AS 5, the question now for EAP 5, is which web >>>>>> service stack, our own JBoss Native, CXF or Metro are we actually >>>>>> going to ship with EAP 5. Of course, whatever version it is >>>>>> needs to pass the Java EE 5 TCK, and not be missing anything we >>>>>> have supported from a feature perspective in previous EAP >>>>>> releases (4.2 and 4.3). The consensus, in the discussion so far, >>>>>> is that we also only want to ship one, and hence support one stack. >>>>>> >>>>>> Thoughts? >>>>>> >>>>>> Thanks. >>>>>> >>>>>> Andrig (Andy) Miller >>>>>> VP of Engineering >>>>>> JBoss, a division of Red Hat >>>>>> >>>>> ---- >>>>> Mark Little >>>>> mlittle(a)redhat.com <mailto:mlittle@redhat.com> >>>>> JBoss, a Division of Red Hat >>>>> Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 >>>>> Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. >>>>> Registered in UK and Wales under Company Registration No. 3798903 >>>>> Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt >>>>> Parsons (USA) and Brendan Lane (Ireland). >>>> >>>> -- >>>> xxxxxxxxxxxxxxxxxxxxxxxxxxxx >>>> Thomas Diesler >>>> Web Service Lead >>>> JBoss, a division of Red Hat >>>> xxxxxxxxxxxxxxxxxxxxxxxxxxxx >>> >>> ---- >>> Mark Little >>> mlittle(a)redhat.com >>> >>> JBoss, a Division of Red Hat >>> Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod >>> Street, Windsor, Berkshire, SI4 1TE, United Kingdom. >>> Registered in UK and Wales under Company Registration No. 3798903 >>> Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt >>> Parsons (USA) and Brendan Lane (Ireland). >>> >> >