[
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...
-Ted
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
