What Are Service Expressions?

Service Expressions represent specific cases of the related but abstract and generalized Service Genre. The detailed description of the Service Expression can be used to design an actual implementation of the behaviours associated with the Service Genre. (Ultimately, Service Expressions are ‘derivatives’ of a Service Genre, but the process by which Service Expressions are created is not always ‘derivation’ – Service Expressions could be developed before or simultaneously with establishing their related Service Genre.)

Illustrative Example – Shipping a Package

To illustrate with a common, everyday example, consider the activities associated with shipping a package via the postal system, parcel service (DHL, UPS, FedEx, etc.) or other type of courier service. While each business will have its specific processes and procedures for interacting with the package’s sender, the package and the intended recipient, there are processes that are common to all – these are listed as Service Genres in the table below.

The essence or general capability of sets of detailed behaviours about shipping a package constitutes a Service Genre. The binding of these behaviours to a specific technology choice is a Service Expression of the associated Service Genre.

In the shipping example, using a paper form at the shipper’s shop or designated drop-off location is one Service Expression of the “Preparing Shipping Instructions” Service Genre. An alternate way to execute the same behaviours would be for the sender to use an online form to indicate the recipient and to choose delivery and other options.

Thus the online form procedure represents another Service Expression – another binding of the behaviours associated with the Service Genre but to a different technology. The two Service Expressions are specific ways of achieving the Service Genre. (A third Service Expression would be for the shipper to prepare a paper form on behalf of the sender.)

The details that describe each particular Service Expression are captured in the Service Expression Description - the complete ‘what’ and ‘how’ that you would need to know in order to successfully ship a package. For this example, the Service Expressions would need to detail how to use the online and paper forms; how to hand off the package at a location; how to arrange for a pickup; how the package may be delivered; various ways to obtain tracking status; and options for obtaining delivery confirmation.

Service Genres	Behaviours	Service Expressions
Preparing Bill of Lading/ Shipping instructions	Select sender Select recipient Select delivery method (standard, express) Select payment Select insurance Select customs info	Online form Paper form prepared by sender Paper form prepared by shipper
Transfer to shipper	Ingest into delivery system Track pickup/Notify sender Track pickup/Notify recipient	Drop box Counter Home pickup Business pickup
Delivery	Track delivery/Notify sender Track delivery/Notify recipient Delivery release	Pickup from shipper Delivery to address by truck Delivery to address by postal carrier
Tracking/Alert	Track status	Notify (push email) Check status (lookup)
Delivery confirmation	Send confirmation	Electronic Post

The Service Expression Description is the documentation used to provide detailed information about the behaviours, operations and interfaces that the Service Expression represents. The information in the Service Expression Description should be sufficient to allow a software designer to write computer code that when implemented, will perform a particular part of the overall process.

Thus in the example about shipping a package, the Service Expression Description for “Notify” would allow a software designer to write computer code that when implemented would send an email message announcing the successful delivery of the package.

Of course, there can be many equivalent, independent designs that will ultimately perform the same process when implemented. These alternatives will differ only in the choices made by the designer, not in the functionality or interface of the working code.

In the e-Framework, there may be widespread need for a Service Genre called “Search”. The Search Genre may have a number of expressions such the SRW specification. Designers may choose to enable the SRW search expression in different ways - for example writing their own code or using an open source SRW toolkit - but the end user must get the same results, no matter which software is used.

At the abstract level, Service Expressions will be related to other Service Expressions, especially those that can be grouped within a common Service Genre, and thus will overlap in functionality with other Service Expressions. However, no two Service Expressions should be identical. The e-Framework will not accept Service Expressions that duplicate existing Service Expressions. (Service Expressions A-1, A-2 and A-3 based on Service Genre A can overlap in function with each other, just as Service Expressions B-1, B-2, and B-3 that are based on Service Genre B can overlap; however, neither Service Expressions A-1, A-2 nor A-3 should overlap in function with Service Expressions B-1, B-2 or B-3.)

While providing formal documentation of a Service Expression might seem like a big task, several of the formal elements in the Service Expression Description correspond to phrases you would use to informally describe the what and how of the behaviours and the specific technologies:

Informal phrases	Formal elements
What it does	Description
How it can be used	Functionality
Its basic interactions	Requests and Behaviours
How to combine everything	Uses and Interactions

If you would like to submit a Service Expression to the e-Framework for consideration, go to Service Expression Submission page. Before submitting you are encouraged to view examples of Service Expressions currently registered in the e-Framework.

Last updated 30 January 2008