SORCER Computing Platform

Service-Oriented Programming

In service-oriented programming three types of services are distinguished: operation services, and two types of request services: elementary and combined. Combined services are called service disciplines. A discipline is a distinct design pattern of a request service such as declarative, procedural, mogramming service, or managed service cooperation of hierarchically organized disciplines in the form of collaboration or governance. Each discipline is arranged to be in accordance with a particular system of organization (structure) and management (behavior). Mogramming is related to cooperation of declarative services (service models) or procedural services (service routines), or both - in short mograms for mogramming services. Mograms in SML (Service Modeling Language) are called service domains.

An operation service, in short opservice, invokes a service provider operation. An elementary request service asks a service provider for output data given input data. A combined request service asks for cooperation of service providers and utilizes obtained output data from multiple service providers. A service consumer combines output data of aggregated request services. Therefore, the end user by creating request services and utilizing the actualized corresponding partnership of service provider becomes the coproducer of net-centric service cooperations. Software developers develop service providers provisioned in the network but end the end users create combined request services for provider partnerships in the network.

A compute service is the work performed in which a service provider (one that serves) exerts acquired abilities to execute a computation. The true compute service runs the request services using net-centric service providers to be expressed and executed under condition that service consumers should never communicate directly to service providers. An elementary request service is realized by the opservice that binds to the corresponding service provider at runtime. A combined request service is realized by hierarchically organized opservices that bind to the dynamic service provider partnership in the network.

Historically, a program has been viewed as a callable unit (subroutine) 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 challenge of service-orientation is refocused on cooperation and coordination of net-centric (local/remote) autonomous objects - service providers. Discipline-oriented programming takes the view that what we really care about is cooperation of service providers - partnerships - rather than the subroutines with data required to manage them. Service-orientation shifts programming subroutines and objects to the backend but with the focus on programming disciplines and co-producing combined request services by the end-users at the frontend. A combined request service is the expression of service-oriented process actualized by the partnership of local/remote autonomous service providers at runtime.

In the Service-Oriented Modeling Language (SML) everything is a service. Seven main categories of multifidelity request services are distinguished: tasks, entries, pipelines, domains, disciplines, trnasdomains, and transdiciplines. Service-oriented mogramming is the software methodology around service activities rather than service actions; organized around net-centric cooperation of service providers rather than service provider subroutines. It is about the approach of specifying service partnership by the end user rather than developing subroutines of the application, tool, or utility (ATU) by a programmer. Elementary services correspond to ATU activities by opservices, and knowledge incorporated into creation of combined request service in terms of opservices is the source of competitive advantage. The end user by creating and executing request services at runtime is seen as the service consumer and co-producer of software on the fly.

The basic principle of service-oriented design is based on the separation of concerns regarding process expression (frontend) from process actualization (backend). Concerns are considered service providers at the back-end and request services comprised of hierarchically nested opservices at the frontend. Operational capabilities of a service provider (HOW) are designed to solve an individual operational concern as a cohesive and atomic service action - opservice. In contrast, a request service specifies abstract interactions (WHAT) between net-centric service providers in terms of opservices. Services providers can be considered as tools, applications, or utilities and their functionality being represented by opservices in request services. A request service specifies cooperation of service providers created by the end user. The expressed cooperation reflects the experience of the end user as the coproducer of request service - service-oriented applications. Consumers want services to be convenient for them, to create and run own service cooperations of ATUs and other component reusable request services. The corresponding service interactions at the backend are coordinated by the dedicated service-oriented operating system (SOS) such that: 1. binds opservices of the request service to partnership of service providers at runtime, 2. manages the cooperation of bound service providers (partnership) for the request service, and 3. finally returns the context of cooperation then disassembles the created service partnership.

In principle, there are no static service connections to service providlets. A request service specifies all interactions to be dynamically established by SOS as specified by configuration/execution dependencies by the end user. A mogram can be specified imperatively (Routine) or decoratively (Model), or a hierarchically organized Domain service (of Transmodel or Tansroutine type) in Service Mogramming Language (SML).

The SORCER platform simplifies radically creation and execution of complex large transdomain and transdisciplinary multifidelity distributed systems as hierarchically organized request services in SML. All system dependencies declared in combined services by the domain expert are realized by the SOS with available/provisionable service providers as autonomous applications, tools, and utilities in the network and/or locally.

