Difference between revisions of "The Development Cycle"
From GCube System
(→A Tiny Profile) |
|||
| Line 3: | Line 3: | ||
== A Tiny Profile == | == A Tiny Profile == | ||
| − | A good starting point with service development is its [[Configuration Management|configuration]]. And a good starting point when configuring a service is the definition of its profile. The role and structure of gCube service profiles is described in detail [[Configuration Management#Profiles, Properties & Descriptors|elsewhere]]. Here we just | + | A good starting point with service development is its [[Configuration Management|configuration]]. And a good starting point when configuring a service is the definition of its profile. The role and structure of gCube service profiles is described in detail [[Configuration Management#Profiles, Properties & Descriptors|elsewhere]]. Here we just show one of the smallest and yet perfectly well-formed profile a service may have: |
<pre> | <pre> | ||
| Line 36: | Line 36: | ||
</pre> | </pre> | ||
| − | By necessity, this profile reveals things yet to come. For the time being, | + | By necessity, this profile reveals things yet to come. For the time being, be happy with a conceptual summary: |
* ''SampleService'' is a a particular type of ''gCube Resource'', one of type ''Service''. Like all gCube Resources has an ''ID'', which it receives when it is formally registered with the infrastructure. Until then, ''SampleService'' does not have a proper identifier. No worries though, a temporary one will be generated by gCF at runtime. | * ''SampleService'' is a a particular type of ''gCube Resource'', one of type ''Service''. Like all gCube Resources has an ''ID'', which it receives when it is formally registered with the infrastructure. Until then, ''SampleService'' does not have a proper identifier. No worries though, a temporary one will be generated by gCF at runtime. | ||
| − | * The profile of ''SampleService'' specifies its ''Name'' and specifies its membership to a ''Class'' of functionally related gCube services. Classes are not pre-defined and here we settle on ''Samples''. A free-form ''Description'' and a ''Version'' complement the preliminary description of ''SampleService'' | + | * The profile of ''SampleService'' specifies its ''Name'' and specifies its membership to a ''Class'' of functionally related gCube services. Classes are not pre-defined, and here we settle on ''Samples''. A free-form ''Description'' and a ''Version'' complement the preliminary description of ''SampleService''. |
| − | + | ||
| − | + | ||
| + | * ''SampleService'' is physically comprised of ''Packages''. A ''Main'' package identifies the main artefact to emerge from the build of the service, a ''GARArchive'', and provides information about the service port-types, including their ''WSDL''s' (here omitted for mercy). The profile unveils our initial plans for a single stateless port-type, which we name by identifying the relative part of the URI at which it will be accessible on the gHN (more on this soon). Another ''Software'' component identifies the secondary build artefact of the service, its own stubs. If the notion of build artefact is not obvious to you, bide your time for a little longer or [[Building & Deploying |jump ahead]]. | ||
| + | Save the profile in a file called ''profile.xml'' and place it in the ''etc'' folder of the service implementation: | ||
| + | <pre> | ||
| + | |-SampleService | ||
| + | |--etc | ||
| + | |---profile.xml | ||
| + | |--src | ||
| + | |--schema | ||
| + | | | ||
| + | |-Dependencies | ||
| + | |--SampleService | ||
| + | </pre> | ||
== My First JNDI == | == My First JNDI == | ||
Revision as of 10:53, 11 April 2008
Let us go through a quick tour of development with SampleService.
Contents
A Tiny Profile
A good starting point with service development is its configuration. And a good starting point when configuring a service is the definition of its profile. The role and structure of gCube service profiles is described in detail elsewhere. Here we just show one of the smallest and yet perfectly well-formed profile a service may have:
<?xml version="1.0" encoding="UTF-8"?> <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> <Version>1.0</Version> <Packages> <Main> <Name>Main</Name> <Version>1.0</Version> <GARArchive>org.acme.sample.gar</GARArchive> <PortType> <Name>acme/sample/stateless</Name> <WSDL>...</WSDL> </PortType> </Main> <Software> <Description>Describes port-type stubs</Description> <Name>Stubs</Name> <Version>1.0</Version> <Files><File>org.acme.sample.stubs.jar</File></Files> </Software> </Packages> </Profile> </Resource>
By necessity, this profile reveals things yet to come. For the time being, be happy with a conceptual summary:
- SampleService is a a particular type of gCube Resource, one of type Service. Like all gCube Resources has an ID, which it receives when it is formally registered with the infrastructure. Until then, SampleService does not have a proper identifier. No worries though, a temporary one will be generated by gCF at runtime.
- The profile of SampleService specifies its Name and specifies its membership to a Class of functionally related gCube services. Classes are not pre-defined, and here we settle on Samples. A free-form Description and a Version complement the preliminary description of SampleService.
- SampleService is physically comprised of Packages. A Main package identifies the main artefact to emerge from the build of the service, a GARArchive, and provides information about the service port-types, including their WSDLs' (here omitted for mercy). The profile unveils our initial plans for a single stateless port-type, which we name by identifying the relative part of the URI at which it will be accessible on the gHN (more on this soon). Another Software component identifies the secondary build artefact of the service, its own stubs. If the notion of build artefact is not obvious to you, bide your time for a little longer or jump ahead.
Save the profile in a file called profile.xml and place it in the etc folder of the service implementation:
|-SampleService |--etc |---profile.xml |--src |--schema | |-Dependencies |--SampleService
