Talk:SORCER

paragraph one - Request Updates

Please replace this:

SORCER (Service ORiented Computing EnviRonment), sometimes written asSOCER, is a cloud-based computing platform that integratesapplications such as engineering systems in large complexIT environments.

It is a follow up to the FIPER project which was funded by the National Institute of Standards and Technology Advanced Technology Program. The SORCER program was led by Michael Sobolewski at Texas Tech University through 2009. In 2010, the project spun off into an independent organization with a goal of providing an open source platform.

with this:

SORCER is a distributed computing platform implemented in Java. It allows writing network-programs (called "exertions") that operate on wrapped applications (services) spread across the network. SORCER is often utilized in similar scenarios to those where grids are used (Grid computing) to run parallel tasks.

SORCER's predecessor was called FIPER, which was software for a GE aircraft-engine-design project funded from 1999-2003 by NIST's ATP. SORCER Labs was founded in November 2002 at TTU; SORCER core's source code was made public in 2013 under the open source Apache license. SORCER (and FIPER) were invented primarily by Professor Mike Sobolewski; his work from 1994-2002 at GE, then at TTUthrough 2009, and since then at AFRL, mirrors SORCER's history. Other groups which have made use of SORCER include Beijing Jiaotong University in China, Cranfield University in the United Kingdom, andUlyanovsk State University in Russia.

---

Consensus agreed in section above (paragraph one)

Pawelpacewicz (talk) 14:45, 10 February 2014 (UTC)

paragraph one, Decline#1

Given that this is the WP:LEDE, I am being a bit more picky about an edit than I would for ones which have obtained consensus for the body of the article.

My issues with the proposed text are:

1. It does not define the acronym SORCER in clear text. This is one of the first pieces of information naive readers are looking for when arriving at the article page.

"The service oriented computing environment (SORCER) is a distributed computing platform..."

