Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [wtp-dev] a new WTP Architecture Overview document is available

Naci, Fernando,
there are a large number of standards and specifications out there for Web services. Miraculously, they tend to fall neatly into one of two camps:
1. Standards for Web Services. Examples: WSDL, SOAP, UDDI, WS-I, WS-Inspection, WS-Security, WS-... etc.
2. Standards for Web Services for a specific platform. For instance, in Java: JSR-101, JSR-109, JSR-181, JSR-224, ... etc.

The tools should be divided the same way, with plugins for (1) living in the WST project (and not needing JDT), and plugins for (2) living in the JST project.

We're smack in the middle of updating and committing a bunch of Web service plugins into CVS, so this whole JST vs. WST question has been bouncing around in my head for a while (and causing no small amount of damage). I agree the tools that deal with Web services for Java are critical (to Java programmers!) and must live in the JST project. However, there is also a massive layer (perhaps even the bulk) of Web service tooling that will live in the WST*. These tools in the WST project neither depend on the JDT nor overlook the need for Java bindings. The frameworks and extension points designed into the tools were originally fashioned to allow the plugging in of tools for specific platforms including, but not limited to, Java.

The definition of "full WS support" is in the eye of the beholder. The Web services tools in the WST project will form a very rich foundation for anyone who wishes to extend the system for any given platform (eg. Perl). On the flip side, folks who wish to use or extend the Java Web services tools will naturally turn to the JST project with its support for Web services in J2EE.

* Initially several "non-Java" Web service plugins will be committed into the JST project because the dependencies are not as neat and tidy as they should be. Following completion of the initial commit, one of the first bits of work we would like to embark on is to clean up the dependencies and move anything not specific to Java Web services down to the WST project.

PS: open source = open discussions :)

Cheers - CB.

Chris Brealey
Rational Studio Java Web Services, IBM Canada Ltd.
D3-275, D3/ENX/8200/MKM, 8200 Warden Avenue, Markham, Ontario, Canada, L6G 1C7
cbrealey@xxxxxxxxxx, 905.413.6038, tieline:969.6038, fax:905.413.4920

Sent by: wtp-dev-admin@xxxxxxxxxxx

11/23/2004 07:18 AM

Please respond to

Re: [wtp-dev] a new WTP Architecture Overview document is available


> - Conceptually it seems that there should not be any JDT dependencies in
> WST, due to our obviosly categoric seperation of Web and J2EE standard
> tools.
> However, the distinction is not clear for Web Services; it is hard to
> imagine that proper tooling and frameworks for web services can overlook
> java bindings for web services and java types on top of validation, and
> delegating Java part of Web Services completely to the JST project would be
> a more critical design flaw than a dependency on JDT (i.e. if you need full
> WS support your depencey will be JST (an indirectly JDT).

I could not understand this reasoning, please enlighten me. What is the strong
dependency beteen web services and java? And, if there is such stroing ties,
why putting everything under JST would be a critical design flaw?

I though web services where about the provider and the consumer being any
language you wish to use. I can, for instance, write consumer for web services
using PHP and providers using Perl. I can get great plug-ins for PHP and Perl
development under Eclipse. But why should I need to install JDT in order to
develop my webservices using Eclipse WST if I won't use Java at all?

On the other way, the Web Service support for Java is officially part of the
J2EE and it requires other J2EE components, like web containers. Even the
non-web part of it (like JAXB, XML bindings to Java classes) are defined as
part of the J2EE plataform. So, if I had to use Java to implement web services,
JST would be the natural fit for those Eclipse components.

Maybe the tools you use to develop Web Services were written using Java. Maybe
some of them are focused on Java developers. The first case you can solve by
factoring out the dependencies from the JDT so I don't need to include all of
it to just generate and validate WSDL files, for example. The second case can
be solved by creating a component that I don't need to install on order to use
other web services-related functionality from WST on my non-Java development.

PS: I hope no one gets pissed of me being so vocal on list about my opinions
but not having provided a single patch so far... PHP and Perl developers were
allways glad to receive the feedback of someone who would be using the tools
early on their design cycles, but maybe you prefer to have a more closed
discussion beteen developers.

[]s, Fernando Lozano

wtp-dev mailing list

Back to the top