The first step in mogramming is to identify all the opservices the end user needs to use and how they relate to each other in a process expressed by the corresponding request service - an exercise often known as service modeling. Once opservices have been identified, corresponding service contexts define the kind of data required by the corresponding service cooperation. Each distinct opservice is known as a service action defined by the provider’s service type(s) used as a binding reference to service provider.

True Service-Oriented Metamodeling Architecture is the underlying metamodeling framework for the SORCER platform. It’s service-oriented metamodeling architecture of the net-centric multifidelity request services and exchange of context-based information is organized around provider services called opservices, which are specifying for the end users the instruction set of the network service processor. The approach allows to express in SML various types of service-oriented processes as hierarchical combinations of opservices and subordinate request services.

SORCER Terms and Definitions

• action
  A fundamental unit of behavior specification that represents some transformation or processing in the modeled system, be it a computer system or a real-world system. Actions are contained in activities, which provide their context. See: activity.

• activity
  A specification of parameterized behavior that is expressed as a flow of execution via a sequencing of subordinate units (whose primitive elements are individual actions). See: action.

• call
  An action state that invokes an operation on a classifier.

• client-server architecture
  The client-server architecture is a distributed architecture that separates a client from a provider of service or resource - server.

• class
  A classifier that describes a set of objects that share the same specifications of features, constraints, and semantics. See: classifier.

• classifier
  A collection of instances that have something in common. A classifier can have features that characterize its instances. Classifiers include interfaces, classes, datatypes, services, and components.

• collaboration service
  A collaboration service is a type of transdomain service focused on exploration of cooperating domain services. In particular optimization processes are expressed by service collaborations.

• combined request service (discipline)
  A combined request service is a hierarchically organized contextion comprised of elementary and other combined request services.

• combined routine
  A combined routine is a request service that is comprised of elementary and other combined routines. There are three types of combined routines: blocks, jobs, and conditional tasks.

• computing platform
  A computing platform allows software to run on the computer and requires a processor, operating system, and programming environment with related runtime libraries and user agents.

• context (service context)
  A service context is a collection of service entries such that each entry name (path) is uniquely associated with a value to be returned. The returned value can be constant (by value entry) or evaluated value (by evaluated entry). Contexts with value entries are called data contexts, contexts with evaluated entries are called context models or entry models. Evaluated entries use various types of evaluators, therefore various types of context models can be considered. See: service entry.

• context model
  A context model is a declarative service representing a collection of interrelated functional compositions expressed by multifidelity service entries. See: multifidelity, service entry.

• context opservice in short cxt-opservice
  Four categories of cxt-opservices are distinguished: getters, setters, connectors, and appenders used for preprocessing and postprocessing service contexts associated with request services (contextions). See: operation service.

• contextion
  A context aware request service. A contextion is as a mapping that produces an output context when given an input context, both of Context type. All combined request services are contextions of hierarchically organized subordinate contextions. See: context.

• discipline orientation
  Service-orientation in which services are divided into separate and distinct design patterns or service disciplines, such as declarative, procedural, mogramming domains, and managed service cooperations as collaborations nad governances.

• discipline service
  A distinct design pattern of a request service such as declarative, procedural, mogramming service domain, or managed service cooperation of hierarchically organized disciplines in the form of collaboration or governance. Each discipline is arranged to be in accordance with a particular system of organization (structure) and management (behavior).

• domain service
  A service domain is a service contextion defined declaratively or imperatively. A domain defined by a service routine is called an imperative (procedural) domain. A domain defined by a context model is called a declarative (functional) domain. A domain that comprises of subordinate domains is called a transdomain - either a transroutine or transmodel. Context values of an imperative domain are defined by subroutines (tasks, blocks, jobs) but values of a declarative domain by service entries (function compositions). Context values of transdomains are determined by analyses and explorations
  of values returned by subordinate domains either of model or routine types. SML domains are realized by provider assemblages and transdomains by provider aggregates.
  See: “mogram”, “mogramming”.

• elementary request service
  An elementary request service is a service task or service entry that invokes an opservice.

• elementary routine
  An elementary routine is an elementary request service defined by a signature and a data context. A basic elementary routine is called a service task. A service task with multiple signatures is called a batch task.

• exertion
  Exertions are request services (contextions) type that exert service providers in the network. Exertinng means net-centric execution of the service that that binds to the service providers at runtime and returns itself with the incorporated result and the net-centric state of execution along with the feedback from executing service providers and the network itself. It may include exceptions, errors, or any related runtime information. See: mograms.