is probably most appropriate (see MOS#Abbreviations, MOS:ABBR, etc.) [Note lack of capitals]. Leaving the statement of "written as SOCER in some early sources" in a end-note is reasonable (assuming it is not used to a significant degree, which it sounds like is the case).

2. Biographical information about "Professor Mike Sobolewski" should not be in the lede. Unlike academic articles, the value of a Wikipedia article does not rest of the reputation of the principal person. He is clearly very important to SORCER, but this article is about SORCER not Professor Mike Sobolewski.
3. Other acronyms are left undefined (FIPER), or are defined in end notes (ATP) where hyper-links, and in-line definitions (NIST), (TTU) would be more appropriate. The guidelines for acronyms can be found at MOS:ACRO. Acronyms should be defined, or left as only an acronym, depending on the level of use in the general public. To leave it as only an acronym the level of use must be very high (e.g. NATO). For instance, I would do something like the following:

"1999-2003 by the National Institute of Standards and Technology's Advanced Technology Program. SORCER Labs was founded in November 2002 at Texas Tech University (TTU);"

Actually, I would probably not include the NIST or ATP acronyms in that sentence because it makes it not as smooth a read and you are not using NIST or ATP in the rest of the article. There is no need to use or define an acronym which is not used elsewhere. Note: the above sentence does not imply agreement with mentioning SORCER Labs at that point. While it is clear that there is some relationship with SORCER, by that point in the article the relationship is nothas not been stated, only implied. It could be something like:

"In 2002, development of SORCER was transferred to the newly created SORCER Laboratory at Texas Tech University (TTU)."

General issue: The proposed lede feels like it gives too much weight to the history of the development of SORCER. While some history should be in the lede because it is, currently, a significant part of the article, the lead should either be shorter, or put more emphasis on why we should care about SORCER (what it is, what it does, how it is used, why it is used, etc.).

This decline is, of course, just my opinion. Another editor reviewing this request may make the edit.

General comment: You appear to be going to have extensive use of end notes. I would recommend the use of one of the other templates other than {{efn}} because the lowercase letters used by {{efn}} can be confused with back-references from citations. Personally I use {{efn-ua}}. Given a significant use of end notes I would recommend splitting the reference section into "Notes" and "Reference" sections. If you also have general references, than three sections of "Notes", "Citations", and "References". See: (WP:FNNR, H:PREGROUP, Explanatory notes, etc.). I find that having the end-notes in a separate section from citations/references helps readers find such notes when that is what they are looking for.

Makyen (talk) 22:55, 10 February 2014 (UTC)

Uninvolved eyes are very useful things to have. I concur with Makyen's analysis for the route forward. While I could make the edits they suggest I choose not to because I do not wish to edit the article actively. I commend their thinking to those who are active in editing this article. Fiddle Faddle 23:13, 10 February 2014 (UTC)

Wikipedia was giving errors when I was attempting to save my edit and then Firefox crashed. There were a couple of minor changes to the above which did not make it in (they are now made above via inserts and deletes and ignoring some grammar issues).

I should have also said: Under most circumstances for a COI edit request, I would just edit modified changes into the article. In this situation, I would prefer to see modifications hashed out again here on the talk page. Given that a consensus was formed, I do not feel it appropriate for me to make modifications to the proposed, agreed-upon text while putting it into the article. Makyen (talk) 00:02, 11 February 2014 (UTC)

I agree with your suggestions. I propose the following text:

The Service ORiented Computing EnviRonment (SORCER) is a distributed computing platform implemented in Java. It allows writing network-programs (called "exertions") that operate on wrapped applications (services) spread across the network. SORCER is often utilized in similar scenarios to those where grids are used (Grid computing) to run parallel tasks.

SORCER's predecessor was called Federated Intelligent Product Environment (FIPER) which was software for a GE aircraft engine design project funded from 1999-2003 by the National Institute of Standards and Technology's Advanced Technology Program. In 2002, development of SORCER was transferred to the newly created SORCER Laboratory at Texas Tech University (TTU). SORCER core's source code was made public in 2013 under the open source Apache license. SORCER (and FIPER) were invented primarily by Professor Mike Sobolewski; his work from 1994-2002 at GE, then at TTU through 2009, and since then at the U.S. Air Force Research Laboratory (AFRL), mirrors SORCER's history. Other groups which have made use of SORCER include Beijing Jiaotong University in China, Cranfield University in the United Kingdom, and Ulyanovsk State University in Russia.

---

What do you think about this text? I also agree that it might be too much history and too little about the poject itself in the first paragraph but I'm not sure how to rearrange it. Prubach (talk) 13:29, 11 February 2014 (UTC)

To give you a substantive response I really would need to read a significant portion of the discussion that lead up to this wording from the wording that is currently in the article. I will probably not do so until at least into/through the weekend. Frankly, I have not yet decided that I am going get that far into this. I probably will, but it is not certain yet. Don't feel that you need to get the lead frozen prior to anything else. One of the lead's functions is to summarize the article. It is likely that, at a minimum, once the rest of the article evolves the lead will change, at least to some extent.

On a couple of points it is clear that I have not communicated.

A) Wikipedia has an aggressive policy of using sentence case text (see MOS:CAPS). There are few exceptions. In this instance I am specifically thinking about WP:CAPSACRS. In a good number of venues it is normal to capitalize the words which form an acronym in order to more clearly show how the acronym was derived. Within Wikipedia, this is not done. Thus, "The Service ORiented Computing EnviRonment (SORCER)" will always be "The service oriented computing environment (SORCER)" within Wikipedia. Prior to doing much editing here, it was my habit to capitalize as you are doing. Thus, I know that it feels a bit strange not to capitalize in a way to lead the reader to understanding how the acronym was formed.

B) My mentioning the {{efn-ua}} template was not intended to imply that all references should be wrapped by that template. The {{efn-ua}} template is specifically for explanatory notes, not references. References should continue to use the <ref name="xxxxx">{{cite xxxxx|xxxx...}}</ref> syntax (see Wikipedia:Citing sources and the other reference related pages I previously linked).

I have more of a response, but I am basically falling asleep at my keyboard at the moment. I need stop and get some sleep. I do not expect to get back to this until at least into the weekend. Makyen (talk) 12:30, 14 February 2014 (UTC)

paragraph one, rough consensus#2

Hello Makyen, thanks for the help. Your point about removing Sobolewski's name from the lede is fair, but is tied in with your question: "...by that point in the article the relationship is nothas not been stated, only implied." The reason that SORCER/FIPER moved from GE to TTU, is purely because Sobolewski did the exact same thing at the exact same time.  :-)   Project follows professor, is the story here. I've done a minimal rewrite — in which I included Prubach's changes — below to show the facts of how SORCER & FIPER evolved over time, without undue weight.

combined upgrades from Makyen and Prubach, then pushed to mainspace ... this shows the diffs

