Service-Oriented Programming and Mogramming

Service-oriented programming (SOP) is a programming model organized around service activities rather than service provider actions; organized around service collaborations rather than service provider subroutines. It’s about the approach of specifying service collaborations by the end user rather than a programmer developing subroutines of the service provider.

Historically, a program has been viewed as an subroutine (callable unit) that takes input data, processes it, and produces output data. The programming challenge was seen as how to write subroutines, not how to manage data. Object-oriented programing shifted the focus from subroutines to data management - objects with encapsulated data managed by subroutines (methods). The SOP challenge is refocused on collaborations of networked (local/remote) autonomous objects - provider services. Service-oriented programming takes the view that what we really care about are the service collaborations we want to create dynamically rather than the subroutines with data required to manage them. The focus of service-orientation shifts from programming subroutines and objects at the server-side (provider services at the back-end) to programming service collaborations at the client-side (requestor services at the front-end) created by the end user. The requestor service (mogram) expresses service-oriented process that is realized by the corresponding collaboration of local/remote autonomous provider services at the back-end.

The basic principle of service-oriented design is based on the separation of concerns as services and with the separation of process expression (front-end) from process actualization (back-end). Concerns are considered as provider services at the back-end and hierarchically nested compositions of abstract references (handles) to provider services as a requestor service at the front-end. Operational capabilities of a provider service (HOW) are designed to solve an individual computing concern as a cohesive and autonomous provider service while a requestor service specifies abstract interactions (WHAT) between provider services in terms of abstract service types implemented by provider services. Provider services can be considered as tools, applications, or utilities while a requestor service is an abstract service model defining interactions between provider services in terms of their service types. The service interactions at the back-end are realized by a dedicated operating system, for example the SORCER OS, such that: 1. using service types assembles for a requestor service a provider-service federation at runtime, 2. manages the federation of provider services to execute the declared service-oriented process - requestor service, and 3. finally returns the result of collaboration then disassembles the created service federation.

In principle, there are no static service interactions at the back-end. A requestor service specifies all interactions as the abstract service model created by the end user (domain expert) who defines all configuration/execution dependencies in the service federation at the front-end. A service model can be defined imperatively in Exertion-Oriented Language (EOL) or declaratively in Context Modeling Language (CML). A service model that is declaraive and/or procedural is called a service mogram.

The SORCER platform with its true service-oriented mogramming environment, for Service Modeling language (SML) that consits of EOL and CML, simplifies radically creation and execution of complex large transdisciplinary multifidelity distributed systems as a hierarchically nested mograms that represent so called N2/N3 diagrams. All system dependencies declared in mograms by the domain expert are realized by the SORCER OS with provided/provisionable provider services as autonomous applications, tools, and utilities.

The first step in mogramming is to identify all the services the end user needs to use and how they relate to each other in a compound service request - a requestor service, an exercise often known as service modeling. Once services have been identified, corresponding provider services define the kind of data they contain - service contexts - and any subroutines that can process the data. Each distinct subroutine is known as a service action (operation) defined by the provider’s service type used as a reference to service provider.

Mograms that express the work to be done by collaborating provider services, are front-end (abstract) services with respect to actualized concrete service collaborations as their back-end. The end users create front-end services - service activities - while software engineers develop provider services – actions of individual service providers.

Basic Service-Oriented Terms

A provider service is the work performed in which a service provider (one that serves) exerts acquired abilities to execute a computation. The behavior of the service provider is defined by its service type (in SORCER a Java interface type) therefore the service type is called a service that in turn is used to specify a member of service federation in the requestor service.

