True Service-Oriented Metamodeling Architecture
A language can be specified by a metamodel hierarchy with a great flexibility. A language can be also specified by a grammar, for example the Java language in EBNF. The primary responsibility of the metamodel layer is to define languages that describe semantic domains to allow users to model a wide variety of different problem domains. The presented approach to true service-oriented metamodeling architecture is based on three categories of services: operation services (signatures and evaluators), elementary request services (task and entries) and combined request services (domain, assembley, transdomain, discipline, transdiscipline) used with three pillars of service-orientation: contextion, multifidelity, and multityping.
A service is the work performed in which a service provider (one that serves) ex-erts acquired abilities to execute a computation. To be the true service resulted from the performed computation, both the computation and the service providers have to be expressed then realized under condition that service consumers should never communicate d irectly to service providers. Asserted cooperations of service providers represented by operation services are called request services. This way, in SML everything is a service. Request services represent cooperations of opservices bound at runtime to service providers to execute computations. In this paper, service-orientation is proposed as the approach with five types of emergent net-centric multifidelity request service representing the following service request services: pipelines, assemblies, collaborations, disciplines, governances.
The “everything is a service” semantics of SML is introduced for request services to be actualized by dynamic cooperations of service providers in the network. A multifidelity request service is considered as a dynamic representation of a net-centric emergent process defined by the end user. In SORCER, a rectified contextion – a service request embedded into a service provider container, becomes a service providlet – a process expression becomes an executable service provider.
To express emergent processes consistently and flexibly, the actualization of SML by SOS is based on three pillars of services orientation (contextion, multifidelity, and multityping) and on generalization of the pillars of functional, procedural, and object-orient programming (see Fig. 1). Generalization of the existing programming paradigms leads to five types of service combinations (pipeline, assembly, collaboration, discipline, and governance). Request services are multifidelity services, but provider services are multitype services. By multitypes of service signatures used in contextions a multimultitype of service cooperation is determined. Therefore, multitype of a signature and a multi-multitype of contextions are classifiers of instances of service providers (providlets) and cooperations of service providers in the network, respec-tively. To the best of our knowledge there is no comparable true service-oriented system, programming language based the three pillars of service-orientation and its SVM.
Emergent systems exhibit three types of adaptivities called system-of-systems (metasystem), system, and service agilities. Metasystem agility refers to updating metafidelities (system reinstantiation), system agility refers to updating fidelities of a mogram (system projection), and service agility refers to selecting fidelity of request and opservices.
The SORCER architectural approach represents five types of net-centric multifidelity service cooperations expressed by request services created by the end users and executable codes of service providers by software developers. It elevates combination of contextions into the first-class elements of the SO federated process expression. The essence of the approach is that by making specific choices in grouping hierarchically provider services for contextions, we can obtain desirable dynamic properties from the SO systems we create with SML. The first rule of service-orientation in SORCER: do not morph and do not distribute your system until you have an observable reason to do so. First develop the sys-tem with no fidelities and no remote services. Later introduce must-have distribution and multifidelities. Doing so step-by-step you will avoid the complexity of modeling with multifidelities and distribution all at the same time.
Thinking more explicitly about SO languages, as domain specific languages for humans than software languages for computers, may be our best tool for dealing with real world complexity. Understanding the principles that run across process expressions in SML and appreciating which language features and computing machines (SVM) are best suited for which type of processes, bring these process expressions (request services in SML) to useful life. No matter how complex and polished the individual process operations are, it is often the quality of the operating system (SORCER) that determines the power of the computing system. The ability of pre-sented metamodeling architecture with SML and SVM with its execution engine to leverage network resources as services is significant to real-world applications in two ways. First, it supports multi machine executable codes via opservices that may be required by SO applications; second, it enables cooperation of variety of computing resources represented by request services that comprise of opservices actualized by the multi machine network at runtime.