The service oriented computing environment (SORCER) is a distributed computing platform implemented in Java. It allows writing network-programs (called "exertions") that operate on wrapped applications (services) spread across the network. SORCER is often utilized in similar scenarios to those where grids are used (Grid computing) to run parallel tasks. SORCER's predecessor was the federated intelligent product environment (FIPER), which was software for a GE aircraft-engine-design project funded from 1999-2003 by the National Institute of Standards and Technology's Advanced Technology Program. The project followed the principal investigator, and thus SORCER Labs was founded in November 2002 at Texas Tech University (TTU); SORCER core's source code was made public in 2013 under the open source Apache license. SORCER (and FIPER) were developed invented primarily by Professor Mike Sobolewski; his work from 1994-2002 at GE, then at TTU through 2009, and since then at the United States Air Force Research Laboratory (AFRL), mirrors SORCER's history. Other groups which have made use of SORCER include Beijing Jiaotong University in China, Cranfield University in the United Kingdom, and Ulyanovsk State University in Russia. Notes section, for uncontroversial tidbits (e.g. brief acronym definitions) and WP:ABOUTSELF stuff.

On the separation into footnote-groups, we have four types of things to mess with here:

1. core papers by Sobolewski/Kolonay on the technology (I think we should call this the Bibliography). These were independent peer-reviewed & usually independently edited, but WP:COI.
2. basic helpdocs/tutorials/explanations by NIST & TTU & SorcerSoft.Org & SorcerSoft.Com (aka WP:ABOUTSELF info... prolly called Notes). Only for bland uncontroversial stuff.
3. ancillary papers by China/Russia/Brits/etc, usually a strong focus on applications of the technology. Again, independent peer-review. Sobolewski is a secondary co-author on about half of them.
4. press coverage outside the academic papers, not much for SORCER but there is a little (mostly Chinese and Russian... however, the fork of FIPER now owned by Dassault has decent press-coverage)

The concepts are complicated enough that it will be almost impossible to explain what SORCER actually is, for a general-purpose wikipedia readership, without relying pretty heavily on #2. (And in particular, scientific-engineering papers of #1 and #3 are exceedingly dense with jargon from the aerospace and abstract-computer-science fields, on top of which they have added fifteen-years-worth of FIPER-and-SORCER-specific jargon that is used heavily.) The press coverage is minimal, so does not help much with the jargon-hurdle. Currently, my thinking is that we need at least three groups: Biblography for #1, Notes for #2, and References for #3_and_#4. Does this make sense to you?

  p.s. Yes, it would be nice for the lede to say what SORCER is/does/etc. Yes, the proposed lede is overly-historical. And yes, we are planning to rewrite the entire article, paragraph by paragraph, so there is no worry about the proposed lede being set-in-stone. We will be rewriting it, today, tomorrow, and a month from now or something. We are trying to iterate through the prose until we get a stable article. Right now we have a messy tag-bombed horror-of-confusion. This "consensus" version of the lede is not a final consensus: it is a purposely temporary there-is-consensus-this-is-a-decent-improvement-so-shove-it-to-mainspace lede.  :-)

  I would have long ago put the changes directly into mainspace myself, already, but I wanted to give our friends with SORCER COI some practice at the whole edit-request process. As a bonus, we get additional improvements, thanks to your suggestions. However, you mentioned at one point that you were anxious about making unilateral changes yourself, as part of fulfilling the edit-request, because you worried that you might override consensus. Do not worry, *please* make changes on-the-fly, in the future. Follow the path of beboldo. Nobody will give you trouble; we *want* you to make helpful changes. If you goof, myself or FiddleFaddle or Ahnoneemoos can always fix up the goofs in mainspace ourselves, and of course Prubach or Pawelpacewicz or Mwsobol or the other fine folks can comment here on the article-talkpage (or on my userpage or via email to Ahnoneemoos). We have several interested computer-science folks like Martijn and scope_creep, that would love to help us improve the specifics, but to make it where those folks can be truly productive, methinks we *have* to get the article a bit more stable and less tag-bombed. Thanks for improving wikipedia, it's appreciated. 74.192.84.101 (talk) 11:39, 16 February 2014 (UTC)

paragraph two

hide much older stuff away: AAO#0 and BEOTU#1

