[Design of JBoss Web Services] - Re: Integration metro
by thomas.diesler＠jboss.com
Being curious about why the metro integration requires
sun-jaxws=2.1.3
I did a scan in wsit
| [tdiesler@tddell glassfish-metro]$ ls wsit/wsit/lib/runtime
| activation.jar jaxb-api.jar jaxrpc-spi.jar jsr173_1.0_src.zip README-BIN.txt sjsxp-src.zip txnannprocessor.jar
| activation-src.zip jaxb-api-src.zip jaxws-api-doc.zip jsr173_api.jar resolver.jar special-README.txt txnannprocessor-src.zip
| CVS jaxb-impl.jar jaxws-api.jar jsr181-api.jar resolver-src.zip stax-ex.jar wstx-asl-3.2.1.jar
| FastInfoset.jar jaxb-impl.src.zip jaxws-api-src.zip jsr181-api.src.zip saaj-api.jar stax-ex-src.zip wstx-src-3.2.1.zip
| FastInfoset.src.zip jaxr-api.jar jaxws-local-transport.jar jsr250-api.jar saaj-api-src.zip stax-utils.jar xmldsig.jar
| http.jar jaxr-impl.jar jaxws-local-transport-src.zip mail-1.4.jar saaj-impl.jar stax-utils-src.zip xmlsec.jar
| jaxb1-impl.jar jaxrpc-api.jar jaxws-rt.jar mimepull.jar saaj-impl.src.zip streambuffer.jar xws-security.jar
| jaxb-api-doc.zip jaxrpc-impl.jar jaxws-rt.src.zip mimepull-src.zip sjsxp.jar streambuffer.src.zip xws-security.src.zip
|
It seems natural that wsit comes with all its dependencies, which would make a seperate download of these artifacts redundant (if not incorrect)
Why do we have this dependency on sun-jaxws and if it is needed how does it relate to the wsit build and our deployment?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138075#4138075
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138075
16 years, 9 months
[Design of JBoss Web Services] - Hudson thirdparty downloads
by thomas.diesler＠jboss.com
For the last couple of runs Metro-Core-4.2.x had lots of regression which could not be reproduced locally
| [tdiesler@jbws jobs]$ find *-AS-4.2.?/workspace/stack-*/thirdparty -name jbossws-jboss42-resources.zip | xargs ls -l
| -rw-rw-r-- 1 tdiesler tdiesler 4767 Nov 20 18:32 AS-Tests-AS-4.2.1/workspace/stack-native/thirdparty/jbossws-jboss42-resources.zip
| -rw-rw-r-- 1 tdiesler tdiesler 4767 Nov 20 18:32 AS-Tests-AS-4.2.2/workspace/stack-native/thirdparty/jbossws-jboss42-resources.zip
| -rw-rw-r-- 1 tdiesler tdiesler 4767 Nov 20 18:32 AS-Tests-AS-4.2.3/workspace/stack-native/thirdparty/jbossws-jboss42-resources.zip
| -rw-rw-r-- 1 tdiesler tdiesler 4767 Mar 20 12:44 CXF-Distro-AS-4.2.2/workspace/stack-cxf/thirdparty/jbossws-jboss42-resources.zip
| -rw-rw-r-- 1 tdiesler tdiesler 4767 Mar 20 12:51 CXF-Distro-AS-4.2.3/workspace/stack-cxf/thirdparty/jbossws-jboss42-resources.zip
| -rw-rw-r-- 1 tdiesler tdiesler 4767 Mar 20 12:31 CXF-Integration-AS-4.2.2/workspace/stack-cxf/thirdparty/jbossws-jboss42-resources.zip
| -rw-rw-r-- 1 tdiesler tdiesler 4767 Mar 20 12:38 CXF-Integration-AS-4.2.3/workspace/stack-cxf/thirdparty/jbossws-jboss42-resources.zip
| -rw-rw-r-- 1 tdiesler tdiesler 5217 Mar 18 18:28 Metro-Core-AS-4.2.2/workspace/stack-metro/thirdparty/jbossws-jboss42-resources.zip
| -rw-rw-r-- 1 tdiesler tdiesler 5217 Mar 18 18:28 Metro-Core-AS-4.2.3/workspace/stack-metro/thirdparty/jbossws-jboss42-resources.zip
| -rw-rw-r-- 1 tdiesler tdiesler 4767 Nov 20 18:32 Metro-Distro-AS-4.2.2/workspace/stack-metro/thirdparty/jbossws-jboss42-resources.zip
| -rw-rw-r-- 1 tdiesler tdiesler 4767 Nov 20 18:32 Metro-Distro-AS-4.2.3/workspace/stack-metro/thirdparty/jbossws-jboss42-resources.zip
| -rw-rw-r-- 1 tdiesler tdiesler 4767 Nov 20 18:32 Metro-Integration-AS-4.2.2/workspace/stack-metro/thirdparty/jbossws-jboss42-resources.zip
| -rw-rw-r-- 1 tdiesler tdiesler 4767 Nov 20 18:32 Metro-Integration-AS-4.2.3/workspace/stack-metro/thirdparty/jbossws-jboss42-resources.zip
| -rw-rw-r-- 1 tdiesler tdiesler 4767 Nov 20 18:32 Native-Core-AS-4.2.1/workspace/stack-native/thirdparty/jbossws-jboss42-resources.zip
| -rw-rw-r-- 1 tdiesler tdiesler 4767 Nov 20 18:32 Native-Core-AS-4.2.2/workspace/stack-native/thirdparty/jbossws-jboss42-resources.zip
| -rw-rw-r-- 1 tdiesler tdiesler 4767 Nov 20 18:32 Native-Core-AS-4.2.3/workspace/stack-native/thirdparty/jbossws-jboss42-resources.zip
| -rw-rw-r-- 1 tdiesler tdiesler 4767 Nov 20 18:32 Native-Distro-AS-4.2.1/workspace/stack-native/thirdparty/jbossws-jboss42-resources.zip
| -rw-rw-r-- 1 tdiesler tdiesler 4767 Nov 20 18:32 Native-Distro-AS-4.2.2/workspace/stack-native/thirdparty/jbossws-jboss42-resources.zip
| -rw-rw-r-- 1 tdiesler tdiesler 4767 Nov 20 18:32 Native-Distro-AS-4.2.3/workspace/stack-native/thirdparty/jbossws-jboss42-resources.zip
| -rw-rw-r-- 1 tdiesler tdiesler 4767 Nov 20 18:32 Native-Integration-AS-4.2.1/workspace/stack-native/thirdparty/jbossws-jboss42-resources.zip
| -rw-rw-r-- 1 tdiesler tdiesler 4767 Nov 20 18:32 Native-Integration-AS-4.2.2/workspace/stack-native/thirdparty/jbossws-jboss42-resources.zip
| -rw-rw-r-- 1 tdiesler tdiesler 4767 Nov 20 18:32 Native-Integration-AS-4.2.3/workspace/stack-native/thirdparty/jbossws-jboss42-resources.zip
|
As you can see it uses a different version of jbossws-jboss42-resources.zip. Namely the one available in jbossws-jboss42/4.2.3.CR1
I reverted to jbossws-jboss42/4.2.1.GA for various reasons that are being discussed elsewhere.
The issue at hand is that
| <get src="${jboss.repository}/jboss/jbossws-jboss42/${jbossws-jboss42}/lib/jbossws-jboss42-resources.zip" dest="${thirdparty.dir}/jbossws-jboss42-resources.zip" usetimestamp="true" verbose="true"/>
|
uses the timestamp on the destination file and if newer does not replace the file.
We could of course usetimestamp="fasle", which would result in every thirdparty artifact being downloaded every time. Hence this would make the hudson runs realy slow.
I am trying a different approach, that would delete the thirdparty.dir whenever the version.properties changes
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138059#4138059
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138059
16 years, 9 months
Re: Web Service Stack for EAP 5
by Mark Little
On 18 Mar 2008, at 17:39, Burr Sutter wrote:
>>>
>>
>> We do have WS-AT and WS-BA support, just not using JBossWS.
> So when we say that WS-Transactions are there but not using JBossWS,
> what does that specifically mean from an end-user perspective? Can
> I run both in the same container at the same time, mix & match
> endpoints? Can I annotate my POJO with @WebService and then change
> some configuration files to "engage" WS-Transactions capabilities?
It means that WS-C/WS-AT and WS-BA are present, tested and using their
own SOAP stack for the protocol aspects. If JBossWS is used for the
application, then the only thing that needs to be added to the SOAP
message is the context. And there are handlers for that too.
>>>
>>
>> Yes, that's correct. But show me the 10 people who are waiting to
>> help us add all of these capabilities into JBossWS within the next
>> few weeks, and maybe we can revisit.
> I'm certainly not trying to suggest that these capabilities would
> come without some resource investment. With that said, it is a
> belief within the customer/prospect base that the integration of
> Metro or CXF would mean we get some/all of these "for free" by
> simply including their stacks in our platform.
We'd definitely get there quicker. But not "for free" ;-)
> Now, I'm sure there is still a ton of integration work, QA work,
> testsuite integration, new test case creation, build system retrofit
> and this assumption is based on theory that CXF and Metro have high
> quality implementations of those standards that don't require us to
> fix.
>>
Mark.
----
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).
16 years, 9 months
Re: Web Service Stack for EAP 5
by Mark Little
On 18 Mar 2008, at 19:04, Burr Sutter wrote:
>>
>>
>> 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
We need to make sure that it is compliant and interoperable before we
go marketing it. That's what Web Services is all about these days.
>
> 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.
That's not WS-RM or WS-RX. WS-Notification, WS-Eventing or WS-
EventManagement (the one to come from the merge) is what you need.
>>
>> 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. It is the public's perception of the work done
> with Metro & 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.
It's not a zero effort approach though. CXF does not do anything with
interoperability at the moment. Metro is based on older specifications
and standards that even Microsoft is moving away from. The intention
is that we will get involved in one or both of these communities to
help drive them in the areas that they are deficient. As a result
we'll pick up more than we could do by ourselves.
>
>>
>>> - 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. :-)
Is this based on the W3C specification for SOAP/JMS :-)?
>>
>> We attend the .NET interop workshops, just like Metro does. There
>> we test the functionality we have available
>>
>> Heiko, is taking care of
>> http://www.jboss.org/index.html?module=bb&op=viewtopic&t=131839
> Sun likes to talk about their relationship with Microsoft, engineers
> working together between the 2 organizations, testsuites that prove
> interoperability and as .NET updates occur, making sure
> interoperability is still achieved. It is tough in a sales
> situation to suggest that we can do what Metro/WSIT have done as
> relates to interop with .NET on the various WS-* stuff. Note, I've
> not reviewed Metro's docs on this matter, nor seen any example code
> that shows me the C#/VB.NET
It does work. But like I said above: they use the older versions of
the specifications and standards (sometimes as old as 4 or 5 years).
>>>
>>
>> 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?
Both IBM and MSFT will support WSDL 2.0. They don't have a choice. But
its take-up elsewhere will continue to be very patchy. WSDL 1.1 and
WSDL 2.0 are getting a lot of negative press, for very good reasons too.
>
>>
>>>
>>> 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?
>>
This was 10 people if you wanted it all done this year ;-) Thomas and
I are discussing this now as well.
Mark.
----
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).
16 years, 9 months
Re: Web Service Stack for EAP 5
by Thomas Diesler
Burr Sutter wrote:
> Some questions/thoughts inline.
>
> Mark Little wrote:
>>
>> On 17 Mar 2008, at 18:52, 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.
>>
>> The SOAP abstraction layer will be present (already is present) in EAP
>> 5. We will support JBossWS-native in the first release and the team
>> will work on full qualification for other stacks as we move forward.
>> There are discussions being had at the engineering level around this.
>>
>>>
>>> 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
>>> - 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
>>
>> We do have WS-AT and WS-BA support, just not using JBossWS.
> So when we say that WS-Transactions are there but not using JBossWS,
> what does that specifically mean from an end-user perspective?
It specifically means that it is not there.
Can I
> run both in the same container at the same time, mix & match endpoints?
> Can I annotate my POJO with @WebService and then change some
> configuration files to "engage" WS-Transactions capabilities?
>>
You can as soon as this is documented in our user guide
http://jbws.dyndns.org/mediawiki/index.php?title=User_Guide#WS-Transaction
and we have automated tests for that. Until then its plain theory - some
people might say a marketing lie ;-)
>>>
>>> - No Coordination
>>
>> Same as above.
>>
>>>
>>> - No Trust
>>> - No SecureConversation
>>> - No REST (not necessarily tied to JBossWS but falls in the same
>>> category)
>>> - No non-HTTP transports
>>> - No non-JAXB serialization (e.g. JSON, JiBX)
>>> - No proof of .NET interop (a customer perceived value of the Metro
>>> stack).
>>> - 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
>>> - 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
>>>
>>> How about WSDL 2.0? I'm drawing a blank on where that one stands but
>>> I think it is a No as well.
>>>
>>> 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).
>>>
>>
>> Yes, that's correct. But show me the 10 people who are waiting to help
>> us add all of these capabilities into JBossWS within the next few
>> weeks, and maybe we can revisit.
> I'm certainly not trying to suggest that these capabilities would come
> without some resource investment. With that said, it is a belief within
> the customer/prospect base that the integration of Metro or CXF would
> mean we get some/all of these "for free" by simply including their
> stacks in our platform. Now, I'm sure there is still a ton of
> integration work, QA work, testsuite integration, new test case
> creation, build system retrofit and this assumption is based on theory
> that CXF and Metro have high quality implementations of those standards
> that don't require us to fix.
http://jbws.dyndns.org/mediawiki/index.php?title=JBossWSSupportedStackCom...
[2] mean theoretically available, but we are working on it to make it
available
X means you have the choice in stack.
For example when we unlock Metros WS-RM I know already that the RM
receiver is bound to the endpoint. i.e. when the endpoint goes down the
client cannot send RM messages any more. Which IMHO defeats the
intension of RM. A customer that truly needs RM might want to stick with
Native until this is fixed in Metro.
>>
>> Mark.
>>
>>
>>>
>>>
>>> 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).
>>>>
>>>
>>
>> ----
>> 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).
>>
>
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
Web Service Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
16 years, 9 months
Re: Web Service Stack for EAP 5
by Thomas Diesler
Burr Sutter wrote:
> 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.
WS-RM is about reliable delivery of one message in the context of a
conversation. What you are looking for is indeed WS-Eventing and
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.
yes
It is the public's perception of the work done with Metro &
> 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. :-)
you can also search the roadmap/changelog in jira. We usually make sure
that it is in jira so it makes it into the release notes.
>>> - 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?
I am currently discussing this with Mark
>>
>>>
>>>
>>>
>>> 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).
>>>>
>>>
>>
>
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
Web Service Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
16 years, 9 months