This project provides an Introduce extension that allows an analytical service developer to configure a service with data types from a caCORE-like system.
For example, if you have generated a caCORE-like system, complete with beans and schemas (produced by the caCORE SDK), you can import those schemas into a service and use the beans from your caCORE-like system.
As a result, your analytical service will now be caBIG silver compatible with your caCORE-like system because your service will use the same types and beans.
h2. Motivation
Some caBIG silver level reviews consist of reviewing both a caCORE-like system and an analytical service. During these reviews, caBIG mentors noticed that the APIs for the analytical service and the caCORE-like system differed. For example, a "Date" type specified on an attribute in a model is implemented as a java.util.Date in the API of the caCORE-like system, but as a java.util.Calendar in a default analytical service. The purpose of this project is to provide a technical solution to ensure that the types used in an analytical service match those of a caCORE-like system. In our example, the result is an analytical service that now uses the beans from the caCORE-like system, ensuring that the UML attribute with a "Date" type is now implemented as a java.util.Date in the analytical service, matching the caCORE-like sytem (changed from java.util.Calendar). Ensuring type compatibility allows projects applying for silver level reviews to present APIs for their analytical service and caCORE-like system that match, ensuring a successful silver level review.
It is important to note that although this type compatibility is critical for silver level review, for purposes of Gold compatibility, the only requirement is to use one set of schemas for all system components (as the schemas are specification of the datatypes on the Grid). Thus, either type of analytical service would pass a Gold compatibility review. That is, this project enables an analytical service developer to create a service that uses the same beans as a caCORE-like system. Both an analytical service developed using this project and an analytical service developed using default Introduce type mappings would produce a service that uses the same schemas as the caCORE-like system. From the point of view of the Grid, they are equivalent.
h3. Additional examples of type incompatibility
For example, the UML model would have java.util.Date as the datatype for an attribute of a class and would be represented as xsd:dateTime in XSD. When the XSD is used to author a service it is converted to java.util.Calendar. In another example, a UML model has an association to a Double data type, mapping to a xs:sequence of xsd:double in the schema, which becomes Collection<Double> in a caCORE-like system but double\[\] (double array) at the service level.
This project fixes all such type inconsistencies by re-using the beans and schemas from the project.
h2. Technical Information
This project is a [datatype discovery Introduce extension|introduce13:Design#Data Type Discovery Extensions]. This extension will enable a developer to add the datatypes created by the caCORE SDK into a caGrid service.
A data service created using a caCORE SDK wizard by default uses the beans and schemas from the caCORE SDK application. Thus, all caGrid data services are automatically silver compatible with caCORE-like system. This extension provides silver compatibility for all caGrid services (e.g., analytical services).
Administration
...