AAO#0: Current. Overview. SORCER is a 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. 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. 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. BEOTU#1: Rewrite. Basic Explanation Of Typical Use. SORCER provides a new command-line shell nsh, running on top of Linux or Cygwin. Shell scripts for nsh create web services non-Jini-discoverable-by-default apps which run on the local PC. These script-generated services apps can call each other. The SORCER-runtime underneath nsh connects the scripted-servicesapps together dynamically, both locally to other scripted-apps-or-services on the PC, but also (depending on config-files) remotely across the LAN to back-end scripted-services (these are network-visible Jini-discoverable service-daemons... often themselves implemented as exertions which are then deployed and configured as network-visible) Inside the SORCER environment, every executing nsh script is a service can see all the network-visible services, which can be running on the local PC, or running on a machine across the LAN. Local scripted-servicesapps can act as wrappers around back-end scripted-services. Scripted-servicesapps on the local PC can also provide a service-oriented wrapper which controls existing command-line applications (and their associated data-files). Creating these scripted-servicesapps, and optionally configuring them as network-visible services, is a job for programmers and system administrators, respectively. Once complete, such frameworks implemented on top of the SORCER-runtime are usually controlled by the enduser (often a wing-designer or turbine-engineer or other aerospace-industry personnel) using application-specific DSLs. Engineer-endusers can write straightforward process-definition-expressions, in the form of a non-network-visible scripted-app running on their local PC, and SORCER transparently spreads the process-workload (back-end scripted services called by the local scripted-app) out across the machines on the LAN. Notes

Boy, howdy *this* is a heavy rewrite. My goal here is to explain the DEAD SIMPLE BASIC use case, not all the special/advanced/rare features, we can cover those further down. I've also tried to get rid of all the new words, and use existing concepts. I'm sure I've made some mistakes, please give me your corrections.  :-)   Thanks. 74.192.84.101 (talk) 23:55, 31 December 2013 (UTC)

hide somewhat older stuff away: AAO#1A && AAO#1B

Updated. 74.192.84.101 (talk) 19:24, 16 January 2014 (UTC) These are some additional things which were removed from paragraph one, and therefore might belong in paragraph two (or paragraph three perhaps). From Prubach: AAO#1A: SORCER is a distributed computing platform implemented in Java. SORCER uses the Jini infrastructure to create wrappers and expose functionalities (other applications, native or java libraries etc.) as services. SORCER introduces the front-end service-oriented programming model, where the user writes network-shell-scripts (similar to Bash scripts) that when executed by SORCER's network shell bind dynamically using Jini's discovery and join protocols to services anywhere in the Jini/SORCER network and execute the operations specified in the script on these services. This is different from Unix shell scripts that execute on one machine or on one Cluster_(computing). from 74: AAO#1B: SORCER is a distributed computing platform (in Java), providing network-based Jini-discoverable services (often wrappers around existing applications). Services are programmatically controlled via network-shell scripts ("exertions"), which dynamically bind at runtime to unloaded network-nodes (see distributed operating system) via Jini " joins". Hope this helps. 74.192.84.101 (talk) 21:06, 29 January 2014 (UTC)

Instead of the whole II paragraph I propose:

AAO#2: SORCER is a distributed computing platform (in Java), providing network-based Jini-discoverable services (often wrappers around existing applications). SORCER introduces the front-end service-oriented programming model, where the user writes network-shell scripts ("exertions") which dynamically bind at runtime via Jini joins to services anywhere in the SORCER network and execute the operations specified in the script on these services. SORCER also supports the back-end service oriented programming model (similar to how BPEL composes services on Application servers (back-end)). In SORCER the back-end programming model is realized by network-shell scripts ("exertions") that may be exposed as services. Prubach (talk) 18:23, 10 February 2014 (UTC)

I agree with verion proposed by Prubach. Pawelpacewicz (talk) 13:54, 11 February 2014 (UTC)

Thought on AAO#2. I don't disagree with this version... but I want to take a step back here, and think about our overall goals for the SORCER article. We have three paragraphs we are working on: the lead paragraph#1, overview paragraph#2, and overview paragraph#3. The rewrite suggested at 18:23 above is pretty close to what paragraph#2 which is currently in the article says, but defers DSL and FMI until later. However, it also repeats much of what we already have in the new paragraph#1.

para1A summarization, and aao#0_mainspace, versus aao#2_combo_suggestion. Main change is that DSL and FMI are deferred until later.