• exec-opservice
  An exec-service is either a service signature or a service evaluator. A service signature binds to a service provider at runtime but an evaluator runs directly its executable code. Executable codes are realizations of multifidelity exec-opservice; it means that for each exec-opservice there is at least one realization executing locally or remotely. See: operation service.

• fidelity
  Fidelity is defined to be “the quality or state given with strong assurance; accuracy in details” (Webster), For a computing process, accuracy and fidelity have the same meaning. Fidelity and cost (or similarly accuracy and time) are positively correlated; this represents a fundamental trade in design.

• governance service
  A governance service is a transdisciplinary structured as a supervised cooperation of federated disciplines. Federated disciplines can be seen as a cooperation of heterogeneous standalone contextions (states) unified under common governance (analysis and exploration provided results) to be supervised by a governor (supervisor).

• instance
  An entity that has unique identity, a set of operations that can be applied to it, and state that stores the effects of the operations. See: object.

• metamodel
  A model that defines the language for expressing a model. 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.

• method
  The implementation of an operation. It specifies the algorithm or procedure associated with an operation.

• model
  A representation of a set of components of a process, system, or subject area along with a representation of data, activities, relationships, and constraints, generally developed for understanding, analysis, improvement, and/or replacement of the process.

• mogram A mogram is an exertion that specifies hierarchically structured cooperation of models and routines created by the end users seen as co-producers of service-oriented software. SORCER mograms are expressed in SML by domain services and are realized by the net-centric service provider partnerships. See: “mogramming”, “domain service”.

• mogramming
  Mogramming is service-oriented programming or modeling, or both. See: “mogram”, “domain service”.

• multifidelity
  Multifidelity in computing perspective that refers to a computing environment with multiple fidelity levels for a given computing process, meaning there are different computing processes to choose from. When selecting the fidelity of multifidelity for a computing process, it is important to appropriately balance the fundamental trade between cost and accuracy.

• object
  An instance of a class. See: class, instance.

• operation
  A feature which declares a service that can be performed by instances of the classifier (Evaluator and Provider) of which they are instances.

• operation service in short exec-opservice
  An operation service, in short opservice is a primitive action. Two types of opservices are distinguished: execute opservices, in short exec-opservices and context opservice, in short cxt-opservices. Exec-opservices call operations on service providers, but cxt-opservices transform input/output service contexts of executing request services (contextions).

• partnership
  A partnership of service providers is a dynamic structured collection of service providers created to actualize service cooperation expressed by a combined request service.

• procedure
  A set of actions that may be attached as a unit to other parts of a model, for example, as the body of a method. Conceptually a procedure, when executed, takes a set of values as arguments and produces a set of values as results, as specified by the parameters of the procedure.

• process

  1. A service process—the process expressed by a request service and actualized by the corresponding cooperation of service providers.
  2. A heavyweight unit of concurrency and execution in an operating system. Contrast: thread, which includes heavyweight and lightweight processes. If necessary, an implementation distinction can be made using stereotypes.
  3. A software development process—the steps and guidelines by which to develop a system. 3. To execute an algorithm or otherwise handle something dynamically.

• provider service called exec operation service, in short exec-opservice
  A provider service is the action performed by which a service provider (one that serves) exerts acquired abilities to execute a computation. Two categories of exec-opservices: signatures and evaluators are distinguished. Opservices are context aware* - its argument and returned values are of Context type.

• realization
  A specialized abstraction relationship between two sets of model elements, one representing a specification (the supplier) and the other representing an implementation of the latter (the client).

• receiver
  The object handling a stimulus passed from a sender object. Contrast: sender.

• region service
  A specification of a discipline as the active service that exhibits self-control (dispatching), data (context) and target service (contextion) represented by the CCD triplet: <context, contextion, dispatcher>. Dispatchers are routine services. See: context, contextion, “routine service”.

• relationship
  Relationships used in knowledge representation, object/service-oriented programming and design, can be summarized as follows:

  1. In a dependency relationship, the client depends in some way on the supplier.
  1. Associations are relationships between classifiers. Just as links connect instances, associations connect classifiers.
  1. Classifier-instance (concept-object, metamodel-model) relations between classifiers and its instances, where 1. an object has an instance-of relationship with its classifier.
  1. Supertype–subtype relations between types (classes) defining a taxonomic hierarchy, where 2. for a subsumption (inheritance) relation: a subtype has a type-of (is-a) relationship with its supertype.
  1. Relations between types (classes) defining a possessive hierarchy, where 1. for an aggregation (i.e. without ownership) relation: a whole has a has-a relationship with its part, 2. for a composition (i.e. with ownership) relation: a constituent has a part-of relationship with its entity, 3. for a containment relation: a member has a member-of relationship with its container.