Federated Service Architecture (FSA) is the underlying framework for the SORCER system. It’s a service-oriented model of the coordinated computing and exchange of information which is organized by provider services, which are describing common concepts and behavior for the end users. The approach allows for interoperability and information sharing between locally and/or remotely distributed autonomous services.

  • A Service Signature is a classifier of service actions specified by an operation and its service type.
  • A service types is either an interface type (for remote action) or the class implementing the interface type (for local action).
  • There is no static references to service providers!
  • A service action is context aware - its argument and returned value are of Context type.
  • An exertion is a imperative service model representing collaborating providers-federation-to be exerted (assembled, managed, and disassembled) by the SORCER Operating System (SOS).
  • A context model is a declarative service model representing a collection of of evaluated functional compositions that can be bound to collaborating providers-federation via service signatures used the same way as in exertions.
  • An elementary exertion defined by a signature with its data context is called a task exertion.
    A task with multiple signatures is called a batch task.
  • A compound exertion additionally contains a control context and component exertions.
    There are three types of compound exertions: blocks, jobs, and conditional exertions.
  • The core of service-object-oriented semantic model of Service Modeling Language (SML) is illustrated in the UML diagram of SORCER Top Level Types.
  • By contrast, two parts of SML: declarative Context Modeling Language (CML) and imperative programming Exertion-Oriented Language (EOL) - expose only very limited number of top-level types (mostly interface types) that are associated with service-oriented operators.
  • Exertions can be created with the EOL and SORCER API. Also in the form of service scripts (netlets) can be created with EOL.
  • A metamodel is an explicit model of constructs and rules needed to build specific model within a domain of interest. A domain-specific language (DSL) can be defined by a metamodel or grammar.
  • SML is a metamodel of front-end services created as service models that express proper semantics of true service-orientation. The term ‘semantics’ reflects the need to not only model something in the real world, but to model the meaning that this something has for the purpose of the metamodel - service-oriented computing.
  • How to create textual mograms (netlets) that can be executed with no need to compile SML source files (SML scripts) (see EOL Exertions and CML Context Models) .
  • You can complement EOL with the CML or vice versa in the process of service modeling and/or programming at the same time, called service mogramming.
  • A netlet is a mogram as it is illustrated in the SORCER model-driven architecture.
  • SML scripts can be executed with SORCER ServiceRequestor (see it in the examples/service project) and SORCER Network Shell (nsh). SML expressions can be complemented with SORCER API and used all together as regular Java sources.

A SORCER Service Provider:

  - defines acquired abilities by its service types
  - implements, advertises, and owns its service types
  - satisfy three neutralities (location, protocol, implementation)

A Service Exertion models runtime collaboration of providers - service federation

  - specifies federation's members by exertion signatures
  - specifies federation's data context and data flow
  - specifies federation's control strategy

The Service interface (Service#service(Exertion)) is implemented by:

  - service providers
  - exertions
  - service contexts (data models)
  - signatures
  - service-oriented shell (sosh)

SORCER Operating System (SOS)

  - executes exertions/netlets expressed in CML/EOL
  - assembles, manages, and disassembles runtime service federations for requestor services
  - provides a service-oriented shell for the SOS

The meaning of a service model in the SML language is an aggregation of context models and service exertions with the top-level entity either as the context model or service exertion and explained in terms of a hypothetical service-oriented computer which performs the set of the service model actions which constitute the elaboration of that service model. Exerting a service model spawns the collaborative process of the service federation associated with the model that adds more information to existing exertion to create a more complex, emergent exertion returned at the end to the service requestor. The end user models front-end service orchestration and the SORCER Operating Systems actualizes it as the back-end service orchestration in its dynamically managed federation of local/remote service providers..

Comparing Object-oriented to Service-oriented Conceptualizations

Object Orientation Service Orientation
EaaO EaaS
Object Service
Sender/Receiver Requestor Service/Provider Service
method signature = selector and parameters service signature = selector and service type
parameters service context
Object reference Service action reference = service signature
message = receiver.selector(arguments) elementary exertion = task(signature, context)
compound exertion = composite of exertions with control flow exertions
model = functional composition of entries (functions)
Argument specific Context aware
OO program => collection of objects SO moogram (front-end) => service federation (back-end)
Send message = invoke object's method Request service = exert service collaboration
Object obj = new(Class) Service mogram = exertion(signature, context, {exertion} )
Service mogram = model( {model entries} )
Receiver reference - object reference Signature - front-end reference to provider action
Mogram - front-end service model to back-end service federation
Remote Method invocation (RMI) Federated method invocation (FMI)
Programming Mogramming = CML + EOL
Virtual Machine SO Operating System

Back to top

Version: 1.0-SNAPSHOT. Last Published: 2016-01-17.