Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [wtp-dev] flexible project & server api changes - please review


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 [2] 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.

Chris Brealey
Rational 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



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."

To
wtp-dev@xxxxxxxxxxx
cc
Subject
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 J2EE version

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 using features.

 
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.


--------------------------------------------------
Rupam Kuehner
IBM Rational Software
phone: 905.413.3859
mailto:rsinha@xxxxxxxxxx
_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev


Back to the top