Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [wtp-dev] Features and Web services - questions and request forfeedback



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

  1. 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?
  1. 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
  • 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
  • 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.

Rupam Kuehner
IBM Rational Software
phone: 905.413.3859

Back to the top