• Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

Comments (2)

1 SoumenC commented Permalink

Thanks a lot for sharing this. The multi-image pattern sounds really good to me. However, I am trying to understand what are its limitation. For example, <div>&nbsp;</div> 1) Does it support customization in terms of the connectivity between the nodes ? <br /> 2) Does it handle security among the created nodes ? <br /> 3) Does it allow the custom input parameters for each of the nodes ? <br /> 4) When the user tries to deploy one image pattern, would it ask for the input parameters like virtual machine configuration, scalability or performance parameters ?

2 DKA commented Permalink

All great questions: <div>&nbsp;</div> 1) Yes, we do enable connection between nodes by allowing you to pass in variables to scripts (i.e. a script that setup a data source in WAS), which are resolved automatically by WebSphere CloudBurst during deployment. For example, in the above 'Create DB2 Data Source' script, I may pass in ${DB2Part.hostname} (just an example) as the value for the host name for my data source. During deployment, WebSphere CloudBurst automatically resolves that variable to the actual host name assigned to the DB2 instance. <div>&nbsp;</div> 2) I'm not sure what you mean by security. You can certainly provide any kind of security configuration you would in your typical application environment deployments. Patterns were designed with the specific intention to allow you to make any sort of customizations you require in your application environments. <div>&nbsp;</div> 3) For each of the distinct part types, there is configuration data and other deployment parameters. <div>&nbsp;</div> 4) For any pattern (single or multi-image), there is configuration data that you can supply during deployment. This includes information about the middleware (i.e. WebSphere Application Server cell and node names), as well as the VM itself (i.e. virtual memory and virtual CPU allocation).

Add a Comment Add a Comment