Service Expression Classification Scheme

The e-Framework uses several classification categories to tag Service Expressions for cataloguing and discovery purposes. These classifiers will be used for all Service Expressions published by the e-Framework; however, submitters and other communities may add their own additional classifiers.

Complete and accurate classification of the Service Expressions will enable all parties to obtain a sense of a Service Expression’s characteristics and status, thereby helping them to assess the uniqueness of the Service Expression as well as its potential for application by other organizations or in other scenarios.

 

Major groups of classifiers

The classification scheme for Service Expressions includes several Status Classifiers as well as Technical Classifiers. Within each of these major groups, some classifiers are required while others are optional but highly desirable. Click on the links to view the permitted choices you can select for required status classifiers, optional status classifier, and required technical classifiers.

Status Classifiers

These classifiers describe a Service Expression’s general status and state of the component.

Required Status Classifiers:

• Domain – Focus, or area, of activity in which the Service Expression is principally used within an IT system. Areas of activity are generalised from the context of higher education.
• Development status - Status of the development of the Service Expression.
• Maturity – The measure of the maturity of the Service Expression.
• Status – The overall status of the Service Expression and its documentation within the e-Framework.
• Confidence - A measure of the level of consensus that the e-Framework partners have in the accuracy of the Service Expression; confidence will be assigned by the e-Framework.

Optional Status Classifiers:

• Deployment scale - The level of deployment or use within the community.

 

Technical classifiers

These classifiers denote the technical and behavioural characteristics of a Service Expression.

Required Technical Classifiers:

• State behaviour - How a service implementation invocation is related to any other service implementation invocation.
• Transactional behaviour – How a service implementation processes data as transactions.
• Batch behaviour - The type of processing of data or document sets by the service implementation.
• Time-constraint behaviour - How the service implementation deals with time constraints.
• Service end point – A description of the role of the Service Expression’s data/resource processing relationship with the other components.
• Authentication or authorization dependency - A description of how the service incorporates internal authentication or authorization controls.
• Protocol binding - The type of communications protocol binding for the service implementation.
• Service Genre coverage – Whether the Service Expression includes all of the features of the parent Service Genre.

Optional Technical Classifiers:

• None

 

Permitted choices for Service Expression classifier values

The e-Framework has specified a vocabulary from which you can choose the values to assign to each of the classifiers. Simply check the box next to the chosen word or phrase in the template document when you are preparing your Service Expression description for submission to the e-Framework.

For most classifiers, only one choice can be selected. For some classifiers, selecting multiple values is allowed; these classifiers will be listed as the plural form (with an 's') in the template used to submit a Service Expression.

Click on the classifier links above to review the definitions of the available choices. Providing a value or values for each required classifier and for as many optional classifiers as you can will benefit the entire community. (Required classifiers are in BOLD type in the templates.)

Note: The e-Framework Editorial Team will assign the appropriate Status and Confidence level and reserves the right to modify other classifier values prior to publication to ensure consistency across all components.

Last updated 14 October 2008