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

[Chris Brealey <cbrealey@xxxxxxxxxx>]

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

fernando@xxxxxxxxxxxxx
Sent by: wtp-dev-admin@xxxxxxxxxxx

11/23/2004 07:18 AM

Please respond to
wtp-dev

To	wtp-dev@xxxxxxxxxxx
cc
Subject	Re: [wtp-dev] a new WTP Architecture Overview document is available

Hi,


> - 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
wtp-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/wtp-dev