Using a domain in a single JVM is very easy. You simply create an instance of
org.apache.tuscany.sca.host.embedded.SCADomain.
Using one of the provided newInstance() methods. Note the package name. You will see a different package name when we look at the multiple JVM case. For now this indicates that the SCA Domain is going to be completely embedded in the Java application that you write.
This is what the different newInstance() operations mean.
public static SCADomain newInstance()
Starts a standalone domain with a default domain URI and will treat the classpath as the contribution to this domain. All .composite files on the classpath will will read any deployable components created accordingly.
Deployable components are defined by either
- placing the .composite file in the META-INF/sca-deployables/directory
- By specifying the composite as deployable in the META-INF/sca-contribution.xml file
public static SCADomain newInstance(String composite)
Starts a standalone domain with a default domain URI and will try and find the named composite file in the classpath and use it's location as the contribution location. It will deploy the named composite.
public static SCADomain newInstance(String domainURI, String contributionLocation, String... composites)
Will start a standalone domain with the specified domain URI and will load the contribution at the contributionLocation. Any named composites will be deployed. As there are both contributionLocation and composite name parameters there are some rules about what happens when you specifier one the other, both or neither as follows.
contributionLocation - an absolute path to a contribution in URL form, e.g
file://C:/mydirA
jar:file://C:/myjar.jar
composite(s) - the name of a composite file(s) e.g.
mycomposite.composite
somedir/mycomposite.composite
So the various combinations give rise to
contributionLocation set / composite null
loads all contributions under the contribution location identified
contributionLocation null / composite set
finds the location of your compsite on the classpath and uses that as the contribution location. It loads the named composite from there
contributionLocation / composite
loads the named composite from the specified contribution path
contributionLocation null / composite null
This option is also used if the above rules don't identify a contribution URL for whatever reason.
No contribution has been specified so look for the following in order and use the location of the first one found as the contribution location
META-INF/sca-contribution.xml
META-INF/sca-contribution-generated.xml
META-INF/sca-deployables directory
For example, in our calculator sample we could do
scaDomain = SCADomain.newInstance("Calculator.composite");
Once created the SCA Domain will have loaded a contribution based on the rules set out above.
You can now use services in the domain either directly from your Java application or remotely over the service instance that the SCA application exposes.
To use services directly you can use the following SCA Domain interfaces to create a service proxy
public abstract <B> B getService(Class<B> businessInterface, String serviceName);
Returns a type safe reference to the named service
public abstract <B> ServiceReference<B> getServiceReference(Class<B> businessInterface, String referenceName);
returns an SCA service reference to the named service. You can use the SCA service reference to manipulate various aspects of the referece.
public abstract <B, R extends CallableReference<B>> R cast(B target) throws IllegalArgumentException;
Casts a service (callable) reference to a typesafe reference .
For example, in our calculator sample we could do
calculatorService = scaDomain.getService(CalculatorService.class, "CalculatorServiceComponent");
Once you have a service proxy you can call methods on it like any other Java object.
Double result = calculatorService.add(3, 2)
When you a finished with the domain you need to close it down.
scaDomain.close();