Closed kneussel closed 10 years ago
I don't think we should create separate Software Node Types for
a) things that are part of installed operating system, e.g. crond
b) program run-time environments, e.g. JRE JDK
a) in the past we used "daemon" for that. is that ok?
b) generally we could use only "Java" for that?
Suggestions for Implemenation:
ApplicationServer/JDK => RTE/JDK
Administration/AutoPilotKiTools => Automation/AutoPilot (the actual component will be part of attributes)
DataProcessing/AutoPilotRestIndexUpdate => Automation/AutoPilot (the actual component will be part of attributes)
ApplicationServer/Liferay => ..ok..
IAM/OpenAM => alrady added...
API/AutoPilotRestAPI => Automation/AutoPilot (the actual component will be part of attributes)
DataHandling/AutoPilotProxy => Automation/AutoPilot (the actual component will be part of attributes)
DataProcessing/Hadoop => ..ok..
DataProcessing/AutoPilotReporting => ???
ApplicationServer/JRE => RTE/JRE
ScheduleServer/Crond => SystemService
Automation/aAE => Automation/AutoPilot (the actual component will be part of attributes)
Administration/AutoPilotCLI => Automation/AutoPilot (the actual component will be part of attributes)
API/AutoPilotSOAP => Automation/AutoPilot (the actual component will be part of attributes)
DataHandling/Zookeeper => ... still TBD ..
DataProcessing/AutoPilotLicenseConnector => Automation/AutoPilot (the actual component will be part of attributes)
For use in AutoPilot CE, we need new classes/subclasses for a standard model.
SoftwareClass/SoftwareSubClass
ApplicationServer/JDK
Administration/AutoPilotKiTools
DataProcessing/AutoPilotRestIndexUpdate
ApplicationServer/Liferay
IAM/OpenAM
API/AutoPilotRestAPI
DataHandling/AutoPilotProxy
DataProcessing/Hadoop
DataProcessing/AutoPilotReporting
ApplicationServer/JRE
ScheduleServer/Crond
Automation/aAE
Administration/AutoPilotCLI
API/AutoPilotSOAP
DataHandling/Zookeeper
DataProcessing/AutoPilotLicenseConnector