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

I sent a separate note expressing my concerns about the schedule. In reference to your last paragraph, it may take the J2EE team a couple of weeks after 6/3 to fully react to the new design. Web services is another layer above J2EE with dependencies that must be stable within J2EE for us to make progress. In other words, the equation is closer to "hoped-for June 3 + a week or two (J2EE) + a week of two (Web services)". Even the optimistic interpretation of that bit of fuzzy logic lands us squarely on June 17 shutdown.

The purpose behind this enhancement is unquestionably good, but yes, there are missing elements to the design itself and the schedule, a lack of information on how and when higher order API (operations) in J2EE tools will be altered, and certainly no detail from myself and rest of us Web services troublemakers about how and when we can redesign our component to live with features.

I would be alot more amenable to this work if (here it comes...) M5 were to move out two more weeks. Far easier said than done, of course.

I would also be more open to the change if we could collectively get all the design changes on the table fast, and target 6/3 for all API right up the stack - Not just the design changes and API central to the Feature design itself. The main source of my concern is not that we can't contain the work, it's that we haven't filled in enough variables in the WTP plugin layer cake to know if we can contain it.

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

"Ted Bashor" <tbashor@xxxxxxx>
Sent by: wtp-dev-bounces@xxxxxxxxxxx

05/13/2005 05:38 PM

Please respond to
"General discussion of project-wide or architectural issues."

"General discussion of project-wide or architectural issues." <wtp-dev@xxxxxxxxxxx>
RE: [wtp-dev] flexible project & server api changes - please review

One of the main objectives of this proposal is to formalize api for declaring and discovering the functionality supported by various server types.  That said, the current proposal doc is incomplete in that it defines an extension point for declaring the features a server type supports, but does not define api for exposing this information.  Tim and the server component team can best comment on where this api should go (ServerCore, ServerUtil, IRuntime, IServerType, ?).  (As a side note, in the doc we suggested merging IRuntimeType and IServerType, but that's not critical to the proposal).
I definitely understand the schedule crunch and the reluctance to transition your extension api this late in the game.  But hopefully defining webservice technologies (which may or may not be appserver-specific) in terms of features which can express dependencies on other features such as J2EE spec levels, and storing these settings in project/component metadata, feels like the right thing to do.  If it was merely a matter of new extension points that support the existing server to project model, we would not be lobbying to do this in 1.0.  But since the feature model effectively inverts the current model, we think it's important to push this through now.
We're hoping that the API is fully in place by 6/3, and most componentType users can be transitioned in a matter of a week or two.  But that may be over optimistic in the case of webservices...
-----Original Message-----
wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx]On Behalf Of Rupam Kuehner
Friday, May 13, 2005 8:21 AM
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
wtp-dev mailing list

Back to the top