80 likes | 290 Vues
SugarCRM Template Issues. Implementation Experience/Feedback. Service Template Issues. Relationships EndPoint encoding Deployment Artifact encoding Packaging (TOSCA Archive) Lifecycle Operations Action: create JIRA issues and resolve. Relationships. Typed Ends
E N D
SugarCRM Template Issues Implementation Experience/Feedback
Service Template Issues • Relationships • EndPoint encoding • Deployment Artifact encoding • Packaging (TOSCA Archive) • Lifecycle Operations • Action: create JIRA issues and resolve
Relationships • Typed Ends • We tried enhancing the Relationship Type to use typed ends • It required one new type for each hostedOn pair • Action: Propose alternate representation • Sometimes it is desirable to associate an operation with a Relationship (e.g. connector) • Frank covered this last week… • Interfaces/operations cannot be associated with Relationship Types • Action: Look at more general case where operations are really covering many Nodes Types and Connectors and determine where such operations can be attached. Add support for association of operations as necessary
EndPoint Encoding • Currently we are forced to use Nodes to represent EndPoints • End points should not be encoded as nodes: • EndPoints don’t really represent a deployable node but still we want to be able to support a type hierarchy and • Nodes contain EndPoints which are connected by connectors. EndPoints should be treated as top level entities and be supported in relations • Action: Consider general issue of supporting non-deployable entities as well as EndPoints in particular
Deployment Artifact Constraints • Need Node Templates to hold their invariant descriptive key/values • E.g. OS.Type=Linux, Linux.Distro=Redhat … • Each Deployment Artifact must hold sets (1 or more) of matching key/values which select their usage context • Action: Add a place for the descriptive key/values in Nodes
Packaging • An overall deployable TOSCA service is a collection of: • The TOSCA XML file(s) describing the ServiceTemplate, NodeTypes, RelationshipTypes, … • XSD files defining Node Type properties etc. • Plan model files (e.g. BPMN 2.0 files) referenced from the Service Template • Deployment artifacts like archives, files, software installables, … • A self-contained packaging format as shipment vehicle for the above collection seems necessary • Self-contained archive file containing all the model files and artifacts, that can be deployed into a TOSCA environment • Proposal: define a packaging format for TOSCA services and their related artifacts similar to existing packaging formats (e.g. in JEE world)
Sketch of a Packaging Format /Meta-Inf SugarCRM Example /Service-Template /Types /Meta-Inf MANIFEST.MF /Plans /... /Service-Template /Archives SugarCRM-ServiceTemplate.xml /Scripts /Types SugarCRM-Types.xsd • Align with existing packaging formats (JAR, tar, EAR, …) • Define structure, content, and processing semantics /Archives sugarCE-Full-6.1.5.tar.gz mysql-5.0.77_db_sugarcrm.tar.gz Note: larger artifacts (e.g. images) might be referenced instead of being packaged.
Lifecycle operations • Need to define the basic operations • And associate them with Node Types where they apply • Their semantics would vary according to Node Type in domain specific ways • Action: resolve JIRA #11