Ted et al,
I've been mulling over the design and
the schedule and have a few concerns.
First off though, I think the requirements
and the design are really slick and will accomplish an excellent goal.
I also think these changes will help improve the unification between some
of the "Web service runtime" concepts we have in the Web services
component with the notion of "features", and really help simplify
how extenders plug-in support for new Web service platforms.
What I'm really concerned about is that
the timing and scope of this work might just kill the Web services component
in M5. At the very least, this effort would require throwing a number of
things out of the Web services M5 plan.
As a bit of context, flexible project
support underwent a great deal of necessary live design and evolution thru
the M4 development phase and took most of the milestone to settle down.
The timing between getting the Web services component integrated/running
with the flexible project feature and delivering M4 was measured in hours.
I'm not keen to repeat the experience - particularly after the API freeze
milestone has passed and we're just one milestone away from WTP 1.0 Final.
Your proposed schedule has some good
detail in it, however, there are some dates of concern and a few unknowns
we must deal with before committing. In no particular order:
1. We need to remove the question marks
from your proposed schedule. By that, I definitely do not mean to put the
items on your teams' shoulders. I just mean we need to determine who in
the community will work on those items. I'm referring mainly to the Web
service and Web service client features, although some other "?"
items like the "assembly publish tasks" will also need to be
working before any Web service scenarios will be successful.
2. The proposed schedule names 5/18
(which is nice and soon) as the target for the new IFeatureDescriptor and
IFeature (assumed) API, and for adding at least some of the associated
methods to IVirtualComponent. There are other interfaces in the proposal
to be updated, such as IServerType, IRuntime, IModule and IModuleType (to
be deleted). I'm not sure if all these changes are planned for 5/18.
3. As Rupam points out by the example
of WebComponentCreationOperation below, there are other chunks of J2EE
and possibly Server tools API used by the Web service scenarios that are
one degree removed from, but will still be heavily affected by, this new
IFeature API. Like  above, we need to determine target dates for both
stable API and implementation changes to these puppies.
4. M5 shutdown begins June 17. Some
of the items targetted for June 10 in the proposed schedule must be stable
before the final round of changes to the Web service scenarios can commence.
It is not sufficient simply for the IFeature enhancement within Server
and J2EE tools to wrap up this closely to shutdown. There must be sufficient
buffer in the schedule for the Web services component near the top of the
dependency stack to finish reacting and have its golden scenarios up and
running by June 17. As Rupam points out in her last paragraph, I don't
believe the buffer is there.
5. I can't emphasize enough how tightly
integrated the Web services scenarios are with J2EE and Server tools. The
shape of the extension points, their interfaces and Apache Axis implementations,
and all the implementation bits that automate project creation and reuse,
component/module creation and reuse, EAR assembly, module/server association,
server creation and reused, etc. will get thoroughly smacked by this change.
The Web service wizard GUI may also require some rework. We must stretch
the scope of this design and schedule into J2EE and Server tools API that
are called by Web services, and into the Web services component itself.
My current 2-cent opinion is that we
should not attempt this in the the current WTP 1.0 schedule.
Hopefully this doesn't come across as
a big "whine and cheese" fest on my part. If anything, the message
I'm trying to convey is that I'm a big chicken when it comes to pushing
a change of this magnitude into M5. We can pull it off if all the planets
align (and they usually don't) and we crisp a number of items from the
Web services M5 plan.
Thanks for reading.
Cheers - CB.
Rational Java Web Services, IBM Canada Ltd.
D3-275, D3/ENX/8200/MKM, 8200 Warden Avenue, Markham, Ontario, Canada,
cbrealey@xxxxxxxxxx, 905.413.6038, tieline:969.6038, fax:905.413.4920
Rupam Kuehner/Toronto/IBM@IBMCA Sent by: wtp-dev-bounces@xxxxxxxxxxx
05/13/2005 11:20 AM
Please respond to
"General discussion of project-wide or architectural issues."
RE: [wtp-dev] flexible project
& server api changes - please review
I'll echo what others have said in that this looks like a good design with
worrisome timing, particularly for the Web services component, since much
of it sits on top of the J2EE and Server components. Here is a brief summary
of the impact and related concerns:
Web service tools make extensive use of the API related to IRuntime and
IRuntimeType for defaulting and validation of component and server/server
type selection in the Web service/client wizards/pop-up actions. We're
currently using these API to do things like:
1. given a component, get a list of valid server types that component
could be associated with
2. given a server/server type, determine whether is supports a particular
3. given a server/server type, determine if it supports EAR association.
With the removal of the runtime target API, as we know it today, we would
require new utilities to help us answer us these (and related) questions
The webserviceRuntime extension point, which is at the heart of the wizard
framework, would have to be revamped in order to identify module types
and version numbers using features. Even if we left the extension XML the
same, the code that reads/interprets it would still have to made feature-aware
in order to make use of feature based utilities and APIs.
Also, Web service tools would be affected by any modifications to the mechanisms
used to programmatically create flexible projects and components within
them. I guess it's not clear to me from the proposed design how or if existing
operations like WebComponentCreationOperation, etc. will be affected.
The main concern lies with timing. The J2EE and Server component work for
supporting features needs to be mostly complete and relatively stable before
Web services work can begin, which, depending on the final dates, could
leave us with very little time, adding to the risk of quality and stability
problems in this component in M5.
IBM Rational Software
wtp-dev mailing list