Difference between revisions of "Single Port-Type"

From GCube System
Jump to: navigation, search
(Profiling for the infrastructure)
(Profiling for the infrastructure)
Line 11: Line 11:
  
 
== Profiling for the infrastructure ==
 
== Profiling for the infrastructure ==
Create a new XML file and place it in the ''SERVICE/etc'' folder. This file profiles the service in such a way that the instance of a service can be discovered by others and eventually dynamically deployed in a gCube infrastructure.  
+
Create a new XML file named ''Profile.xml'' and place it in the ''SERVICE/etc'' folder. This file profiles the service in such a way that the instance of a service can be discovered by others and eventually dynamically deployed in a gCube infrastructure.  
  
 
<pre>
 
<pre>
Line 60: Line 60:
 
</Resource>
 
</Resource>
 
</pre>
 
</pre>
 +
 +
The file identifies our service by assigning it a ServiceClass and a ServiceName. Then it indicates that it is composed by two packages, the service itself and its stubs and that the first one has a GHN-scoped dependency against the second one.
  
 
== Delving into the implementation ==
 
== Delving into the implementation ==

Revision as of 23:19, 21 March 2008

From configuration to testing with a single Port-Type

Even if not compulsory, we strongly suggest to adopt the Eclipse 3.3 as development platform. In such an IDE, open a new workspace with a Java 1.5 compiler and create a new Java project by specifying a source folder (named from now on, SERVICE folder). Then, fill a user-library with all JARs in gCore lib and name it CONTAINERLIB.


Structuring the service code

Prepare the source folder structure as follows:

  1. create a etc folder where to place your configuration files
  2. create a org/acme/sample folder where to place your source code
  3. create a schema folder where to place the remote interface files
  4. copy the share/gcube_tools/build.xml file into your SERVICE folder

Profiling for the infrastructure

Create a new XML file named Profile.xml and place it in the SERVICE/etc folder. This file profiles the service in such a way that the instance of a service can be discovered by others and eventually dynamically deployed in a gCube infrastructure.

<Resource xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<ID></ID>
	<Type>Service</Type>
	<Profile>
		<Description>A very simple gCube Service</Description>
		<Class>Samples</Class>
		<Name>SampleService</Name>
		<Packages>
			<Main>
				<Description>Describes port-types</Description>
				<Name>Main</Name>
				<Dependencies>
					<Dependency>
						<Service>
							<Class>Samples</Class>
							<Name>SampleService</Name>
						</Service>
						<Package>Stubs</Package>
						<Version>1.0</Version>
						<Scope level="GHN"/>
						<Optional>false</Optional>
					</Dependency>
				</Dependencies>
				<GARArchive>org.acme.sample.gar</GARArchive>
				<PortType>
					<Name>acme/sample/stateless</Name>
					<WSDL/>
				</PortType>
				<PortType>
					<Name>acme/sample/stateful</Name>
					<WSDL/>
				</PortType>
				<PortType>
					<Name>acme/sample/factory</Name>
					<WSDL/>
				</PortType>
			</Main>
			<Software>
				<Description>Describes port-type stubs</Description>
				<Name>Stubs</Name>
				<Files><File>org.acme.sample.stubs.jar</File></Files>
			</Software>
		</Packages>
	</Profile>
</Resource>

The file identifies our service by assigning it a ServiceClass and a ServiceName. Then it indicates that it is composed by two packages, the service itself and its stubs and that the first one has a GHN-scoped dependency against the second one.

Delving into the implementation

Building & Deploying

gCore Logging & Restart

A Test Client

Refining the implementation