Here is the first part of paragraph#1, from the roughConsensus#2 subsection elsewhere on the talkpage. SORCER is a distributed computing platform implemented in Java. It allows writing network-programs (called "exertions") that operate on wrapped applications (services) spread across the network. SORCER is often utilized in similar scenarios to those where grids are used (Grid computing) to run parallel tasks. Here is current-vs-suggested paragraph#2. AAO#0: "Overview" (currently in mainspace). AAO#2: Abstract Architectural Overview (combo-suggestion by Prubach at 18:23). 1 SORCER is a computing platform that allows the end user to 1 SORCER is a distributed computing platform (in Java), 2 program dynamic front-end compound services, called exertions, 2 providing network-based Jini-discoverable services (7A) (see below) 7A (often wrappers around existing applications). 5A The SOS utilizes the service object-orient architecture (SOOA) 5A SORCER introduces the front-end service-oriented programming model, 5B and a federated method invocation. 5B nix 6 The front-end services created by the end users 6 where the user writes network-shell scripts ("exertions") 3 bound at runtime by the SORCER OS (SOS) 3 which dynamically bind at runtime via Jini joins 4A to federations of service providers 4A to services anywhere in the SORCER network 4B 4B and execute the operations specified in the script on these services. 4C 4C SORCER also supports the back-end service oriented programming model 4D 4D (similar to how BPEL composes services on Application servers (back-end)). 4E 4E In SORCER the back-end programming model is realized 4F as new back-end dynamic services. 4F by network-shell scripts ("exertions") that may be exposed as services. 7A are service collaborations of users' applications, tools, and (7A) (see above) 7B utilities with their data and corresponding control strategies. 7B nix 8 The end users in understandable domain specific languages (DSL) 8 nix 9 define only their service-oriented process expressions 9 nix 10A and the SOS makes that process expressions actualized by the 10 nix 10B corresponding dynamic service federations in the network. 11 nix

Frag1 of AAO#2 is almost an exact repeat of the first sentence of frag1 para1.  :-)   I suggest we cut out the duplication. But my primary suggestion is that we need to be more concrete. Waaaaay more concrete. This is an encyclopedia article: we have been abstract description in the lede paragraph. In the overview-section, aka para2 and para3, we must immediately give the readership a firm idea of the stuff that Mayken spoke about. What it is (concretely!), what it does (concretely!), how it is used (concretely!), and why it is used. We already *told* the readership that SORCER is a Java-based distributed computing platform, for writing exertions and wrapping apps. The readership already *knows* that SORCER spreads computation across the network, kinda like grid computing. Now we have to tell them how it all works in detail, at a summarized level.

  This is a tricky balance. It is not like writing an abstract for a scientific paper (that stays too abstract... hence the name!). It is not like writing a marketing blurb for a brochure (that stays too abstract *and* too pufferized). We need to summarize the essence of SORCER, without glossing over the details. This is not a narrative hook, to get the readership more interested in what is to come. This is a cliff-notes readers-digest summation. Once the reader has gotten through para1 para2 para3, they should be able to STOP reading, and be reasonably informed. Distilled conclusions come first, in a wikipedia article. The overview must not start out up in the clouds of fuzzy abstractions. We can cover fuzzy abstractions *later* in the article. Does this make sense?

  Specific problematic sentence. If I had to pick a sentence that needed the most work, it is this one: "SORCER introduces the front-end service-oriented programming model." First, citation needed. Where is the independent peer-reviewed (or at least editorial-board-fact-checked) reference, in which somebody outside GE/TTU/AFRL/SSO/SSC/Engenius/Dassault said, and I quote, "SORCER ***introduces*** the front-end service-oriented programming model"? Because that isn't a neutral claim. That is a promotional claim: that SORCER was the first evah. Such claims must be impeccably sourced, which means, sourced to something outside the SORCER/FIPER research groups and their associated companies/organizations/etc.

  Here is a weaker claim: "SORCER has a programming language called EOL, which is built on Groovy (cf Scala/Clojure/etc — these are all built on the JVM)." Now, we still need a citation, ideally. But this is no longer a promotional claim. Another weaker claim: "SORCER exertions can call back-end services; those back-end services are themselves exertions, which have been configured & deployed as network-visible services." Citations help, but non-promotional. In combination, these two weaker sentences don't add up to the strong claim, because they don't say SORCER was first. But these weaker claims have the advantage of not needing a cite to the head of NASA published in the WSJ. Just as importantly, the "weaker" sentences actually tell the readership more because they are more concrete. The *name* of EOL is mentioned. That EOL is *built* on Groovy is mentioned. The important *factoid* that back-end services are just specially-deployed-n-config'd exertions is conveyed.

  Rewrite. Here is what we have. ((para1A)) SORCER is a distributed computing platform implemented in Java. It allows writing network-programs (called "exertions") that operate on wrapped applications (services) spread across the network. SORCER is often utilized in similar scenarios to those where grids are used (Grid computing) to run parallel tasks. In para2 & para3, we need to *explain* exactly what kind of platform, exactly what kind of Java, the concrete meaning of "exertion", the concrete meaning of "services", and exactly how they are "spread across the network", plus how parallelism is implemented.