• request service
  Request services are activities expressed as a flow of execution via subordinate request services whose primitive elements are individual opservices. Two types of request services are distinguished: elementary and combined. An elementary request service specifies call on a single service provider. A combined request service specifies cooperation of hierarchically structured calls on service providers.

• routine service
  A routine service, in short routine when not confusing, is comprised of elementary routines and combined routines that comprise from other routines. Elementary routines are called service tasks and three types of combined routines are distinguished: blocks, jobs, and conditional tasks.

• send [a message]
  The passing of a stimulus from a sender instance to a receiver instance. See: sender, receiver.

• sender
  The object passing a stimulus to a receiver instance. Contrast: receiver.

• service
  A service is the work performed in which a service provider (one that serves) exerts acquired abilities to execute a computation. In service-oriented programming, a request service is a specification of context-based, multifidelity, and net-centric behavior that is expressed as a cooperation of subordinate request services whose primitive elements are operational services executed by corresponding service providers.

• service entry
  A service entry is a pair: <service name, service evaluator>. Service entries are elementary services used in context models to create functional compositions via evaluator arguments that refer to other service entries. In hierarchical compositions (contexts) the entry name is a path in the namespace of a context. An entry path is uniquely associated with the entry value (value entry), evaluated value (procedural entry), or exerted value (request entry). Value entries correspond to constant evaluations (functions).

• service evaluator
  A service evaluator is the instance of Evaluation or Invocation type defined in SORCER. Service evaluators are opservices and used to provide values for service entries.

• service federation
  A service federation is a service provider partnership created at runtime to realize supervised cooperation of disciplines managed by disciplinary analyses and explorations under shared governance. See: governance service, partnership.

• service mogram
  Represents runtime partnerships of SML domain services.

  • specifies routine tasks by net and object signatures
  • specifies entries of service models by evaluators
  • specifies input/output data of cooperations as context management
  • specifies hierarchically organized service cooperations (domains)
  • specifies fidelity management of cooperations by fidelity projections and morphers

• service operating system (SOS)

  • provides a service-oriented shell for the SML
  • executes contextions/netlets expressed in SML
  • runs a service virtual machine (SVM) executing opservices
  • manages runtime service cooperations of service providers for contextions

• service pipeline
  A service pipeline is a set of opservices connected in series, where the output of one opservice is the input of the next one. The opservices of a pipeline can be executed sequentially or in parallel. A pipeline is a combined opservice of Evaluator type that can be used with looping and branching evaluators to form structured algorithms. Exec-opservices can be concatenated with cxt-opservices that preprocess/postprocess service contexts used by exec-opservices and request services.

• service provider
  An entity that provides a specified executable code or collection of executable codes referred by exec-opservices. In SORCER, service providers are of the Provider type, in particular instances of Evaluator and Exerter subtypes. Remote instances of Exerter types bound to exec-opservices by service multitype are called providlets. See: exec-opservices, service provider type.

• service provider type
  A service provider type, in short service type, is either an interface type (for remote exec-opservice) or a class type (for local exec-opservice). Service signatures bind to remote service provider instances (providlets) by multiple service type (service multitype) at runtime. See: exec-opservice, aervice signature.

• service registry
  A service registry is a resource that provides dynamically controlled access to service providers. In effect, it is a constantly evolving catalogue of information about the available service providers. The ultimate goal is to allow fast and reliable communication and interoperability among diverse applications with minimal human oversight.

• service signature
  A service signature is an exec-opservice specified by an operation and its service type called the primary service types. Additional service types may complement the primary service type - to form a service multitype to be used as the net-centric classifier of service provider instances. The executed service signature binds to a service provider at runtime and runs the operation of service provider locally or remotely depending on how the primary service type of the provider is specified. If the primary service type is a class type, then the instance of the provider is created at runtime and executes locally. Otherwise, the signature multitype binds to the instance (providlet) in the network.

• service task
  A service task is an elementary request service that contains a single signature with service context that the signature operates on.

• SML
  Service Mogramming Language (SML) is a metamodel of request services called contextions defined by semantics of the MetaService Facility (MSF) 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 mogramming. A request service created with opservices defines the partnership of service providers. Therefore, the request service is the metamodel for its service partnership - the net-centric service processor but the instance of SML as its metamodel. SML scripts are executable with the SORCER network shell (nsh) and with ServiceRequestor (see the examples/service project). Also SML expressions can be complemented with the SORCER API and used all together as regular Java sources.

