SORCER: Difference between revisions
Juliancolton (talk | contribs) Wikipedia:Articles for deletion/SORCER closed as no consensus |
according to suggestion: "This article is in a list format that may be better presented using prose." - list format in History and Features sections were changed to prose. |
||
| Line 169: | Line 169: | ||
== Features == |
== Features == |
||
SORCER is built on the concept that everything is a service. (Everything anytime anywhere as a Service (EaaaS)). That includes front-end services (process expressions - called exertions - that define the requested interactions of services) and back-end services (process actualizations-federations of service providers that execute the process expressions). SORCER introduces service variables (vars) with multifidelity evaluations and the related var-oriented modeling paradigm. It unifies many programming styles (procedural, functional, block-structured, and workflow-structured) with var-oriented modeling into the service-oriented mogramming (programming or modeling or both) environment with a matching operating system and a federated virtual service processor. |
|||
The front-end mogramming model introduced in SORCER may be used with services that are deployed both as a direct result of the execution of a request (front-end deployment) or may be started like servers in the network (back-end deployment). To cope with load balancing and reliability issues SORCER uses self-balanced space computing (see [[Tuple Spaces]]) for exertions with transactional semantics (see [[Transaction processing]]) as a way to parallelize the execution of complex tasks. The end user may define different coordination algorithms (synchronous or asynchronous) or select different deployment strategies (autonomic provisioning/unprovisioning) for each part of the computing process (each exertion). |
|||
*Introduction of a service variable (var) with multifidelity evaluation and related var-orineted modeling |
|||
To address interoperability problems at the level of data inputs and outputs for services, SORCER introduces a uniform service context across service federations. Services are context-aware and select the data elements appropriate for them from the uniform service context. Another important interoperability aspect is that in SORCER the network transport protocols are not fixed (as opposed to, i.e. traditional [[Service-oriented architecture|SOA]] which is based mostly on [[WSDL]]/[[SOAP]]) and may be configured at deployment time individually for every service provider |
|||
*Unification of programming styles (procedural, functional, block-structured, and workflow-structured) with var-oriented modeling into the service-oriented mogramming (programming or modeling or both) environment with a matching operating system and a federated virtual processor. |
|||
*The front-end mogramming with the capability of both back and front-end service provider deployment; |
|||
By using the [[Jini|Jini’s]] [[Service-object-oriented architecture|Service-object-oriented architecture (SOOA)]] SORCER has a number of self-healing mechanisms (network discovery/join protocols and dynamic lookup services) and its services inherit the following features: smart proxying – this enables balancing execution of business logic between service requestors and providers; fat proxying allows for running the provider’s code completely at the requestor side . Also, [[Jini]] enables SORCER services code mobility across federations using the behavioral transfer between requestors and providers. |
|||
*Ease of parallelization with self-balanced space computing for exertions with transactional semantics, |
|||
| ⚫ | |||
*Front-end selection of mixed synchronous and asynchronous execution of service federations; |
|||
SORCER follows up on the [http://jazz.nist.gov/atpcf/prjbriefs/prjbrief.cfm?ProjectNumber=99-01-3079 FIPER project] (1999-2003) - funded by [http://www.nist.gov NIST] Advanced Technology Program ($21.5 million). The FIPER software environment was developed and demonstrated at the [[GE Global Research]] Center (Chief architect and lead developer was M. Sobolewski) in collaboration with GE Aircraft Engines (Cincinnati, OH), Goodrich Corp. Aerostructures Group (Chula Vista, CA), Parker Hannifin Corporation (Mentor, OH), Engineous Software, Inc. (Cary, NC) and Ohio University (Athens, OH). When the project was finished M. Sobolewski established the [http://sorcersoft.org SORCER Laboratory] at [[Texas Tech University]] (2002-2009) where he continued his FIPER-based research. The SORCER Laboratory was partially funded by [[General Electric]], [[Texas Tech University]], [[Sun Microsystems]], [[Air Force Research Laboratory]], and others. During that time 28 graduate [http://sorcersoft.org/theses/index.html research studies] (M.S. and Ph.D.) were completed all of which contributed to the development of the SORCER platform and the foundations of federated service-oriented computing. In the meantime, a number of collaborative SORCER-based projects (2007-2010) were realized together with universities from other countries ([[Beijing Jiaotong University]], [[China]]; [[Beihang University]], [[China]]; [[Ulyanovsk State University]], [[Russia]]). |
|||
| ⚫ | Since 2008 M. Sobolewski continues his SORCER applied research at the Multidisciplinary Science and Technology Center, [[Air Force Research Laboratory]]/WPAFB and starting in 2010 simultaneously at the <!-- [[Polsko-Japońska Wyższa Szkoła Technik Komputerowych w Warszawie|Polish Japanese Institute of IT]] --> [http://www.pjwstk.edu.pl/?kat=239 Polish Japanese Institute of Information Technology]. In 2010 the [http://sorcersoft.org SORCER Laboratory] became an independent research organization focused on the development federated service-oriented computing. |
||
*Front-end (on-demand) autonomic service provider provisioning/unprovisioning; |
|||
| ⚫ | |||
*Context awareness of the service-oriented computing with service context-based interoperability across service federations; and |
|||
*Location/implementation neutrality, but most importantly wire protocol neutrality and transport protocol selection at service deployment (transport endpoints); |
|||
*Smart proxying for balancing execution of business logic between service requestors and providers, with fat proxying for running the provider’s code completely at the requestor side; |
|||
*Code mobility across service federations – dynamic behavioral transfer between requestors and providers; and |
|||
*A self-healing runtime environment using [https://en.wikipedia.org/wiki/Jini Jini] network discovery/join protocols and dynamic lookup services. SORCER is build on top of Jini's [[Service-object-oriented architecture|Service-object-oriented architecture (SOOA)]] |
|||
| ⚫ | |||
*The [http://jazz.nist.gov/atpcf/prjbriefs/prjbrief.cfm?ProjectNumber=99-01-3079 FIPER project] (1999-2003) - funded by [http://www.nist.gov NIST] Advanced Technology Program, $21.5 million. The FIPER software environment developed and demonstrated at [[GE Global Research]] Center (Chief architect and lead developer: M. Sobolewski) in collaboration with GE Aircraft Engines (Cincinnati, OH), Goodrich Corp. Aerostructures Group (Chula Vista, CA), Parker Hannifin Corporation (Mentor, OH), Engineous Software, Inc. (Cary, NC), Ohio University (Athens, OH). |
|||
*M. Sobolewski established the [http://sorcersoft.org SORCER Laboratory] at [[Texas Tech University]] (2002-2009) to continue his FIPER-based research funded by [[General Electric]], [[Texas Tech University]], [[Sun Microsystems]], [[Air Force Research Laboratory]], and others). 25 graduate [http://sorcersoft.org/theses/index.html research studies] completed to support the development of the SORCER platform and foundations of federated service-oriented computing. |
|||
*Collaborative SORCER-based projects (2007-2010) with [[Beijing Jiaotong University]], [[China]]; [[Beihang University]], [[China]]; and [[Ulyanovsk State University]], [[Russia]]. |
|||
| ⚫ | |||
*From 2010 the [http://sorcersoft.org SORCER Laboratory] becomes the independent research organization focused on federated service-oriented computing. |
|||
| ⚫ | |||
== References == |
== References == |
||
Revision as of 08:23, 4 December 2013
 | This article has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these template messages)
|
| Working state | Current |
|---|---|
| Source model | Free and open source software with proprietary components |
| Initial release | 2003 |
| Latest release | 1.0-M2 / 24 July 2013 |
| Repository | |
| License | Apache License |
| Official website | sorcersoft |
SORCER (stands for Service ORiented Computing EnviRonment) is a computing platform that integrates various applications (i.e engineering systems) from various vendors, in large complex IT environments into one dynamically manageable cloud of services. With Java as the primary back-end language for implementing service providers, SORCER delivers front-end programming languages that enable the end users to flexibly realize interactions of services available within these SORCER service clouds. Allowing to create compound services on-the-fly with front-end programming SORCER makes it easy to manage complexity of modern challenges (i.e. air vehicle design).
Overview
SORCER is a federated service-oriented computing platform that allows the end user to program dynamic front-end compound services, called exertions, bound at runtime by the SORCER OS (SOS) to federations of service providers as new back-end dynamic services. The SOS utilizes the service object-orient architecture (SOOA) and a federated method invocation.[1] The front-end services created by the end users are service collaborations of users' applications, tools, and utilities with their data and corresponding control strategies, all seamlessly collaborating in the network. [2]The end users in understandable domain specific languages (DSL) define only their service-oriented process expressions and the SOS makes that process expressions actualized by the corresponding dynamic service federations in the network.
Computing requires a platform (runtime system) to operate. Computing platforms that allow programs to run require a processor, operating system, and programming environment that allow creation of symbolic process expressions. SORCER is a well-defined federated service-oriented platform with a front-end federated service-oriented programming environment, a matching operating system, and a federated virtual processor. The architecture of SORCER is based on the concept: Everything Anywhere Anytime As a Service (EaaaS). Therefore the end user service requests (front-end expression) as well service providers (back-end federations) are treated as services. SORCER is the first platform that created front-end service-oriented mogramming (programming or modeling or both) as the key element of its federated service orientation. SORCER mograms are called exertions. The exertion-oriented programming has its roots in the FIPER project. An exertion as the front-end service composition defined by the user is bound by the SORCER OS (SOS) to service providers (local and/or remote) to form a matching collaborative service federation at runtime - a virtual service processor of the SORCER platform.
Exertions represent front-end "services" that are hierarchically organized with data contexts (attributes that describe the service data), control contexts (attributes that describe the service control strategy), and associated service providers' signatures based on service types (local-Java classes or remote-interfaces). The associated signatures are bound to service providers to collaborate according to control strategies imposed by exertion's control contexts to process data contexts of the service federation created at runtime by the SOS. SORCER is the first system enabling front-end service-oriented programming with the relevant operating system and dynamic back-end service federations as its virtual processor.
SORCER Operating System
The SORCER operating System (SOS) manages execution of front-end service-oriented mograms and related resources including required service providers. The SOOA kernel by itself is the service-oriented system made up of system service providers architecturally equivalent to domain specific service providers. A service provider is a container for service beans that is responsible for deploying services in the network, publishing their proxies to registries, and allowing the SOS to access proxies of deployed providers. Providers maintain their availability in the network continuously by renewing leases for their registered object proxies; registries intercept these announcements and cache/remove proxy objects per providers’ requests. The SOS looks up proxies by sending queries to registries and making selections from the currently available providers or provisions on-demnad required ones. Queries generally contain search criteria related to the type and quality of service. Registries facilitate searching by storing proxy objects of services and making them available to the SOS. Providers use discovery/join protocols to publish services in the network and the SOS uses discovery/join protocols to discover registries and lookup proxies in those registries.
Use
The basic exertion-oriented platform was developed at GE Global Research Center with the partners of the FIPER project (1999-2003). FIPER was used at that time to design aircraft engines[3] [4] .[5] The Multidisciplinary Science and Technology Center, the United States Air Force Research Laboratory/WPAFB is using and developing SORCER to address the physics-based distributed collaborative design for aerospace vehicle development[6] [7] .[8] In China for example SORCER is used as noise mapping platform for urban traffic,[9] a resource integration platform ,[10] engineering collaborative design environment,[11] and at the Wright State Unversity as a collaborative computational framework for multidisciplinary and reliability-based analysis and optimization.[12]
Features
SORCER is built on the concept that everything is a service. (Everything anytime anywhere as a Service (EaaaS)). That includes front-end services (process expressions - called exertions - that define the requested interactions of services) and back-end services (process actualizations-federations of service providers that execute the process expressions). SORCER introduces service variables (vars) with multifidelity evaluations and the related var-oriented modeling paradigm. It unifies many programming styles (procedural, functional, block-structured, and workflow-structured) with var-oriented modeling into the service-oriented mogramming (programming or modeling or both) environment with a matching operating system and a federated virtual service processor.
The front-end mogramming model introduced in SORCER may be used with services that are deployed both as a direct result of the execution of a request (front-end deployment) or may be started like servers in the network (back-end deployment). To cope with load balancing and reliability issues SORCER uses self-balanced space computing (see Tuple Spaces) for exertions with transactional semantics (see Transaction processing) as a way to parallelize the execution of complex tasks. The end user may define different coordination algorithms (synchronous or asynchronous) or select different deployment strategies (autonomic provisioning/unprovisioning) for each part of the computing process (each exertion).
To address interoperability problems at the level of data inputs and outputs for services, SORCER introduces a uniform service context across service federations. Services are context-aware and select the data elements appropriate for them from the uniform service context. Another important interoperability aspect is that in SORCER the network transport protocols are not fixed (as opposed to, i.e. traditional SOA which is based mostly on WSDL/SOAP) and may be configured at deployment time individually for every service provider
By using the Jini’s Service-object-oriented architecture (SOOA) SORCER has a number of self-healing mechanisms (network discovery/join protocols and dynamic lookup services) and its services inherit the following features: smart proxying – this enables balancing execution of business logic between service requestors and providers; fat proxying allows for running the provider’s code completely at the requestor side . Also, Jini enables SORCER services code mobility across federations using the behavioral transfer between requestors and providers.
History
SORCER follows up on the FIPER project (1999-2003) - funded by NIST Advanced Technology Program ($21.5 million). The FIPER software environment was developed and demonstrated at the GE Global Research Center (Chief architect and lead developer was M. Sobolewski) in collaboration with GE Aircraft Engines (Cincinnati, OH), Goodrich Corp. Aerostructures Group (Chula Vista, CA), Parker Hannifin Corporation (Mentor, OH), Engineous Software, Inc. (Cary, NC) and Ohio University (Athens, OH). When the project was finished M. Sobolewski established the SORCER Laboratory at Texas Tech University (2002-2009) where he continued his FIPER-based research. The SORCER Laboratory was partially funded by General Electric, Texas Tech University, Sun Microsystems, Air Force Research Laboratory, and others. During that time 28 graduate research studies (M.S. and Ph.D.) were completed all of which contributed to the development of the SORCER platform and the foundations of federated service-oriented computing. In the meantime, a number of collaborative SORCER-based projects (2007-2010) were realized together with universities from other countries (Beijing Jiaotong University, China; Beihang University, China; Ulyanovsk State University, Russia).
Since 2008 M. Sobolewski continues his SORCER applied research at the Multidisciplinary Science and Technology Center, Air Force Research Laboratory/WPAFB and starting in 2010 simultaneously at the Polish Japanese Institute of Information Technology. In 2010 the SORCER Laboratory became an independent research organization focused on the development federated service-oriented computing.
Since 2013 the development of SORCER is continued simultaneously by Sorcersoft.com in cooperation with the Polish-Japanese Institute of Information Technology and SMT Software.
References
- ^ Sobolewski, Michael (2009). Metacomputing with Federated Method Invocation. In-Tech, intechweb.org. pp. 337–363. ISBN 978-953-7619-51-0. Retrieved 2010-01-27.
{{cite book}}: Unknown parameter|booktitle=ignored (help); Unknown parameter|editors=ignored (|editor=suggested) (help) - ^ Thompson, Ernest D (2012). "University of Dayton, 2012". University of Dayton: 230–241.
{{cite journal}}:|chapter=ignored (help); Cite journal requires|journal=(help); External link in|chapterurl=|chapterurl=ignored (|chapter-url=suggested) (help) - ^ Seeley, C.E. (2001). "Multidisciplinary analysis and optimization of combustion sub-system using a network-centric approach". 42nd AIAA/ASME/ASCE/AHS/ASC Structures, Structural Dynamics, and Materials Conference AIAA-2001-1270. American Institute of Aeronautics and Astronautics. doi:10.2514/6.2001-1270.
{{cite book}}:|access-date=requires|url=(help); External link in|chapterurl=|chapterurl=ignored (|chapter-url=suggested) (help); Unknown parameter|coauthors=ignored (|author=suggested) (help) - ^ Tappeta, R.V. (2002). "Application of Approximate Optimization to Turbine Blade Design in a Network-Centric Environment". 43rd AIAA/ASME/ASCE/AHS/ASC Structures, Structural Dynamics and Materials Conference AIAA-2002-1588. American Institute of Aeronautics and Astronautics. doi:10.2514/6.2002-1588.
{{cite book}}:|access-date=requires|url=(help); External link in|chapterurl=|chapterurl=ignored (|chapter-url=suggested) (help); Unknown parameter|coauthors=ignored (|author=suggested) (help) - ^ Liao, Li (2004). "2D/3D CFD Design Optimization Using the Federated Intelligent Product Environment (FIPER) Technology". 9th AIAA/ISSMO Symposium on Multidisciplinary Analysis and Optimization AIAA-2002-5479. IAIAA. doi:10.2514/6.2004-1847.
{{cite book}}:|access-date=requires|url=(help); External link in|chapterurl=|chapterurl=ignored (|chapter-url=suggested) (help); Unknown parameter|coauthors=ignored (|author=suggested) (help) - ^ Kolonay, Raymond (2004). "Object Models for Distributed Multidisciplinary Analysis and Optimization (MAO) Environments that Promotes CAE Interoperability". 10th AIAA/ISSMO Multidisciplinary Analysis and Optimization Conference AIAA 2004-4599. AIAA. doi:10.2514/6.2004-4599.
{{cite book}}:|access-date=requires|url=(help); External link in|chapterurl=|chapterurl=ignored (|chapter-url=suggested) (help); Unknown parameter|coauthors=ignored (|author=suggested) (help) - ^ Kolonay, Raymond (2013). "Physics-Based Distributed Collaborative Design for Aerospace Vehicle Development and Technology Assessment". Proceedings of the 20th ISPE International Conference on Concurrent Engineering. IOS Press. pp. 381–390. ISBN 978-1-61499-301-8.
{{cite book}}:|access-date=requires|url=(help); External link in|chapterurl=|chapterurl=ignored (|chapter-url=suggested) (help); Unknown parameter|editors=ignored (|editor=suggested) (help) - ^ Scott A., Burton (2012). "Efficient Supersonic Air Vehicle Analysis and Optimization Implementation using SORCER". 12th AIAA Aviation Technology, Integration, and Operations (ATIO) Conference and 14th AIAA/ISSM, AIAA 2012-5520. AIAA. pp. 381–390.
{{cite book}}:|access-date=requires|url=(help); External link in|chapterurl=|chapterurl=ignored (|chapter-url=suggested) (help); Unknown parameter|coauthors=ignored (|author=suggested) (help) - ^ Li, Nan (2011). "A SOOA Based Distributed Computing Mechanism for Road Traffic Noise Mapping". IEEE Computer Society Washington, DC, USA: 109–112. ISBN 978-0-7695-4455-7.
{{cite journal}}:|chapter=ignored (help); Cite journal requires|journal=(help); External link in|chapterurl=|chapterurl=ignored (|chapter-url=suggested) (help); Unknown parameter|coauthors=ignored (|author=suggested) (help) - ^ Lingjun, Kong (2011). "Electronic and Mechanical Engineering and Information Technology (EMEIT), 2011 International Conference on (Volume:3 )": 1466–1469. ISBN 978-1-61284-087-1.
{{cite journal}}:|chapter=ignored (help); Cite journal requires|journal=(help); External link in|chapterurl=|chapterurl=ignored (|chapter-url=suggested) (help); Unknown parameter|coauthors=ignored (|author=suggested) (help) - ^ ZHANG, Rui-hong (2008). "Engineering Collaborative Design Environment Based on Service-oriented Architecture". JOURNAL OF HEBEI UNIVERSITY OF TECHNOLOGY, Vol.37 No.4. pp. = 40–44.
{{cite book}}:|access-date=requires|url=(help); External link in|chapterurl=|chapterurl=ignored (|chapter-url=suggested) (help); Unknown parameter|coauthors=ignored (|author=suggested) (help)CS1 maint: extra punctuation (link) - ^ Aithala, Karkada Nagesha (2011). "Wright State University, 2011". Wright State University.
{{cite journal}}:|chapter=ignored (help); Cite journal requires|journal=(help); External link in|chapterurl=|chapterurl=ignored (|chapter-url=suggested) (help)