SORCER Computing Platform

Federated Service Architecture (FSA) is a service-oriented model of the coordinated computing and exchange of information which is organized by service providers, which are describing common concepts and behavior. The approach allows for interoperability and information sharing between locally and/or remotely distributed autonomous services.

This is an approach to model front-end services created by end-users; not by software engineers for building back-end multitier client/server distributed applications. End users, using service-oriented (SO) terms and rules, create for each service request own domain-specific model of coordinated computing and exchange of information. A federated service model is executable by a collaborative service federation, so each service request (model) can be a new application created at runtime as a federation of dynamically provisioned and managed local/remote autonomic service providers. Front-end service models can be also deployed as-is as back-end service providers. As expected, front-end and back-end services adhere to the corresponding metamodel-model relationship by using established interface types (the abstract layer) and classes (instances of implementation) for service-oriented semantics.

Two domain-specific languages (DSLs) are used in SORCER to create service models and programs, Context Modeling Language (CML), and Exertion-Oriented Language (EOL), respectively.

Both languages combined constitute the Service Modeling language (SML) that is used to express information or knowledge about front-end services using a functional structure defined by a consistent set of operators and rules. The rules are used for interpretation of the meaning of expressions in the service model called an mograms. SML top-level interfaces declared by SML operators are implemented with the SORCER API as Java reference classes defining the SML mogramming model. SML is a service metamodel highlighting abstract service properties of the real world object-oriented model expressed in UML.

Note that object modeling languages, for example UML, are modeling languages based on a standardized set of symbols and ways of arranging them to model an object oriented software design or system design by software developers and for software developers. SML is a textual and executable modeling language (a graphical form is expected as well) to model a collaborative work of abstract providers specified by service types (no static associations to real world service providers). It uses standardized SO operators accompanied by parameters. Each operator is associated with its SO type and association of related types represented by parameters that in turn are operators or instances of SO types. SML uses a few SO types related to mogramming due to metalevel abstractions sufficient for service modeling only. See for details Context Models and Exertions.

Object modeling languages are designed for software developers (back-end modeling) to create programs for computers in particular service providers that publish their service types used in SML. By contrast SML is designed for the end-users to model their service-oriented requests (front-end-modeling) to share knowledge with other end users. CML can be effectively used with EOL and vice versa by power users who need more control over SO models that can be expended with OO programming using the SORCER API. This type of mogramming refined with OO programming allows for building OO + SO Java-based complex adaptive systems with top-level SO semantics, fine granularity with Java objects, and mogramming scripts called netlets.