...
3. The ContributionProcessor introspects the contribution to create a list of artifacts of interest for SCA. Each artifact is classified by ContentTypes.
4. The artifacts are parsed by the content type. we provide parsers for SCDL (StAXElementLoader) and we can reuse existing parsers for XSD and WSDL (XmlSchema, wsdl4j, woden). So the WSDL introspector would parse the document using, say, wsdl4j and then store the interesting things that it finds.
5. The interesting definitions are added to the contribution store and that is the end of the contribution operation. We keep the contribution and cache the introspection results.
...
Info | ||
---|---|---|
| ||
The changeSet for the physical runtime is meant to be very precise and the builder's role is to turn that into runnable code. So it's not SCDL stuff but much lower level. The idea is to keep the builder very simple (and hence quite testable) that means there is a bit more work in the conversion from logical to physical, bascially a "portable" builder. The idea of "portable builders" is about separating the node responsible for domain assembly from the nodes running component implementations. In a heterogeneous federation, it could be the assembly node(s) are running C++ but the user wants to add a Java component that will actually run on a Java node. If the introspection results for the Java contribution are portable, it would be possible for the C++ to set up the physical configuration for the Java builder; alternatively, it could delegate that to a service running in a native Java environment. Similarly, if the component was in some portable language (like Ruby or XSLT), then the configuration could be done on a Java node and passed to a C++ runtime node. |
6. The next steps is the build/connect/run.