Rupam,
1. We’ve considered adding “OR”ing
of required features, but there are a number of complications that arise out of
this. Usually there is some other way of structuring features such that “OR”ing
is not required. For instance, if feature A depends on feature B or C, you can
split A into two and have A1 depend on B and A2 depend on C. Alternatively, if
you are trying to express that feature A depends on Bv1 or Bv2, perhaps we can
model it as A depends on Bv1 and higher.
2. I definitely think it’s important
to maintain ui consistency and we can work together to make sure that whatever
feature config ui that is produced for project creation / feature set
modification will be extensible to allow it to be reused in the webservices
wizards. Base features may or may not be bound to server runtimes as part of
their implementation detail. We are still hashing out how that would look, but that’s
purely an implementation detail of how features setup the project classpath.
Nothing external to feature implementation should depend on that. In my mind,
the feature selection ui is interaction between features and server types. Selecting
a particular server type only serves to filter the set of available features.
The server type is not persisted anywhere in the project/component metadata.
So, a user could pick WebLogic and see the feature list filter down to the set
of feature supported by WebLogic, but if the user then only selects J2EE
standard features they can still deploy to Tomcat, etc. Once the user selects
the set of features and hits next, he is prompted to configure the features. It’s
at this point that the user picks the runtime, if that’s required by the
features that were selected. Note that there is still disagreement over this.
This disagreement does not invalidate the overall proposal, so I am waiting for
the go / no go decision before trying to hash this out completely.
- Konstantin
From:
wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx] On Behalf Of Rupam Kuehner
Sent: Monday, May 16, 2005 3:00 PM
To: wtp-dev@xxxxxxxxxxx
Subject: [wtp-dev] Features and
Web services - questions and request forfeedback
I've been mulling over some of the re-design of the Web
services frameworks in light of features and have a few of questions and ideas
I'd appreciate feedback on....
- Can a
feature require an "OR"ing of other features?
For example could we set up a feature like j2ee.webservices 1.1 to require
j2ee.webapp 1.4 or j2ee.ejb 1.4? I can envision the creation of Web
service features tied to Web service specifications. For example, jaxrpc
1.0, jaxrpc 1.1, j2ee.webservices 1.0, j2ee.webservices 1.1, each for
which required other features (like j2ee.webapp 1.3, j2ee.ejb 1.3, etc).
Any suggestions on how Web services related features should be structured?
- We will need to converge
the feature framework with the existing Web service runtime framework, One
way to do this is by modifying the Web service runtime extension XML to
specify the set of features it requires on a component. The fun begins
when we try to design the logic and UI needed to guide the user through
the selection of their project, component, features, server runtime,
server type, and Web service runtime. The look and feel of such a dialog
should be similar to the UI used in the creation of a new component and
the UI used for the modification of features on an existing component,
with the added twist that we'll have to include Web service runtimes and
server types in the picture. The flow of the UI could be
- The user first selects a
Web service runtime (e.g. Axis 1.2). The dialog is updated to show the
features that will get added, a list of valid server runtimes and server
types to choose from
and/or
- The user first selects
features (e.g. j2ee.webapp, j2ee.webservice 1.1). The dialog is updated to
show valid Web service runtimes, server runtimes, and server types to
choose from
and/or
- The user first selects a
server type (e.g. tomcat 5.0). The dialog is updated to show valid Web
service runtimes, server runtimes, and features that will get added
I'll be the first to admit that this seems quite complicated (even if it's
hidden behind an Edit or Advanced button). Feedback on how we can make the
user experience simple yet powerful is very welcome. Referring to an
earlier comment from Chuck, will the
base features on existing components be bound to runtimes? This
would enable us to remove the server runtimes from view, at least for
existing components.
- An inventory is underway
of Web services code's use of J2EE tools and Server tools API that is
likely to be affected by the feature related changes. We're also trying to
identify what new utilities we'll need. We'll be providing feedback
through the week.
Thanks.
--------------------------------------------------
Rupam Kuehner
IBM Rational Software
phone: 905.413.3859
mailto:rsinha@xxxxxxxxxx
|
