[jason.greene]

"omatzura" wrote:

To Jason: since soapui will focus on the top-down part, what top-down functionality are you preparing for wstools 1.0? (you can just point me at some jira issue or cvs document which I can read myself).

The goal of the first release is to replace the core functionality offered by wscompile but only supporting J2EE style web services (so no compile time stubs). So top-down will be limited to taking a wsdl file and generating SEI + jaxrpc-mapping.xml + JAX-RPC value objects that map to complex types.

Currently there are a massive amount of tools jira issues, so they may or may not help you. As soon as I finish some core components I will clean those up.

-Jason

[omatzura]

Hi Marshall!

I think we should at least have the "inspection/invocation" part of soapui as an eclipse-plugin including top-down wstools-integration.. (generate client/server skeletons from WSDL) ready by then, of course depending on the readiness of these wstools themselves.. If there is time, UDDI integration and the functional/load-testing part of soapui would be next on our list..

does that sound ok for you?

/Ole

[mculpepper]

Sounds great..

Just out of curiosity ... does your plan for UDDI integration conflict / integrate at all with the UDDI browser stuff in WTP?

[omatzura]

hmm.. we'll have to check on the possibility to integrate with the WTP in this regard, I'll let you know when we have more on that.. ok?

/Ole

[mculpepper]

Okies =). Just be aware that we plan on integrating 100% with webtools so hopefully we can minimize conflicting functionality (or even better yet maybe you can utilize some of their functionality to help you along your way?)

[markusoj]

I watched this thread for a while and I wondered all the time how the JBoss IDE will relate to the WS components of WTP. I just started to write a post, but then Marshall came up just before me? I agree with him. A solution separate from WTP would seem a bit like doing the same thing twice. WTP already has some WS features like a WSDL editor, Wizards for top-down and bottom-up generation, and simple tools for monitoring and testing. JBoss IDE could try to make use of these existing features; it would be nice to have existing code that gets developed further by others - JBoss IDE already uses features of WTP anyway. On the other hand, WTP is currently tied to Axis and does not JBoss specific features. There are several possibilities here - one approach could be to help the WTP guys to get WS provider (Axis) independent and develop a ?BossWS provider? for the WTP WS components.

[omatzura]

Hi!

yes.. a more tight integration with the WTP instead of (for example) soapui is of course another option for jbosside.. I guess Marshall and the rest of the jbossws team have to weigh pros/cons of either approach against each other.. maybe even multiple integrations is an option over time..

eviwares vision with soapui is to provide a standalone soa(p) development tool that is not "restricted" to any existing IDE/platform, although we are no stranger to providing complementary plugins to maximize usability for a certain target (as discussed in this thread).. If we integrate the jboss wstools into soapui, this integration will be available to non-eclipse users also (which are quite alot), which is a good thing for jboss as well.

regards!

/Ole

[mculpepper]

Ole --

Wouldn't it be beneficial to reuse the WTP Webservices groundwork to minimize the effort needed by your team? I'll admit that I've never seen the internal so I'm not sure how interchangable WS runtimes are, but using WTP WS tools could save you time and be a win-win for both of us.

[omatzura]

absolutely!

We'll have a look and see how the WTP could be used for our purposes.. what is interesting is too see how we could plug into existing WTP functionality that is currently not in soapui, for example UDDI browsing and WSDL editing.. as far as the "core" webservice inspection/invocation/testing groundwork is concerned, most of the existing soapui code is not bound directly to swing and mainly needs to be repacked inside the Eclipse/SWT framework..

anyway, we'll dig into the WTP and let you know how we plan on doing things as soon as possible!

best regards,

Ole