Writing a ServiceMap Document

In order to create an application service using GFac, the application provider must write an XML document that we call the ServiceMap document. We provide a Web interface to create and regsiter the Service Map documents. If you have one avalible it is highly recomended to use it.

Example Service Map document

<ServiceMap xmlns="http://www.extreme.indiana.edu/namespaces/2004/01/gFac"
            xmlns:lead="http://www.extreme.indiana.edu/lead">

    <service>
        <serviceName targetNamespace="http://www.extreme.indiana.edu/lead">TestCMD_Example4</serviceName>
    </service>
    <portType>
    <method stageOutputDataFiles="true" forceFileStagingToWorkDir="false">
        <methodName>Run</methodName>
        <application paramValuesOnly="true" useLEADNameListFile="false" useLEADNameListPropertiesFile="false">
            <applicationName targetNamespace="http://www.extreme.indiana.edu/lead">TestApp</applicationName>
        </application>

        <inputParameter>
            <parameterName>InputParam1</parameterName>
            <parameterType>Integer</parameterType>
        </inputParameter>
        <outputParameter>
            <parameterName>OutputParam4</parameterName>
            <parameterType>FloatArray</parameterType>
            <regExp>outfile\d[a-zA-Z].*</regExp>
        </outputParameter>
    </method>
    </portType>
    <lifeTime>
        <notAfterInactiveMinutes>60</notAfterInactiveMinutes>
    </lifeTime>
</ServiceMap>

To learn about How to add methods and input parameters to service Map document please read Creating a simple ServiceMap document

Element/AttributeDescriptionRequired
serviceNameThe fully qualified name of this service i.e QName of this service. This is the targetNamespace plus the name of this service. http://www.extreme.indiana.edu/lead is the targetNamespace of this service and TestCMD_Example1 is the name of this service No two services must have the same QName.Yes
applicationName The QName of the application. This application is described in another xml document called the application description document. See the directory appDescDocs for some examples
Parent:ServiceMap/method/application
Yes
inputParameterEach input parameter represents an input to the service. The value(s) of each input parameter must be provided by the user/client (in the SOAP message) at the time of invoking the service A service can have zero or more input parameters.
outputParameter Each output parameter represents an output result of the application. The output result must be present in the "standard out" a.k.a stdout of the application. The service will parse the "standard out" of the application and while doing so will look for the output parameter name i.e "OutParam" in this case. It will then retrieve the value of "OutputParam1" and return it to the user. As an example, if the "standard out" of the application contains a line like OutputParam1 = "somevalue1", the service will return "somevalue1" in the SOAP message to the user/client. See the file ./testApp for some examples service can have zero or more output parameters.
paramValuesOnlySpecifies that the application must be passed only the paramValues and not paramName/paramValue pairs. This is usually true. If it is false, the parameters are passed as Name value pairs. If the parameter name is foo and it is a array type parameters will be passed as foo0,foo1 ....Optional
useLEADNameListFile Specifies that a FORTRAN NameList file be used instead of command line arguments
Parent:ServiceMap/method/application
Optional
useLEADNameListPropertiesFileSpecifies that the FORTAN NameList file must be updated with the values specified in the NameList properties file. This is passed along with the SOAP header
Parent:ServiceMap/method/application
Optional
regExpThe regular expression that represents the pattern of the output of the application. This regular expression will be used by the service to search for output of the application in its stdout
Parent:ServiceMap/method/outputParameter
Optional
notAfterInactiveMinutesThe services created by the toolkit support lifetime management. They renew their WSDLs with a well known Registry Service at regular intervals of time. You can specify the lifetime for a service in terms of the number of minutes of inactivity. After the specified period of inactivity, the service will un-register its WSDL from the Registry and shutdown. The period of inactivity is measured from the time the service sends the last response message to a client (not the time it receives the last request message from a client). You can specify the lifetime as shown below. The service will shutdown after 60 minutes after sending the last response message to the client.Optional

Sample Service Map Documents

Here are some examples of Service Map Documents (SMDs) that can be used as templates for writing new SMDs