Semantics and its' role in Business Services

Role and importance of semantics in the context of services and SOA:

Semantics refer to interpretation of information and not the literal definition of information/ data. Applying semantics to information turns it into “knowledge”. Semantics is the act of applying references and drawing conclusions given a set of more scientific informational constructs. Typically semantics are derived using the context in which information is presented. Transposition on the other hand allows applies the rule of inference where in one can draw conclusions on the implication of truth based on some set of facts.


By deduction semantics and semantic transposition deals with alternate inferences being drawn from one or more data and informational constructs using business rules. Inferences of this nature are not completely predictable as the rules used to arrive at the interpretation may or may not be quantifiable and/or may not be codified into a business rule.


The biggest risk in dealing with semantics is the lack of predictability of the outcome of an interaction, whether manual or automated. The reason is that the rules driving the decision tree or the execution path are not quantifiable.


Despite the complexity of interactions brought about by semantics and the complexity in being able to interpret these to codify and execute alternate behavioral patterns, one can attempt to capture metadata and leverage naming conventions to make the service based interaction more predictable. These guidelines may either be applied within an enterprise or could even have applicability to govern service interactions within an industry vertical.


In the realm of services, semantics drive both the discovery of services and also the execution paths and alternate process logic that is undertaken by the service provider. Naming conventions and expected service behavioral guidelines govern candidate service descriptions. Having documented behavioral implications and constraints associated with these naming conventions make the service “discovery” of a service and the expected interaction with the service provider more predictable from the service consumers perspective. These service naming conventions also act as metadata that can be used to publish information about the service definition during the publication and registry process.


Furthermore, one could make the assumption that there are certain features of a service action that denote the type of expected behavior, notwithstanding the type of business concept or the business function being manipulated by the service invocation. The service business action verb component can be associated with the general description of the type of behavioral patterns a consumer can expect. Given that SOA style services follow design by contract principles the naming and the signature of the service definition or description does not bind or affect the manner in which the service is implemented. This metadata of the verb does not impact communications patterns internally used by the service or even the informational model or informational exchange pathways that might internally be used by the service. These details are left up to the service provider. Having action verb nails expected behavioral semantics (inquiry only vs. alteration of service information model state) and not implementation semantics. Also, the action verb points to expected interaction semantics (one way/ two way/ guaranteed delivery etc.) and not the implementation model used by the service provider.


The key is that having these kinds of action-verb semantics outlined makes the service usage more specific. The service based action/ verb may be used by the consumer to identify the right service to use during the process of discovery. Also, the provider can use the action/verb notation to inform the consumer about the implications of the information being returned.


For example, a service operation called “obtainLoanRate()” with a action/verb embedded as the service invocation metadata may inform the consumer that the information being returned in not legally binding on the service provider. On the other hand, using the “lock” action/verb in the service invocation metadata “obtainLoanRate()” implies that the service provider is locking the rate and that the consumer is also bound legally to non-repudiation of the “rate” being locked. In this case, the semantics of the verb can be used by the consumer context to pick the right service depending on the usage context on the consumer tier. In addition the action/verb pairing may be used by the provider to insure that the right application logic is invoked. For instance, when the service consumer calls with a “get” action/verb invocation context the service provider implementation layer may go through fewer rigors and processing cycles than would be the case when the service consumer calls with a “lock” action/ verb invocation context.

Another example of the metadata driving semantics is the use of business context field by the service provider. A service operation “getCustomerProfile()” that uses the context of “Customer Profitability” or “Customer Credit Rating” could alter the information being returned in the payload of Customer Profiles. The service provider uses the service usage contextual information provided by the consumer to decide what type of information is returned to the consumer. The consumer context allows the service provider to alter the information returned between providing “Customer Profitability Range” or the “Customer Credit Score” in the customer profile.


