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

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-----
From: wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx]On Behalf Of Rupam Kuehner
Sent: Friday, May 13, 2005 8:21 AM
To: wtp-dev@xxxxxxxxxxx
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

Back to the top