Re: [sdd] FW: OASIS SDD Action Item: "2.1.2, 2.1.2.1, 2.1.2.2, 2.1.3.1 -Clarify with Debra."

[Randy George <randyg@us.ibm.com>]

With respect to James question on alternative
topologies, I think that the SDD needs to support both cases: 

1) a requirement for an SQL db and any
mfg flavor or version will work.
2) a requirement for an SQL db, but
only the following are support XXX version 8.1, YYY version 10.2, or ZZZ
version 11.3.  This is a very common scenario.  In some cases,
this is a technical constraint, e.g. my table definitions do not work on
other SQL impl

Regards,
Randy George

Senior Technical Staff Member
Provisioning Architecture
Tivoli Software, IBM Software Group
Austin, TX  
(512) 838-0752     T/L 678-0752

"Danielson, Debra J" <Debra.Danielson@ca.com>

03/08/2006 05:51 PM

To	<sdd@lists.oasis-open.org>
cc
Subject	[sdd] 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 
Sent: Friday, February 24, 2006 10:35 AM
To: 'James Falkner'
Subject: RE: OASIS SDD Action Item: "2.1.2, 2.1.2.1, 2.1.2.2,
2.1.3.1 - Clarify with Debra."
Hi James,
 
See below.
 
Regards,
Debra
-----Original Message-----
From: James Falkner [mailto:james.falkner@sun.com] 
Sent: Thursday, February 23, 2006 3:24 PM
To: Danielson, Debra J
Subject: OASIS SDD Action Item: "2.1.2, 2.1.2.1, 2.1.2.2, 2.1.3.1
- Clarify with Debra."
 
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-