As has been mentioned semantics can be applied to both the service publication and service discovery process. As part of the service publication process (to the registry) the service provider may use metadata in order to express the need for more precise contextual information to drive the way the service provider interprets the request. The service provider may add this constraint to leverage this information for altering the returned payload. The service consumer may also be able to use this business context metadata provided by the service provider along with the service provider business action-verb name to derive information about expected behavior of the service provider and how the request might be interpreted. For instance, a service operation that has an action-verb called “preview” may inform the service consumer that the information may not be reliable or even persisted beyond the current session while having a service consumer invoke a service operation with an action/verb “reserve” indicates to the consumer that the information returned is persisted beyond the current session. This naming convention is indicative of the service provider confidence factor in the consumption of the information being returned by the service provider.


In addition having some area for capturing the concept of the consumer context may help the service provider apply this knowledge to execute alternate paths of the business use case scenario. To some small extent, semantic transposition can be achieved by incorporating rules that have been gleaned from observing human behavior. If these manual workflows and best practices can be captured then these business rules can be used to execute alternate flows in the service. Consumer context information can then be used to invoke alternate business functionality and/or pathways that are known at compile time but may be loaded at runtime or invoked at run time on an as-needed basis.


The behavior altering ability can help the provider to honor consumer requests with more precision and with greater compliance to the contracted SLAs. This may also enable the service provider to roll out more behavior without altering the information models being exchanged and without altering the service interface. This may be a mechanism to curb the service version sprawl!!


Finally, the business context that is expected by the service provider or the business context information and candidate service name as published by the service provider could be classified as "service usage semantics". The purpose of the service usage semantics is to inform the service a consumer about the possibility of semantic variations in the honoring of service call.


Issues in incorporating Semantics in the realm of services and SOA


Semantics and "Semantic Transposition" may be fairly complicated to achieve in business systems. Most applications/services are typically written to fall cleanly into the “known” process logic pathways with no ability of either interpreting independent unrelated pieces of information. All paths typically have to be known and defined at compile time. In most situations, semantic interpretation may be complicated enough or unique enough to only be undertaken manually by knowledge workers. However, there may be a small subset of cases where the interpretations and inferences that drawn by the knowledge workers may be codified into rules and contextual metadata to help in the execution of alternate flows of a business use case.


Impact of semantics on Web Services, Service Registry and Service Repositories


As the concept of SOA and SOA style services become more standardized service related metadata registries/ repositories such as UDDI hosting web service URLs, service contract definitions and service descriptors defined as WSDL may make provisions to allow a service provider to publish service usage semantics, standard classifications and ontologies. These sets of metadata may become a guide in aiding the service consumers to browse for and find services more intelligently.


Furthermore, having a standardized mechanism to express the semantic usage information may enable tools to automatically bring this information back when service consumers are browsing for potential services. It must be noted that if this information is just some comment or a open ended description field instead of it being a structured metatag with known enumeration of values then browsing and searching for services cannot be automated.


Each industry vertical may have different values that might be populated into the standard structure to help with automating the search. These fields and valid industry vertical enumeration of values could all be published into the UDDI registry to help the consumer in either formulating the request or in informing the consumer about how to process the response.Some sample metatags could include fields such as business area field (Credit/ Sales/ Logistics).One such specification that is addressing Semantics in the realm of services is the Semantic Annotations for WSDL specification. http://www.w3.org/2002/ws/sawsdl/.


Conclusion


Having some stringency bound in using naming convention and in creating the request canonical models allows execution of the right sub-set of the service behavior thus making the service interaction more optimal. The presence of semantic oriented metadata allows the service provider to alter the behavior being executed in response to a service invocation and/or alters the amount and type of information returned to the service consumer.


Although not applicable in all situations, having contextual information and action/verb usage metadata information enables semantic transposition and execution of alternative service provider behavior s without having to resort to the execution of a human workflow and manual intervention. The objective of associating semantics to action verbs or in associating consumer context is not to bypass human intervention always but to use the learning obtained from the knowledge worker and encapsulate it in process automation logic.