[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: FW: OASIS SDD Action Item: "2.1.2, 2.1.2.1, 2.1.2.2, 2.1.3.1 - Clarify with Debra."
|
Including list. Regards, Debra From: Danielson, Debra J Hi
James, See
below. Regards, Debra -----Original
Message----- Ok,
here's the issue I had last week with these requirements: 2.1.2.1
The SDD specification must support the ability for the author to define
information about viable topologies and define relationships between nodes
in the topology and components targeted to those nodes 2.1.2.1.1
The SDD specification must support the ability for the author to define
prioritization of alternative topologies. -->
I don't understand the need for "alternative topologies".
Wouldn't the
SDD author specify *the* required topology for the solution? Perhaps
within individual elements of *the* required topology, the author can
provide leeway (for example, one node must be an SQL database, but any
SQL db from any vendor would do). Why the need for a complete alternative
topology? [djd]
because I think that there may be multiple alternatives either to maximize some
specific performance or resource metric (high concurrent users, low concurrent
users; network constraints), or accommodate the requirements of a specific
feature set selection. So a component may be able to be deployed
co-resident with another component, or it may be distributed, or it may be
clustered. As you then move up in the integration food chain by
aggregating the component within a larger solution, some of the alternative
topologies may be constrained away, but when defining the component, you need
to provide the multiple options. 2.1.2.2
The SDD specification must provide an open and flexible definition of target
environments -->
This is very vague. I was hoping for more detail but not sure where you
were going with this requirement. [djd]
This was intended to allow for target environments to be more than just
operating systems, but to encompass hardware platforms, application servers,
and other things that we might not be thinking about today. So when we
talk about deploying into a target environment, we need the criteria that
defines the domain of target environments to be extensible (open) and
encompassing (flexible). 2.1.3.1
The SDD specification must not require knowledge of each resource type by
the provisioning application or installation program in order to process the
descriptor. -->
I do not quite get this one. I originally thought it means "install
applications should not have to know about all types used in
SDD in order to parse SDD". For example, if the SDD refers to a PNG
image used as an icon, an install program that cannot display PNG
images can easily skip over the PNG data and still parse the rest of
the SDD. But then I read the associated use case (#72): [djd]
yes, so this requirement was the “opaque artifacts” requirement
from below. The platform/resource-neutral isn’t covered in this
requirement. The platform/resource-neutral means that we don’t
package SDD as MSI, RPM, etc. (We may use these things as opaque
artifacts, but don’t package that way.) "Traditionally,
product installation means installing software into the operating
system environment. Increasingly today, vendors are creating products
that include other software, such as J2EE applications, and are recognizing
the need to treat other content such as database tables and web content
as a formal part of the product that requires lifecycle management. Requirement:
Pluggable mechanism for specifying target environments and artifacts
to be installed. Opaque artifacts. Descriptor is platform/resource-neutral.
"
I get the 'opaque artifacts' part but what does it mean for a descriptor
to be 'platform/resource-neutral' ? -jhf- |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]