BEOTU#2: Basic Explanation Of Typical Use. ((attempt#2 sans DSL && FMI)). SORCER provides a new command-line shell nsh, running on top of Linux or Cygwin. Normally, UNIX shell-scripts can call each other, local apps, and network-visible resources (e.g. via wget). SORCER exertions written for nsh are similar: they create scripts which run on the local PC. Exertions can interact with other local exertions, and can also act as wrappers around local apps. Local exertions are not network-visible (Jini-discoverable) by default, but they can call other back-end network-visible SORCER services. These services are themselves often implemented as exertions, but on the server-machine (the "local" exertions to that server-hardware are then configured and deployed by a sysadmin to make them network-visible SORCER services). The SORCER-runtime underneath nsh connects all these exertions/apps/services together dynamically. Inside the SORCER environment, every executing nsh-based exertion can see all the network-visible services, without special effort by the programmer (contrast with utilizing a remote JSP on a webserver from within a UNIX shell script via wget). For this reason, SORCER is said to implement a service-oriented architecture. Because SORCER hides the details of cross-network shell-scripts, it is also sometimes called the "SORCER [virtual] operating system" in the literature (this is metaphorical: SORCER is not a bare metal bootable operating system, but rather a software platform).

  In the suggested 'AAO#2' at 18:32, we currently just say "Jini-discoverable" and then "service-oriented" and then "network-shell" plus finally "BPEL", but with few concrete details that the readership is likely to already understand. My suggested 'BEOTU#2' rewrite is very different, because the goal is different. So, before we keep rewriting, I'd like to get the goal of para1/para2/para3 worked out here. We already have a three-sentence summary-overview in para1A. Prubach's suggested para2 is an AAO continuation, which gives more details, but stays very much in the abstract realm. I'm urging that instead, we drop immediately to a concrete metaphor that most of the readership will already understand, the "barebones UNIX metaphor" suggested by prof Sobolewski elsewhere on this talkpage. Now, this is not an XOR choice, since we *could* actually do both: para2 AAO, then para3 BEOTU (or vice versa with para2 BEOTU then para3 AAO). Thoughts? TFIW. 74.192.84.101 (talk) 13:48, 16 February 2014 (UTC)

paragraph three

old stuff