• SORCER
  A service-oriented computing environment (SORCER) is a SOOA-based computing platform, which provides service-oriented mogramming environment within its operating system that runs request services and dynamically manages a dynamic net-centric processor - partnership of local and remote service providers of executing request services. The object-oriented model of core SML classes is illustrated in the UML diagram of SORCER Top Level Types.

• SORCER platform
  Programming Environment, Service Operating System (SOS), and Net-centric Service Processor

  • Programming Environment - SML, netlets, Java API
    • Request services – multi-tier multiFi contextions
    • Input and outputs contexts – domain intelligence
  • Service Operating System (SOS) - net-centric intelligence
    • Service shell
    • Network service shell
    • Multi fidelity management (reconfiguration and morphing)
    • Service Virtual Machine (SVM)
  • Net-centric Service Processor
    • Partnerships of system service providers
    • Partnerships of domain-specific service providers
    • Signature-based service binding and provisioning
    • Multitype service lookup and discovery

• SORCER basic service interfaces
  • Service public Object execute(Arg... args) throws ServiceException, RemoteException;
  • Request extends Service public Fi getMultiFi(); public Morpher getMorpher();
  • Contextion extends Request public Context evaluate(Context context, Arg... args) throws EvaluationException, RemoteException;
  • Exertion public <T extends Contextion> T exert(T contextion, Transaction txn, Arg... args) throws ContextException, RemoteException;
  • Mogram extends Contextion, Exertion, public <T extends Contextion> T exert(Arg... args) throws MogramException, RemoteException;
  • Evaluation<T> public T evaluate(Arg... args) throws EvaluationException, RemoteException;
  • Invocation<T> public T invoke(Context<T> context, Arg... entries) throws ContextException, RemoteException;
  • Exerter extends ServiceProvider, Exertion
  • Evaluator and Exerter are subtypes of ServiceProvider

• SORCER service provider
  • defines acquired abilities by its service types - multitype
  • implements, advertises, and owns its proxy by its multitype
  • satisfy three neutralities (location, protocol, implementation)
  • provides net-centric service provider/beans container

• SOA
  A service-oriented architecture (SOA) is a software architecture using loosely coupled service providers that introduces a service registry, the third component to client-server architecture. The registry allows finding service providers in the network to create service collaborations.

• SOOA
  A service-object-oriented architecture is SOA with the communication based on remote object message passing with the ability to pass data using any wire protocol that can be chosen by a remote object (service provider) to satisfy efficient communication with its requestors. In SOOA a proxy object is created and owned by the provider so its service requestors are wire protocol neutral. SORCER is based on SOOA.

• SPOA
  A service-protocol-oriented architecture is SOA with a wire protocol between service requestors and service providers that is predefined and final. In SPOA a proxy that complies with the fixed wire protocol is created and owned by the service requestor.

• stereotype
  A class that defines how an existing metaclass (or stereotype) may be extended, and enables the use of platform or domain specific terminology or notation in addition to the ones used for the extended metaclass. Certain stereotypes are predefined in the UML, others may be user defined. Stereotypes are one of the extensibility mechanisms in UML. See: constraint, tagged value.

• transdomain service
  A transdomain service is a cooperation of context models and service routines as a transmodel or transroutine service and explained in terms of a hypothetical service-oriented computer which performs the collection of the transdomain multifidelity actions which constitute the elaboration of subordinate domains. Executing a transdomain service spawns the process of the hierarchical service cooperation at multiple layers associated with the subordinate domains that adds more information to subordinate domains to create a more complex, emergent transdomain returned at the end to the service consumer. Transdomain service cooperation designed by the end user is actualized by the service provider aggregate managed by SOS.

• transdisciplinary service
  A transdisciplinary service is a cooperation of service disciplines as a collaboration or governance service and explained in terms of a hypothetical service-oriented computer which performs the collection of the transdisciplinary multifidelity actions which constitute the elaboration of subordinate disciplines. Executing a transdisciplinary service spawns the process of the hierarchical service cooperation at multiple layers associated with the subordinate disciplines that adds more information to subordinate disciplines to create a more complex, emergent transdiscipline returned at the end to the service consumer. Transdiscipline service cooperation designed by the end user is actualized by the service provider federation managed by SOS.