Current. SORCER is a 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. Rewrite. Speaking abstractly, SORCER implements a service-oriented model of computation, with an associated standardized programming environment. SORCER can be thought of as a distributed operating system, with a virtual "processor" of sorts; in this metaphor, the entire LAN is seen as the "PC". Individual network-nodes in the LAN are seen as " threads". When an enduser starts a particular scripted-app running on a particular instance of the nsh command-line, this action is communicated to the metaphorically-centralized "operating system" of the SORCER software platform, which acts like a "process scheduler" and assigns "CPU slices" (aka compute time on some network-visible node) to the nsh-invoked-app. Even more abstractly than the hardware-metaphor, SORCER can be thought of as an implementation of a service-oriented architecture, wherein "everything" is a service. Under the everything-a-service-metaphor, scripted-apps running on the local PC are viewed as (potential) services, since they can be configured and deployed as services (without recoding). Back-end network-visible services are, of course, easy to think of as services; they are *also* often implemented simply as scripted-apps (running on a server-machine), albeit already configured to be network-visible to other "services" (including the "potential services" running on the various local PCs in the LAN). "Services" can call other services, either on the same machine or across the network; which *particular* callee is bound to the caller, varies dynamically with compute-load on the various network-nodes (see the hardware-operating-system metaphor above). This phenomenon, wherein an individual service (whether front-end or back-end — it does not matter) can call another set of helper-services in parallel and/or asynchronously, which can "pop up" on any node in the network which has compute-capacity to spare, is called a "federated method invocation" because a federation of abstractly-network-visible helper-services do the work (contrast with Java remote method invocation in which a single helper-service on a single fixed-network-node does the work). Recent research in 2012 has investigated extending SORCER's programming environment to include integrated modelling (network-shell-scripts which have models as well as programs are dubbed "mograms"[www.scirp.org/journal/PaperDownload.aspx?paperID=22393] from model + program). The discipline of writing network-shell-scripts ("exertions") which are executed in the distributed computing environment provided by SORCER has been dubbed "exertion-oriented programming" with the first academic papers on this topic published in 2007 (but as with SORCER itself the roots of exertion-oriented programming can be found in the FIPER predecessor-project). An extension of the Groovy language (which runs on the Java JVM platform) has been implemented, which provides an Exertion Oriented Language, a new programming syntax for writing nsh shell-scripts ("exertions") as an alternative to writing SORCER-apps in Java (and calling the SORCER API). Metaphorically, then, instead of talking about a programmer who writes network-shell-scripts in a JVM language for SORCER's nsh, which can call remote Jini-discoverable network-visible backend services, that dynamically execute on the available compute-nodes anywhere on the LAN, we can instead speak about a mogrammer writing exertions in EOL for the SOS, which performs federated method invocations (and speak of the LAN as a "virtual CPU" for everything-a-service exertion-oriented mogramming techniques). to form a matching collaborative service federation at runtime - a virtual service processor of the SORCER platform.

Uggh. Got pretty bloated. And could use a re-organization. But methinks the key points were covered: SORCER can be thought of in terms of a LAN-as-virtual-CPU-metaphor aka distributed operating system. At the same time, SORCER can be thought of as a bunch of boxen-with-arrows, the "everything is a service" metaphor... which is not *exactly* true, because being a service implies being network-visible, and only properly "deployed & configured" exertion-scripts are actually network visible... but still, the literature uses the everything-a-service metaphor, so we should explain that metaphor to the readership. Once those two abstractions are explained, we can take a stab at explaining the idea of FMI. Finally, we close the loop to the concrete overview given in paragraph two, and explain how the concrete and the abstract are both talking about the same thing: SORCER. Hope this helps, see my modifications to Prubach's proposal for paragraph one for the wiki-markup that will help us to rewrite without getting lost, and without needing to repeat ourselves (*too* much anyhoo). Danke. 74.192.84.101 (talk) 19:24, 16 January 2014 (UTC)

This description is rather big but you really covered the main points and on top of that using well understandable metaphores. I really like this paragraph. I can try to simplify it a bit but I think it would be best if someone without too broad knowledge of SORCER could look at it and polish it.Prubach (talk) 18:31, 10 February 2014 (UTC)

Okay, we need somebody to cut the fat out. Timtrent, TheRedPenOfDoom, Ahnoneemoos... can you folks please edit this suggested stuff below, slicing off excess, and tagging where it is nonsensical? Be harsh, we can take it.  :-)   Also, please go ahead and edit in place. Thanks. p.s. Maybe CorinneSD would like a piece of this, as well? 74.192.84.101 (talk) 15:35, 16 February 2014 (UTC)

para3 is too verbose

Current:

SORCER is a 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.

Suggested rewrite:

Hardware Metaphor: LAN as PC, SORCER as OS. Speaking abstractly, SORCER implements a service-oriented model of computation, with an associated standardized programming environment. SORCER can be thought of as a distributed operating system, with a virtual "processor" of sorts; in this metaphor, the entire LAN is seen as the "PC". Individual network-nodes in the LAN are seen as "threads". When an enduser starts a particular scripted-app running on a particular instance of the nsh command-line, this action is communicated to the metaphorically-centralized "operating system" of the SORCER software platform, which acts like a "process scheduler" and assigns "CPU slices" (aka compute time on some network-visible node) to the nsh-invoked-app.

Computer Science Metaphor: SORCER as SOAA. Even more abstractly than the hardware-metaphor, SORCER can be thought of as an implementation of a service-oriented architecture, wherein "everything" is a service. Under the everything-a-service-metaphor, scripted-apps running on the local PC are viewed as (potential) services, since they can be configured and deployed as services (without recoding). Back-end network-visible services are, of course, easy to think of as services; they are *also* often implemented simply as scripted-apps (running on a server-machine), albeit already configured to be network-visible to other "services" (including the "potential services" running on the various local PCs in the LAN). "Services" can call other services, either on the same machine or across the network; which *particular* callee is bound to the caller, varies dynamically with compute-load on the various network-nodes (see the hardware-operating-system metaphor above).

SORCER as OS begat FMI. This phenomenon, wherein an individual service (whether front-end or back-end — it does not matter) can call another set of helper-services in parallel and/or asynchronously, which can "pop up" on any node in the network which has compute-capacity to spare, is called a "federated method invocation" because a federation of abstractly-network-visible helper-services do the work (contrast with Java remote method invocation in which a single helper-service on a single fixed-network-node does the work).

SORCER as SOAA begat EOP begat EOL. The discipline of writing network-shell-scripts ("exertions") which are executed in the distributed computing environment provided by SORCER has been dubbed "exertion-oriented programming" with the first academic papers on this topic published in 2007 (but as with SORCER itself the roots of exertion-oriented programming can be found in the FIPER predecessor-project). As an alternative to writing SORCER-apps in Java (and calling the SORCER API), an extension of Groovy (programming language) (which runs on the JVM platform) has been implemented, called the Exertion Oriented Language, a new programming syntax for writing nsh shell-scripts ("exertions"). Recent research in 2012 has investigated extending SORCER's programming environment to include integrated modelling (network-shell-scripts which have models as well as programs are dubbed "mograms"[www.scirp.org/journal/PaperDownload.aspx?paperID=22393] from model + program).

Conclusion: what the neologisms mean, in a nutshell. Normally, we would speak of

a programmer writing network-shell-scripts in a JVM language for SORCER's nsh,
which then call remote Jini-discoverable network-visible backend services that dynamically execute on the available compute-nodes anywhere on the LAN.

Metaphorically, we can simultaneously speak of

a mogrammer writing exertions in EOL for the SOS,
which performs FMIs.

To achieve this simplification, we (metaphorically) think of the LAN as a "virtual CPU" which is utilized via everything-a-service exertion-oriented mogramming techniques. All distributed programming systems involve the use of remote computation-resources on remote nodes; the SORCER platform is intended to make service-instantiation and node-assignments happen on-the-fly. Services and nodes are collaboratively harnessed into a working dynamically-generated set of computational resources, without the programmer of the individual network-shell-script on a local PC needing to do much more than declaratively specify what computation they want to happen.

(( Please edit the above in place, to cut out the fat. Danke. 74.192.84.101 (talk) 15:35, 16 February 2014 (UTC) ))

I have read (that is, tried to read) all the material in this section of the Talk page. Since I know nothing about computer programming, this sounds almost like another language to me. I just made a few edits to the first two paragraphs of the article. All I can do is improve sentence structure and cut out (or suggest cutting out) unnecessary or repetitive words, of course making an effort not to change meaning. 74, I see your note just above, "Please edit the above in place, to cut out the fat." When you say, "the above", do you mean only the paragraph just above your comment, or all of the paragraphs in this section above your comment, or only the first paragraph ("Current" version)? When you say "in place", I guess you mean here on the Talk page.

I have a few questions about the second paragraph in the article:

1) The line, "the program followed the investigator", is not clear to me (an average non-technically minded person). Who was the investigator? Was it a person or a group? Did that person or group move? From where to where, and why? What, exactly, is meant by "the program followed"? If the first questions are made clear, then I guess this will become clearer.

2) The material in this sentence:

"SORCER (and FIPER) were developed at GE from 1994-2002, at TTU through 2009, and since then at the United States Air Force Research Laboratory (AFRL)."

seems to me to be either repetitive (since these organizations and similar dates were mentioned earlier in the paragraph) or unnecessary. If there is something in this sentence that is really important, perhaps some consolidation could be done with the earlier material; that would reduce the number of words in the paragraph. I'll take a look now at the third paragraph.CorinneSD (talk) 18:01, 16 February 2014 (UTC)

While I'm waiting to find out exactly which paragraph (above) you would like me to look at, I just thought I'd point out something which you have probably already seen: in the first paragraph in "Overview", "federated" is a red link, but in the material just above here on the Talk page under "SORCER as OS begant FMI", it is a blue link.CorinneSD (talk) 18:10, 16 February 2014 (UTC)