From Wikipedia, the free encyclopedia
Jump to: navigation, search

Selective manual archiving has a consensus[edit]

To reduce clutter here, we manually archived all discussions, some of which may still have been active. Please see "Archive 1" over to the righthand side, to view the previous info. Feel free to open a new section here, if you want to discuss something in the archives further (don't edit the "Archive 1" contents directly though... too confusing!). I've already copied the sourcing-and-tone sections from the archives, see below. (talk) 18:02, 30 December 2013 (UTC)

Makyen has just added an automatic archiving scheme to this talk page. I have, however, reverted that addition for two reasons:
  1. The talk page as it stands is being used to reconstruct the article, and all material on it currently is germane to that reconstruction. Auto-archiving by date is inappropriate at this stage in the article's life.
  2. Addition of automatic archiving requires a demonstrable consensus to be built. That has not yet been performed.
My feelings are that the talk page should be considered for autoarchiving, but probably not before April 2014 in order to give sufficient time for much of the reconstruction to be performed. After that time it seems to me to be sensible to consider an auto-archiving scheme, but with full consensus for:
  • Doing it at all
  • number of threads to be left
  • number of days of inactivity on a thread prior to archival
It is worth considering whether, post reconstruction, this talk page will see much activity anyway. When an article is 95% complete then discussion tends to cease. I feel that is a discussion best held when the article is 95% complete, but your opinion may differ. Fiddle Faddle 10:58, 2 February 2014 (UTC)

notability and sourcing[edit]

Worthwhile reading — WP:42 is the answer to most questions about new articles, in the wikiverse (gratitude to TRPoD for this link). Summary of the sources-list below is basically....

  1. DoD, the multiyear multi-million-dollar supergrants by the USAF+NIST and NSFChina (plus hints of Ulyanovsk) ... and the classified weaponized-aerospace work these indicate. Such work is not useful as RS now, today, because WP:V demands the info be *published* aka available to the public... and wikiLeaks doesn't count as RS methinks... or does it? Hmmmm. Point is, this stuffwill be declassified someday. And it exists now, today. We cannot *use* it today, for sourcing the article, but that doesn't mean we have to pretend this set of classified sources, published-yet-top-secret, doesn't exist — when evaluating the public sources below, it can lend some perspective to what they don't say.
  2. UK, the 2007 U.Cranfield lit-review & industry-survey (a solid secondary source), plus the 2009 G.Goteng PhD from same place. WP:SOURCES sez, "academic peer-reviewed pub's are usu the most RS". WP:SCHOLARSHIP sez, "PhD [theses]...can be used but care should be exercised".
  3. RU, the 2007/YYYY/2013 newspaper articles in Russian (I've asked somebody who "can read a few words of Russian" to give us rough assessment of depth... anybody amongst us here know Cyrillic?)
  4. ZH, the 2010 PhD and 3+ peer-reviewed journal articles by Nan Li (most of the work in Chinese but that is no hindrance to wikiNotability though it is a barrier to gauging depth... Clover1991 of DUROMAC fame has offered to help us with translating the mandarin if kazumo is busy), plus the 2011 and 2013 Beijing Jiaotong University PhD (students of Nan methinks?); *maybe* the ZH edu-news section; additional evidence, tho not themselves RS, are the two Master's theses. Again WP:SOURCES and WP:SCHOLARSHIP
  5. US, the 2013 iosPress/AFRL papers (peer-reviewed by the 20 members of the conf-board and the 3 members of the editorial-subset which were mostly Aussies), plus the 2012 DaytonThesis PhD (which has a public-domain chapter on SORCER beginning on page 230... decent tone... might be the best place to start on the rewrite of mainspace?); additional evidence, tho not itself RS, is the WrightState Master's. SorcerDotCom in Poland, and SorcerSoftDotOrg at TTU in Texas, are the entities directly responsible for SORCER; the USAF and WPAFB are funding Prof.Sobolewski, U.Dayton, WrightSt.U, and various other stuff via the MSTC/AFRL folks in Ohio.

Meanwhile, as Tim and ScopeCreep and TRPoD and Garamond and others are analyzing whether this list of sources is bulletproof wikiNotability, safe from all future deletion-attempts, Pawelpacewicz and Martijn and Prubach and myself can try to start working on WP:TONE, and on clearly explaining the meaning of SORCER/nsh/exertions/mograms/SOOA/COLA/PEPSI/7UP/etc to the readership.

Fiddle Faddle's suggestion "that the first task is to show and prove notability though" ... there is one, and only one, way to prove wikiNotability. That is, namely, to find multiple independent Reliable Sources, which cover SORCER itself (specifically), in some amount of depth. Finding good sources, and proving wikiNotability, are the same thing. Nothing more is required, but also, nothing less is required. There is a difference between a *secondary* source, and an *independent* source. If anyone finds independent sources, fact-checked by an independent journalist's professional editorial board, or peer-reviewed by independent referees at some journal's science-board, please add them to the list below. Thanks for improving wikipedia. (talk) 18:02, 30 December 2013 (UTC)

The second AfD ended well, with a 'keep' rather than the wishy-washy 'no consensus' that we had the first time. That doesn't mean we are done organizing sources, however! It is important for wikipedia to reflect wat the wikiReliable Sources say, see WP:UNDUE. So please, keep adding sources to this listing, appropriately categorized, as you find them. Thanks for improving wikipedia, it's appreciated. (talk) 19:24, 16 January 2014 (UTC)


notability and sourcing, further discussion thereof[edit]

Commentary goes here please, use the shortname of the source in the list above (if such is yet specified). (talk) 18:02, 30 December 2013 (UTC)

Here are the key authors that work on SORCER/FIPER in the academic world, as opposed to the classified world. Cite-counts of top three papers are raw google-scholar-figures (not checked!).

  1. '00-12 w/43+36+24 cites from best papers == M Sobolewski (plus five co-authors on some of his more-recent less-cited papers ... SORCER/FIPER is the topic)
  2. '00-11 w/74+39+24 cites from best papers == RM Kolonay (plus Sobolewski on top-cited papers... plus three co-authors on some of his more-recent less-cited papers ... collaborative CAD/CAE is the topic)
  3. '03-06 w/67+23+20 cites from best papers == CD Cera (not Kolonay or Sobolewski... plus several co-authors on all papers ... secure collaborative CAD/CAE is the topic)
  4. '05-07 w/64+32+18 cites from best papers == WD Li (not Kolonay or Sobolewski... plus one distinct co-author on each paper ... collaborative product CAD/CAM is the topic)
  5. '03-08 w/27+15+11 cites from best papers == S Goel (plus Sobolewski on all papers ... plus one co-author on most papers ... collaborative CAD/etc secure grid-computing is the topic)
  6. '08-11 w/22+11+05 cites from best papers == J Yu & J Cha (plus Sobolewski on top-cited papers ... plus four co-authors on less-cited papers ... CAE/concurrent engineering is the topic)

("SORCER" OR "FIPER") ("federated" OR (distributed collaborative) OR ("exertion oriented" OR "with exertions") OR "sobolewski" OR "kolonay" OR "rubach" OR "goel" OR "nan li" OR "li nan" OR "li wd" OR "wd li" OR "berger" OR "J Cha" OR "JD Cha")

So, what this tells us is that SORCER/FIPER isn't really a computer science topic, which means that Garamond's analysis that it isn't academically notable in that niche is correct. There *are* a bunch of computer-science-papers, by Sobolewski mostly but also by Berger (the filesystem stuff) and other co-authors... however, those never took off in the world of strict EECS academia. FIPER/SORCER left TTU in 2009, and returned to their roots, working on high-end military-grade aerospace systems, in the distribute-collaborative-secure-CAD/CAE/CAM world.

  SORCER/FIPER is a software system which is used almost exclusively for industrial engineering, mechanical engineering, and especially aerospace engineering. This is a much smaller field that EECS in terms of author-population, and thus, the cite-counts are naturally smaller that Garamond is used to seeing for OOP/LISP/SOAP/etc. Does anybody know someone from NASA/ESA or Lockheed/Dassault or Boeing/Airbus or something, that can give us an idea about whether a dozen papers with 25+ cites, including three or four with 50+ cites (max 74 for the original FIPER report) is wikiNotable in the engineering disciplines? Hope this helps. (talk) 17:15, 3 January 2014 (UTC)

dealing with terminology/jargon/neologisms[edit]

With the neologisms, may I suggest a special reference group named, perhaps neologism where a correct textual explanation is given , but in layman's language. I am sure I've explained this style of scheme to you before, but I only now see the application in this manner. One may have multiple names reference groups in an article. The only caveat is that the associated {{Reflist}}must come after the final instance on the page. Thus one may also have a group named note, another named Dr Pepper, and so forth. Fiddle Faddle 16:09, 29 December 2013 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── The hits on google-scholar gave me some insight into when the various terms first cropped up in the literature.

  1. "SORCER", first mentioned 2003/2004 but counts became much stronger by 2007/2008
  2. "federated method invocation" , 2007/2008
  3. "exertion oriented" OR "with exertions" , first mentioned 2007/2008
  4. "mogram" OR "mogramming" , first mentiond 2011/2012
  5. "FIPER" , first mentioned 2000/2001 but became much stronger by 2004/2005/2006

Only about half of the post-2008 CAE papers mention exertions, or FMI ... and many will mention one but not the other... but they all (in this list anyways) mention SORCER (plus sometimes FIPER). By contrast, 100% of the post-2008 EECS papers mention both exertions and FMI, whenever they mention SORCER. Per the google-scholar-analysis in the talkpage section above, which says the academic-genre FIPER&SORCER belong to is CAE/CAD/CAM rather than EECS qua EECS, plus given the history of when the terms arose, it seems pretty clear to me that the main article should be called SORCER, with FIPER as a large subsection. Wikipedia already has an article on concurrent engineering, but not on distributed CAD nor collaborative CAD; maybe another name for the latter? HTH. (talk) 17:33, 3 January 2014 (UTC)

todo list[edit]

Here are the snark-spams at the top of the article today.

  1. A major contributor to this article appears to have a close connection with its subject. (December 2013)
  2. The topic of this article may not meet Wikipedia's general notability guideline. (December 2013)
  3. This article possibly contains original research. (December 2013)
  4. This article relies on references to primary sources. (December 2013)
  5. This article may contain an excessive amount of intricate detail that may only interest a specific audience. (December 2013)
  6. This article may be too technical for most readers to understand. (December 2013)

Pretty long list.  :-)   There are actually just two basic issues. WP:RS to prove wikiNotability, which is being covered above. WP:TONE, too much jargon, and gotta stay neutral. As we go through the paragraphs, we can start to solve tag#6 and tag#5. (talk) 15:20, 29 December 2013 (UTC)

paragraph one[edit]

  1. SORCER (Service ORiented Computing EnviRonment), sometimes written as SOCER,
  2. is a cloud-based computing platform
  3. that integrates applications such as engineering systems in large complex IT environments.
  4. It is a follow up to the FIPER project
  5. which was funded by the National Institute of Standards and Technology Advanced Technology Program.
  6. The SORCER program was led by Michael Sobolewski at Texas Tech University[1] through 2009.
  7. In 2010, the project spun off into an independent organization with a goal of providing an open source platform.[2]
Sorry folks, I've been swamped. I have made a few tweaks to the wording; I changed "using" into the more vague "which have made use of" ... we can give details of who used/uses SORCER, when, in the body. I also added some grammar-tweaks and some wikilinks. Here is the usual numbered listing:
  1. SORCER[c]
  2. 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.
  3. SORCER is often utilized in similar scenarios to those where grids are used (Grid computing) to run parallel tasks.
  4. SORCER's predecessor was called FIPER, which was software for a GE aircraft-engine-design project
  5. funded from 1999-2003 by NIST's ATP.[d]
  6. SORCER Labs was founded in November 2002 at TTU;[e]
  7. SORCER core's source code was made public in 2013 under the open source Apache license.[f]
  8. 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 AFRL, mirrors SORCER's history.
  9. 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.

  1. ^ SORCER derives from "Service ORiented Computing EnviRonment", written as SOCER in some early sources.
  2. ^ Advanced Technology Program of the National Institute of Standards and Technology.
  3. ^ SORCER derives from "Service ORiented Computing EnviRonment", written as SOCER in some early sources.
  4. ^ Advanced Technology Program of the National Institute of Standards and Technology.
  5. ^ "About SORCER Lab at TTU CS". Retrieved 15 December 2013. 
  6. ^ "About SORCER: Timeline". Retrieved 15 December 2013. 

In order to actually make the edit-request, you should always first de-number, and write it out like this, as a paragraph ready to be pasted by the ERQ person.

Please replace this:

SORCER (Service ORiented Computing EnviRonment), sometimes written as SOCER, is a cloud-based computing platform that integrates applications such as engineering systems in large complex IT 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[1] through 2009. In 2010, the project spun off into an independent organization with a goal of providing an open source platform.[2]

with this:

SORCER[a] 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.[b] SORCER Labs was founded in November 2002 at TTU;[c] SORCER core's source code was made public in 2013 under the open source Apache license.[d] 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 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.

This is good neutral prose, in my book, a big improvement. Specific, sensible, non-controversial. If this looks good to everyone, go ahead and submit the WP:ERQ. Usually I would just push this into mainspace myself, right now, but I'd like to get you used to the procedure.  :-)

  p.s. On the other paragraphs, I suggest working in parallel. Create a section for each paragraph, and folks can attack them as they are ready. We don't have to go 1,2,3,4..., sequentially. We can be like SORCER, and spread the work out across all our nodes. Good work on paragraph one, we will start seeing faster progress now. I will try to get some time free to come back and hammer through myself, but again, don't let me be the bottleneck. Use those edit-requests, and use WP:TEAHOUSE, when you need help getting something cleaned up. Just try not to terrify them with all the SORCER keywords.  :-)   Thanks, and talk to you later; ping my talkpage if you think my elbow needs a little joggle, I won't ever mind. (talk) 21:03, 29 January 2014 (UTC)

Looks good to me - its definitely easier to read for a newbie, let's replace the first paragraph on the main page with the proposed version.Prubach (talk) 17:31, 6 February 2014 (UTC)

paragraph one - Request Updates[edit]

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[1] through 2009. In 2010, the project spun off into an independent organization with a goal of providing an open source platform.[2]

with this:

SORCER[e] 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.[f] SORCER Labs was founded in November 2002 at TTU;[c] SORCER core's source code was made public in 2013 under the open source Apache license.[d] 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.

  1. ^ SORCER derives from "Service ORiented Computing EnviRonment", written as SOCER in some early sources.
  2. ^ Advanced Technology Program of the National Institute of Standards and Technology.
  3. ^ a b "About SORCER Lab at TTU CS". Retrieved 15 December 2013. 
  4. ^ a b "About SORCER: Timeline". Retrieved 15 December 2013. 
  5. ^ SORCER derives from "Service ORiented Computing EnviRonment", written as SOCER in some early sources.
  6. ^ Advanced Technology Program of the National Institute of Standards and Technology.

Consensus agreed in section above (paragraph one)

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

paragraph one, Decline#1[edit]

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)[A] 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).
  1. 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.
  2. 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.

  1. ^ Written as SOCER in some early sources

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)[A] 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).[B] SORCER core's source code was made public in 2013 under the open source Apache license.[C] 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.

  1. ^ Written as SOCER in some early sources
  2. ^ "About SORCER Lab at TTU CS". Retrieved 15 December 2013. 
  3. ^ "About SORCER: Timeline". Retrieved 15 December 2013. 

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[edit]

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: " 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.

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. (talk) 11:39, 16 February 2014 (UTC)

paragraph two[edit]

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. (talk) 23:55, 31 December 2013 (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.

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. (talk) 13:48, 16 February 2014 (UTC)

paragraph three[edit]

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. (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? (talk) 15:35, 16 February 2014 (UTC)

para3 is too verbose[edit]


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"[4] 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. (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)

how many source-code repos are there?[edit]

Questions about the number of forks/repos of the SORCER codebase (plus ancillary codebases surrounding it), which groups used what codebases (historically and recently), which groups contributed *code* as opposed to money/endusers/similar.

  1. SORCER is about grids of distributed algorithms, for concurrent-engineering design-disciplines
  2. SORCER is a huge computing environment, only a fraction of the results related to SORCER have been published
  3. This is partly because some of the apps are classified (military), and partly because some of the apps are proprietary (corporate trade-secrets)
  4. Still, there is a conceptual framework, and a reference architecture, which is what has been covered in the wikipedia article (to date).
  5. Mwsobol works full-time for AFRL/WPAFB (which maintains one? two? more? repos of the SORCER codebase... plus various USAF-proprietary libs/apps/etc).
  6. Mwsobol occasionally teachs SORCER, including in Russia (how many places? Ulyanovsk State University), and the Russians maintain their own SORCER repo (just one?)
  7. Mwsobol occasionally teachs SORCER, including in China (how many places? Beijing Jiaotong University), and the Chinese maintain their own SORCER repo (just one?)
  8. Cranfield University in the United Kingdom ... do they use SORCER, nowadays? When did they use it? What about UK military or British Airways or similar?
  9. Mwsobol occasionally does consulting work, and helps interested parties to get started with SORCER
  10. One such interested party was, located in Poland, who got trained by Mwsobol during 2013
  11. is now just starting to develop commercial GUI-tools for SORCER
  12.'s proprietary work is based on a private repo, an internal fork of the open-source codebase, is not available to the public,
  13.'s public work is based on the version developed at TTU (aka SORCER Labs), which is currently open-source
  14. Mwsobol occasionally teachs SORCER, including (in January 2014) in Poland at PJIIT, which is using an open-source version (different from's? Different from's repo, if any?)
  15. ... which is not officially connected to ... is the current home of Mwsobol's SORCER Lab (still at TTU? or now at AFRL? or maybe now at PJIIT? or maybe just spun-off to Mwsobol's private webhost? confusion!)
  16. The historical FIPER codebase, which was used at GE from the late 1990s (NIST-ATP-funded from 1999-2003 but Mwsobol first hired at GE GRC in 1996) for turbine-design.
  17. One of the small companies involved with FIPER was later acquired by Dassault, the EU corporation. Do they have an internal version of FIPER, or of SORCER?
  18. Is FIPER still being used by GE/Dassault/Stanford/OhioUniversities/others? If so, is the codebase (or are the codebases) available publically?
  19. Has GE used SORCER?
  20. Has Dassault used SORCER?
  21. Has Stanford used SORCER?
  22. Have OhioUniversities used SORCER? (yes, U.Dayton PhD + WrightStateU MEng) What about Ohio Aerospace Institute? What about BFGoodrich?
  23. During the transition from FIPER to SOCER-and-then-SORCER,
  24. some external links are redundant, already listed at
  25. one particular repo was developed at TTU, and is now maintained by
  26. Github contributors page ,
  27. This particular github group is the maintainers of the version developed at SORCER Lab
  28. There are many maintainers of multiple repositories, not just that one
  29. the SORCER platform is implemented in many places.
  30. The MSTC/AFRL/WPAFB/USAF is using and developing SORCER to ... [5]
  31. but, in the 2012 DaytonThesis, Kolonay (director of MSTC) was specifically mentioned as implementing three or four major class-libraries(?)
  32. It is not fair to those who really contributed and are ignored.
  33. Unless all development sites are listed it is just misleading information

Note that wikipedia tends to just give one main "official link" ... is that , nowadays ... right? As for the main subject of this talkpage section, anybody want to try and give me the overview of what groups were responsible for what code, when? Please start historically, so we can give a summary of the history of the project's code, in the article. Danke, it's appreciated. (talk) 01:48, 1 January 2014 (UTC)

"How many source-code repos there are, and who runs them, and what year(s) each repo was active." There are currently two maintained repos. There is one at the U.S. Air Forcer Research Lab(AFRL) which contains some new features and proprietary extensions - for example the whole Var-Oriented Modeling framework (see the latest papers). As far as I know this repo started around 2007/08 based on the one at TTU. The second one is the open source version maintained by my colleagues and myself at - it is a stripped down and mavenized version based on AFRL's version from mid 2013. Previously (2002-2009) SORCER was developed by Prof. Sobolewski and his students at Texas Tech University (TTU) but when he decided to quit TTU in May 2009 the lab was closed and the repo there was abandoned (I was his last student at TTU). Prof. Sobolewski doesn't keep SORCER to himself, he is open to invite others to use it and develop it but it is a rather complex technology and it is difficult to find people willing and competent enough to do it. Therefore, in the meantime there were several moments when the source code was given to students or researchers elsewhere (mostly China and Russia - the last attempt in May 2013 when Sobolewski was invited to run a workshop on SORCER to Ulyanovsk State University) but I don't believe that they still maintain and develop it, although of course one cannot be always sure what happend to those sources afterwards. Prubach (talk) 13:31, 16 January 2014 (UTC)
So, there is SorcerSoftDotCom, repo#1_A which is an open-source repo at github, and repo#1_B which is a closed-source fork thereof for the proprietary GUI-tools. Next, there is repo#2 closed-source repo used inside AFRL. What is SorcerSoftDotOrg, does it not have a repo? Or is it the open-source-portion of the AFRL repo? Historically, there was repo#0 at TTU, the ancestor of all current SORCER-repos. Historically-or-maybe-currently, there was repo#3_A at Ulanyovsk, repo#3_B at Samara (or maybe they shared repo#3_A?). Historically-or-maybe-currently, there was repo#4_A in China (and maybe more than one repo?). However, notability is not temporary, we need to go further back in time to FIPER. There was a FIPER repo, call it repo#5, used at GE/GRC, right? Is it still in use? Have they upgraded to SORCER? What *do* they use nowadays, does anybody know? Goel was from NY... was he working with GE and with TTU, or just with TTU? Furthermore, this FIPER repo#5 was the ancestor of TTU repo#0, but FIPER was also the direct ancestor of Engenious repo#6_A, which became Dassault repo#6_B, which is now Simulia repo#6_C (munged in with Dassault's Abaqus product-line). Also there was C.D.Cera(FIPER?) + Nnanji(FIPER), what repo? In the UK, we have W.D.Li(FIPER) + G.Goteng(SORCER) — what repos did they use? (talk) 19:24, 16 January 2014 (UTC)

technical question, about exertions versus federations[edit]

"An exertion as the service classifier is used in SORCER and so all federations such that the exertion can be bound to at runtime are instances of it." --Beavercreekful

  1. I do not understand the above sentence.
  2. I'm familiar theoretically with Self.
  3. I'm familiar with Javascript-style prototyping where there is no classdef; objects are just modified-clones of previous objects.
  4. An exertion is an nsh-shell-script, written in EOL or in Java.
  5. A running/executing exertion is a service (kinda-like a web service but-not-exactly-like).
  6. A federation is a compound-service (a wrapper around a set of services... and the wrapper itself can be treated as a service).
  7. If I have a file called myExertion.sorcer stored on my local PC, that file (or the associated config-file maybe) will give the pointers (names? network-locations? URLs?) to the federations it depends upon.
  8. When I use nsh to execute-slash-run myExertion.sorcer , the bindings of the actual underlying dependencies (local federations/services or remote federations/services or local Linux apps/datafiles) are bound-at-runtime.

What does the word "it" at the end of the confusing sentence, really mean? " all federations such that the exertion can be bound to at runtime are instances of it."

  1. If an exertion can be bound-at-runtime to a federation, those federations are instances/subclasses/interfaceImplementations of that exertion?
  2. Or, if an exertion can be bound-at-runtime to a federation, then that exertion must be an instance/subclass/interfaceImplementation of those federations?
  3. Or, something else entirely?  :-)

Thanks. (talk) 01:48, 1 January 2014 (UTC)

  • Ad. 1) I do not understand the above sentence. — 74

Let's start with the UML definition of "classifier" with "exertions" added for my service-oriented class.

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

If object a is an instance of a class A, A is the classifier of a.

And now it's important to understand the difference with interface types. An object a of class A that implements interface B is instance of interface B. In other words, the interface B is a classifier of a. By the interface type we can classify objects independently of the object implementation (class). SORCER uses interface types in exertion signatures to bind to network objects that implement the signature interfaces. Mwsobol (talk) 04:17, 1 January 2014 (UTC)

Okay, that's much clearer, thanks. My understanding is that there are two (colloquial) types of exertions, as used in SORCER. There are the usual sort, the front-end exertions, coded up by a savvy aerospace-designer to automate some kind of wing-design-analysis procedure, or somesuch. These front-end exertions (FEEs) run locally, and can optionally rely on other FEEs, also running locally, but coded so as to implement specific interfaces. In addition to calling each other (possibly within the same JVM instance or possibly across multiple JVM instances running with different CPU affinities and/or security settings), FEEs can also call remote back-end-exertions across the network. Much like the FEEs, the BEEs are just exertions... but running on another box.
  For the sake of being concrete, we have a client-side aerospace-engineer-slash-programmer named Alyssa, who implements her own set of four FEEs on her local workstation, A1 A2 A3 A4. These are wrappers around her local command-line tools for the most part, and call each other (FEE to FEE) from time to time. These are simple FEEs which do not depend on any BEEs that are located across the network. However, there are also four BEEs, B5 B6 B7 B8, which are each running on their own back-end server-box, and exposing their interface-implementations via the SOS (in some handwavy fashion that I do not yet understand). The author of the BEEs was named Ben, who programmed and tested and installed and configured all four BEEs, then left for Hawaii.
  When, on the following Monday, our hero Alyssa goes into work and boots her workstation, she opens nsh and writes A9, an especially complicated FEE, which relies on all eight of our existing A1..A4 local-services and B5..B8 remote-services. When she is finished programming, Alyssa then executes A9, and the magic happens: when on line 111 the code of A9 calls the 'non-internal' Java-function foo(), nsh scans the SOOAverse looking for something which implements foo(), and discovers A1, then dynamically binds the FEE A9 with the FEE-acting-as-a-network-service-A1. Later, when on line 555 the code of A9 calls baz() nsh-slash-SOS discovers B5 implements that, and does the FMI thing to connect A9 into B5 across the network. Finally, when on line 666 (gasp!) the code of A9 calls qux() which is implemented by B6 there is a problem, the server-box B6 was running on just crashed, but luckily, C5 C6 C7 C8 C9 replicated online backup boxen are ready, so nsh-slash-SOS discovers that C6 can provide the implementation of qux() that A9 requires. Happy ending.
  At the end of the day, I understand (or believe I do — please correct as needed) the sentence now... but I don't think the sentence is necessary because I don't see what is special about the words.
An exertion A local nsh shell-script (aka FEE)
as the service classifier calls Java-interfaces implemented in other scripts
is used in SORCER which are discovered by nsh-slash-SOS
and so when configured as SOS-visible service-providers.
all federations All server-side nsh shell-scripts (aka BEEs)
such that the exertion can be called by local nsh shell-scripts (FEEs)
can be bound to with function-calls to methods defined in Java-interfaces
at runtime dynamically bound at function-call-time (or at FEE launch?) by nsh-slash-SOS.
are instances Speaking in terms of theoretical computer science, the FEE is an 'instance'
of it (the federation). of the set of all BEEs (the network-visible 'federation') which is relies upon.
Please correct my errors and/or misunderstandings. Because the goal is to explain SORCER in 100 words or less at the top of the article, and then describe the details of SORCER in 1000 words or less in the main body of the article (or perhaps summarize the key details is a better way to put it), my goal is to use as much Java-and-CPP-and-ALGOL-style concepts as possible, so that the casual reader who has some programming background will be able to understand what SORCER is/does/etc. Even if they only have six months of 9th-grade Intro to HTML and Intro to Javascript under their belt.
  For speed, I'll go ahead and reply to your other sections below, but if my assumptions in the table above are wrong, no doubt I'll be even more wrong in my answers below. Do not feel that you are required to respongd toeach reply of mine, or even read them, if you can already tell I'm off the true path.  :-)   Thanks for your assistance. — (talk) 19:36, 4 January 2014 (UTC)

If an exertion with a service signature including a service type B (practically Java interface B in SORCER) matches the interface of a network object (service provider) that implements the interface B then this service provider is the instance of this exertion. Now if an exertions includes 5 signatures with 5 services types (Java interfaces) then five service providers in the network that implement these interfaces create the service federation for this exertion. This federation is an instance of the exertion. In that case we say that the exertion binds to the federation and matching (binding) is done by the SORCER OS. Take into account that there in no any static references to service providers in exertion signatures.

Service providers are replicated for reliability and load balancing. So, when you run the same exertion again you can get usually a different federation (a collection of matching providers based on the interface types only). Obviously another attributes can be used in SORCER as well if required but the basic concept of binding is based on service types. That federation concept does not exist in any other service-oriented platform. By the way provisioning in SORCER is based on the service type concept as well. For a set of signature the SORCER OS on-demand can create a corresponding federation or multiple federations (instances) of a given exertion. Mwsobol (talk) 04:17, 1 January 2014 (UTC)

I understand the part where you say, "...then this service provider is the instance of this exertion". But what is the *value* of that factoid? Why does a reader (usually referred to as Randy From Boise hereabouts), need to know that exertions-are-classifiers-aka-parents-of-the-federations-which-implement-the-exertion's-client-side-function-calls-to-server-side-interface-implementations-and-thus-federations-can-be-seen-as-instances-of-said-exertions? Can we not just tell Randy, that exertions-make-function-calls-which-nsh-passes-across-the-network-to-server-side-federations-that-implement-the-function-bodies? If not, why not? Given an exertion-which-is-a-classifier-of-a-federation-aka-instance, can I subclass the exertion, or jscript-style-prototype the exertion, to programmatically generate a *new* and distinct federation-instance? Can I use server-side programmatic reflection to modify the client-side *exertion's* implementation at runtime without needing any access to Alyssa's workstation PC? Or maybe something else special.
  I'm going to skip asking how the load-balancing and replication work, specifically... because I suspect that is explained in the helpdocs. But I will note, in my understanding at present, that client-side FEEs are not configured to be load-balanced nor replicated by default, and that server-side BEEs *are* so configured (manually presumably by a sysadmin), but that otherwise there is little difference... both FEEs and BEEs are nsh-shell-scripts, implemented in Java (or Groovy or EOL perhaps). Is this correct? Is it possible for Alyssa in Asia to change her FEE A3 into a network-visible service-provider, that her fellow aerospace-engineer Carly is able to use across the LAN from the seventh floor of the same building in Hong Kong? Next, what about Dan in Denver, can *he* see the A3 nsh-shell-script that Alyssa wrote, and configured to be network-visible to Carly on the 7th floor? Obviously, our friend Dan can get on a plane to Hong Kong, or Dan could install VPN software to make his PC virtually "part" of the LAN in Hong Kong... but does nsh-slash-SOS provide network-visibility only on the LAN, or does it offer web-visibility in some fashion? What nodes are considered fair game, when it comes to replicating BEEs? How is data-storage replicated, if B6 depends on /home/ben/dataset.txt what happens when B6's dedicated node is offline, and the replication-node C6 is trying to take over implementation of qux() for all the FEEs? (talk) 19:36, 4 January 2014 (UTC)

  • Ad. 4) An exertion is an nsh-shell-script, written in EOL or in Java... — 74

see "How to explain SORCER conceptualizations?" An exertion is a front-end specification of a service federation and its collaborative behavior. A textual form of interpreted exertions are called "netlets", exertions as instances of Exertion interface (Created with SORCER API) are called "exertlets", and exertions created with GUIs are called "service diagrams". Thus, three forms of exertion languages exist: EOL for the network shel (nsh), Java API (no need for the shell), and a visual exertion programming with a GUI that creates a corresponding exertlet or netlet or both if the round trip editing is supported between service diagrams and netlets. Mwsobol (talk) 04:17, 1 January 2014 (UTC)

Okay, so I would instead say, an exertion is an nsh-shell-script, written in EOL, or alternatively, a Java program which directly accesses the SOS API (bypassing nsh). But my understanding is that the "innards" of the server-side federations were *also* just a bunch of (server-side) nsh-shell-scripts-in-EOL, or alternatively (server-side) Java programs, which differed from client-side exertions only in that they were configured to be network-visible.
  1. Can a client-side exertion A4 implement an interface, and be configured to be locally-visible to other exertions on that PC, and then have another client-side exertion A9 which classifies the interface-implementation provided by A4? I think the answer is yes, but correct me if I'm wrong.
  2. Similarly, can a server-side exertion 'program" B7 implement an interface, and be configured to be locally-visible to other exertions 'programs' on that server, and then have another server-side exertion 'program' B8 which classifies the interface provided by B7? Again, I think the answer is yes, but correct me if I'm wrong.
  3. Finally, the big new feature of SORCER-fka-FIPER is that client-side exertion A9 can magically dynamically classify server-side exertion 'service provider' B7, as long as B7 is configured to be network-visible in a way that A9 can see via nsh-slash-SOS (as opposed to B7 just being "locally-visible" to B8).
As for netlets and exertlets (but not service-diagrams which merely are a means of creating those).... My assertion is that a netlet can be written and then run on Alyssa's workstation PC, but also that a netlet can be written and then run on Ben's app-server (or replicated server-farm of app-servers). Same assertion for exertlets. Am I wrong about these? Are service-providers not simply netlets/exertlets which have been configured so as to be network-visible, and optionally replicated? (talk) 19:36, 4 January 2014 (UTC)

  • Ad. 5) A running/executing exertion is a service (kinda-like a web service but-not-exactly-like). — 74

see "How to explain SORCER conceptualizations?" below. Oh, No!!!
Web services are back-end services (deployed at the app servers) and the front-end client can invoke only one service per invocation with a static server end-point (URL). What the invoked service do later is another story. An exertion is the from-end service that invokes a collaborative federation in the network (as explained above). There is no app servers, no static end-points, service providers are small footprint independent services that can come and go as needed in the global network Mwsobol (talk) 04:17, 1 January 2014 (UTC)

I agree with everything you say (except the "oh no" portion :-)   ...   but I was under the impression that a "collaborative federation" was in fact implemented with server-side exertions, written by server-sider programmers. When a client-side programmer writes a client-side exertion, nsh-slash-SOS hooks the client-side function-call up tothe server-side function-body. Incorrect? See the final sentence of Prubach's answer at 11:59 here,[6] "you're right about the possibility of dividing execution between the provider ((server-side exertion 'program')) and requestor ((client-side exertion)) - it cannot be done dynamically but needs only a reconfiguration of the provider". I understood that last bit to mean, that a server-side backend service provider, was merely an exertion installed on a server-box, with some special configuration to make it discoverable-on-the-network by the nsh-slash-SOS. (talk) 19:36, 4 January 2014 (UTC)


"I need to understand whether or not a locally-defined EOL-script, is visible (by default or just optionally or not at all) across the network?" - An EOL script contains the defintion of an exertion. (you can see an example here: [7]) - an EOL script by itself is just a script, and so just like any file you can put it on a web server etc. but it is not exposed by SORCER in anyway. However, when you execute this script using the network shell (NSH) then the tasks defined in it may run on remote machines - everything depends on where you started the Multiplier, Adder and Subtractor services. By default an EOL script (and this particular example as well) doesn't specify whether the exertion will run locally or remotely (although you can limit it to be executed only locally) - this will be determined at runtime dynamically. This is the Front-end federated programming.

Since the main goal of SORCER is to foster reuse, there is a possibility to easily (no coding, just configuration) create a service using an existing exertion - in that case you supply your script and you can start a new service that when called will execute the exertion specified in your EOL script - this is the Backend federated programming because it needs some deployment (configuration and starting of the service) - it is the equivalent of deploying a new BPEL process on a BPEL engine (the process will call other web services but it must be first deployed to be accessible to users).

On the second half of this point, further clarification of the details of back-end-federated-programming please, concerning the typical way back-end-service-providers are created. Here is how I paraphrase/understand what you said. Back-end federated programming is easy: given an existing exertion-defining-scriptfile My.EOL, you can, without further programming, configure&start (aka deploy) a new service[provider], that when called, will execute that exertion (i.e. the one specified in My.EOL). You mention that the 'deploy' step is kinda like Business Process Execution Language process-deployment on a BPEL-engine... but BPEL is web-svcs-stuff, that means the BPEL-engine is a webserver. If I have an engineering-workstation, with AutoCAD and LibreOffice installed, and I'm doing my finite-elt-analysis on my wing-design with some local exertions My1.EOL / My2.EOL / My3.EOL and so on, aka pure front-end-federated-programing, how hard is it to "deploy" My2.EOL so that it becomes a LAN-visible service, that my buddy in the next office can call from *her* local EOL-scriptfiles?

X. Do I have to install a webserver on my workstation-PC, and install the 'backend' pieces of SOS, reconfigure my software firewall to open up a bunch of ports, login as admin to install some daemons, or something complicated like that? Y. Or, do I just open up some config-wizard, click the 'create new svc' button, browse to /home/alyssa/wing/My2.EOL in the wizard, and click 'OK' for a total "deploy" time of sixty seconds flat? Z. Or, something else, please specify.

From your answer to my LAN-and-VPN-question (below), my assumption is that doing back-end-federated-programming is more like the install-a-bunch-of-server-side-junk-and-mess-with-firewalls description. Therefore, in typical practice, our engineer Alyssa would not be able to make My2.EOL into a LAN-visible service from her *own* workstation... instead, she would FTP/NFS/SMB/whatever the scriptfile to an already-configured-server-machine (w/ Apache River infrastructure already up and running!) elsewhere on the LAN, and then ask some friendly sysadmin of that server-machine to run the config-wizard to deploy My2.EOL on that server box. Is this correct?

gory details of SORCER's networking substrate[edit]

"Is SOS currently a LAN-slash-VPN-only solution, or whether it can function seamlessly-out-of-the-box through firewalls across the global internet?" The networking layer of SORCER is implemented using JINI/Apache River. Therefore, in this respect it functions just like JINI services themselves. In JINI there is a lookup service (called Reggie) that is used to discover and register existing services. Reggie supports multicasting and unicasting. Obviously, multicast works only in LAN and may be enabled via VPN but it may be rather impractical in this scenario - assuming the VPN has a limited bandwidth, it doesn't make sense to send all multicast requests via VPN when, for example, most of them will be of interest only within the main LAN. In that case you can bridge multiple JINI/SORCER installations using unicast - for that you need to configure the addresses of the remote Reggies in every Reggie. So in that case, multicast doesn't have to be enabled between all the SORCER services on both networks, however, the services must be able to communicate directly once they discover themselves via the Reggies, so firewalls and routers may make that difficult. Prubach (talk) 13:31, 16 January 2014 (UTC)

  • Some techie-questions, see here.[8] Does SORCER use the JERI protocol under the hood, and if so, what substrate-transport(s) are supported out of the box? Apache folks say you can send packets as unencrypted-TCP, SSL-over-TCP, or Kerberos-over-TCP ... all these options are effectively LAN-only (because of firewalls in the wild). However, they also say you can send JERI packets over HTTP/HTTPS ... but from your answer to point#3 it sounds like SORCER does not do this. For performance reasons (e.g. is multicast only supported in some transports?), or code-complexity reasons, or historical reasons, or something else? Maybe under the hood SORCER is using JRMP-transport aka old-school RMI stuff? (talk) 19:24, 16 January 2014 (UTC)

  • River offers infrastructure for dynamic discovery (w/ a registry), and optionally, for on-demand-distribution-of-compiled-code (w/ a class-server). It sounds like SORCER use a River-based-registry aka Reggie, but does SORCER use a River-based-classServer? Or not, and if not, what *does* SORCER use for the distributed-computation-magic it offers? (talk) 19:24, 16 January 2014 (UTC)

  • You say: "services must be able to communicate directly". This is too abstract. How do they 'communicate directly' across the LAN? What are the specifics? By way of analogy, consider how you would explain FTP to me. There is an FTP client, an app on PC#1. There is an FTP server, a daemon on PC#2. They also "communicate directly" with each other. Specifically, FTP was based on NCP from 1971-1980, and since then on TCP. Active-mode means, the client on PC#1 must know the IP of PC#2 (or DNS-name if we assume PC#2 has a domain-name && PC#1 has a DNS-client), to create the control-channel, a socket from (any-un-priv) port 55555 on PC#1 to (standard) port 21 of PC#2 over LAN-or-internet. Next, the client sends a PORT 55556 command, and the server on PC#2 creates the data-channel from server-port-20 to client-port-55556. This assumes no firewalls in the way, either direction! Thus, in passive-mode, client sends PASV (not PORT 55556), and server replies on ctrl-chan w/ PORT 20, after which *client* creates data-channel from client-port-55556 to server-port-20. Thataway, firewalls only need to be properly configured to make the *server* aka PC#2 web-visible; client can be locked down against intruders. That is FTP, in a nutshell. We can also talk security, there is an optional login-name (or anonymous), plus there are several optional crypto mechanisms (explicit FTPS with AUTH TLS to server-port-21 / implicit FTPS to server-port-990 / "explicit" FTP-over-SSH-tunnelling to server-port-22 / "implicit" SFTP to server-port-22 / maybe others). What does SORCER work like? Feel free to just point me at the appropriate helpdoc for River-and-or-SORCER, if these gory details are already put in writing somewheres. (talk) 19:24, 16 January 2014 (UTC)

How to explain SORCER conceptualizations?[edit]

I was alarmed about the confusing SORCER conceptualizations above, so let's hope the clarification by analogy to a common computing platform will help to understand unique features of the SORCER platform. By the way, conceptually it does not have anything common with grid computing or web services. The fact you can do grid computing or run web services in SORCER does not mean it was designed directly to do so.

Let's consider a common computing platform (or runtime: programming environment, operating system, processor). For example, a UNIX platform (programming environment - Unix shell programming, a UNIX operating system, and a native or virtual processor such that the operating system can execute programs (executable codes) compiled for this platform. So, each platform has a front-end (shell or command processor), a back-end (executable codes) and in the middle (an operating system). A common platform is used predominantly to execute a single command that runs the executable code in the shell locally. Advanced users can write a shel script (in a file or at the command line) to create a pipeline of locally executing programs (pipes are local). The fact that an executable code can provide networking internally using for example sockets or any application protocol (FTP, SMPT, HTTP) is the feature of a program (application) not the platform. The common platform runs executable codes locally.

Now let's imagine that a platform at the back-end instead of local executable codes has applications, tools, utilities that can be provisioned on-demand in the network at runtime (they constitute a network processor of the platform). Now the shell script can define any collaboration (service pipeline (batch), workflow, block for branching and looping) of back-end services that can be found or provisioned in the network at runtime. These scripts define front-end services (programs) as collaborations of back-end services. The shell now executes front-end services and the operating system can run any collaboration of back-end services. These collaborations of backend services for each front-end service are called service federations. The paradigm is called federated service-oriented computing since a shel invokes a federation of service providers. To do so the operating system needs a new invocation method, instead of invoking a single program or pipeline of programs locally invokes a federation of back-end services in the network for each front-end service. Please match the above description to the chart of the SORCER OS in the article. Note that all other service platforms provide service collaborations at the back-end (called an applications server) only.

The above federated platform defines: a front-end service (exertion), a singleton back-end service (a service provider), and a back-end collaboration of services (federation) specified by a front-end service. When developing the FIPER architecture I have introduced the terms given in parenthesis to emphasize three types of completely different service semantics in federating computing. If you prefer, you can use longer names in the article: front-end service, back-end service, and a collaborative service at the backed defined by the front-end service. By the way a front-end service is a collaborative service as well but at the front-end as the virtual service (realized at the back-end by its federation). Also, calling a front-end service as a "service script" like UNIX script is confusing due to completely different semantics of the network shell, operating system, and the processor as a collection of dynamic service federations. SORCER front-end scripts are called "netlets". An exertion is a more generic concept for a front-end specification of a back-end federation. Formally, an exertion is a metamodel with models in the form of "netlet" (textual), "exertlet" (any object that implements Exertion interface, created with API), and "service diagram" (visual programming - interactive GUI). Therefore a netlet, exertlet, and service diagram are exertions. Three different forms of front-end services have to be called differently and three types of services (exertions, service providers, and federations) in federated computing have to be called differently.

The SORCER lab completed research in all aspects of federated computing as described above. Other organizations including AFRL develop federated service applications using the TTU SORCER platform. The research papers by AFRL are focused on how to design air vehicles using SORCER but not how to design SORCER. I assume this article is about the TTU platform architected, designed, and implemented at the SORCER lab as the extension of FIPER. The currently offered open source version maintained by is the implementation completed at the SORCER lab. Thus, please drop any unjustified relationships of the TTU SORCER technology to other organizations that can be used as the secondary sources regarding how SORCER is used. They spent own money on the projects related directly to they business objectives. When they say we develop SORCER it means that develop tools to make SORCER easier to use with their applications. is not developing the SORCER technology as well, the company is developing tools for interactive exertion-programming and var-oriented modeling. They do what Apple has done with BSD UNIX for Mac OSX. There is no any research paper on the SORCER technology from other places than the SORCER lab ( since that core technology is open to any organization with no need to redevelop it. I still assume the article should be about the core SORCER technology that originated from NIST FIPER and TTU SORCER.Mwsobol (talk) 02:59, 1 January 2014 (UTC)

During my reading of this explanation, I replied above, which methinks covers the meat of where I am confused. The bullet-points here are just clarifications or quibbles, to make sure we are on the same page after we get to the heart of how exactly server-side back-end service-providers are practically implemented... are they just a server-side exertion with some config-stuff to make them network visible? If not, what exactly *are* service-providers implemented as? Anyhoo, on with the bullet-points.
  • 0. "...conceptually (SORCER'13) doesn't have anything common with grid computing, or web services." Quibble: conceptually speaking, that may be true, but SORCER'08 is described in the sources *as* a grid-computing solution, and used by e.g. DaytonThesis of 2012 primarily *for* the grid-computing features. The sources call SORCER'08 grid-computing, and wikipedia follows the sources. Wikipedia is supposed to document both the current state (as documented in WP:RS) of a topic, as well as the historical evolution of a topic. Therefore, SORCER'03 is relevant tothe wikipedia article, and it *was* a web service implementation, from what Pawel hinted, right? As for FIPER, which this article will also document the history of, it is definitely distinct from SORCER'13 in many ways.
  All that being said, wikipedia IS NOT MEANT to give an elegant theoretical abstract description of SORCER's conceptual architecture. Why? Because less than 1% of the readership will understand such a thing. Wikipedia has to explain FIPER'00/SORCER'03/SORCER'08/SORCER'13 properly, which means, in term s the readership will find more understandable. Therefore, whenever possible, we avoid abstract fuzzy concepts, we use metaphors relating SORCER-features to things the reader has already likely heard of, we keep jargon/neologisms/TLAs/multisyllabicisms to the absolute minimum, and so on. Wikipedia *can* have advanced concepts, but we cannot start out in the first sentence, packing it full of ten fancy words. That will be useless to most readers.
  We have to explain the topic slowly and thoroughly, from the ground up. Is SORCER being used in the wild, as documented by WP:RS, for grid computing? Yes. Do the sources call it that? Yes. Will the readership understand what grid computing is? Yes, and if not, they can read grid computing. Even more readers understand web services, than understand grid computing; it is dramatically easier for the readership for us to say that SORCER is some kinda grid computing infrastructure for CAE, and sorta implemented with non-URL-based web services, and then go on to explain SORCER better, later, than it is to just smash the reader's gumption instantly. :-)   A bit further down, you had suggested a barebones-UNIX-platform metaphor, which is a great idea, see numbered sections below.
  I suggest we start with the barebones-UNIX-platform, and then extend it, and speak of ssh and cURL and such (more on this in a minute). Then we can speak of an analogy to web services. Then to grid computing, as a metaphor to improve understanding, plus also because SORCER is often used thataway. Finally, we'll get to the EECS meat: exertions as classifiers of federation-instances, all running on a virtualized meta-operating-system. Everything will be clear in the reader's mind, the metaphors can drop away, and then can head for the Further Reading section where all the key papers over the years are listed. Plus, at the tail end of the descriptive overview, we can cap off the descriptive-section of the article with the newly-cited-in-2011 mogramming, and a brief mention of the as-yet-still-classified var-oriented stuff. Another portion of the article can cover history of the concept, and the researchers who helped. Another section will cover killer applications, the aircraft-engine design at GE/GRC with Engenious, the traffic-noise-mapping by Nan Li, and the auto-optimizing physics-based-predicting CAD/CAE work by AFRL, among others.
  1. "The fact you can do grid computing or run web services in SORCER does not mean it was designed directly to do so." Correct, and important. The article *should* describe the historical design-goals of FIPER'00/SORCER'03/SORCER'08/SORCER'13, in turn, and it should do so accurately. That said, it should also describe what customers/funders/endusers actually did with SORCER, and usually that means grid-computing for aerospace-design CAE/CAD efforts. Right?
  2. "...a common computing platform (or runtime: programming environment, operating system, processor)." See my note over on WT:Articles_for_creation/Exertion-oriented programming, about the traditional meaning of the terms operating system, software platform, hardware platform, programming environment, API, processor, and runtime. Because wikipedia uses these terms in the way that traditional sources use them, and more importantly, because the readership *expects* that when we say operating system we mean something like Win7 / OSX10.6 / Ubuntu1204 / Android 4.0 , there is simply no way that we can call the SOS an 'operating system' without scarequotes and an immediate explanation that it is really a meta-operating-runtime-platform-thingamabob.
  3. 'UNIX platform' == native (or virtual) CPU, with Linux/BSD/similar UNIX-like OS installed, logged into a command-line bash shell, which can execute both compiled javac apps, as well as interpreted shell scripts (usually bash). Okay, fair enough, this is a description of a 1980s-style UNIX workstation, with no GUI and no ssh and no VNC, plus of course, not graphical web browser and no graphical multimedia-player. So I would dub it the barebones-UNIX-platform.
  4. "each platform has a front-end shell, in the middle an operating system, and a back-end (executable codes)" This description does not match my understanding of Linux. There is a front-end shell, which provides two main features, the usermode interactive TUI and also the shebang-based interpreted usermode shell-scripts. There are compiled apps too, in our hypothetical barebones-UNIX-platform using javac. Even they are still usermode apps, and of course, just like shell-scripts; and under the hood, our shell-scripts are converted from Unicode text into binary CPU opcodes, before actually getting executed by the processor. And technically, java apps are only partially compiled, into bytecode which is later interpreted by the JVM into raw CPU opcodes (at runtime via JIT). In the middle is the kernel mode portion of the operating system, which provides the system-level API, used by the JVM and the bash-interpreter. At the back end is the physical hardware, including GPU and CPU and drives and keyboard-microcontroller and such.
  5. " create a pipeline of locally executing programs (pipes are local)." Yes, typically... though our barebones-UNIX-platform is lacking ssh, which *does* allow non-local scripts, and you can even use ssh-tunnelling of GUI apps. Of course, nowadays we also have web-apps and various sorts of web-automation tools, such as wget and cURL and phantom.js and such; some programming languages have HTTP-based cross-network "pipes" built into the language, including Javascript (XmlHttpRequest) as well as PHP (fopen/file_get_contents/etc) ... which are common languages for beginning-programmers, which work in a command-line environment in the form of WSH and PHP-CLI. Maybe we can explain SORCER in those terms, rather than in terms of federated method invocations, in the top half of the article-overview section, before we get into the literature-specific stuff in the bottom half article-gory-details section? We can even speak of dyn-DNS and torrents for dynamic provisioning, and distributed webserver farms plus CDN-style systems load-balancing, to explain some of the fancier features of SORCER, The question is not how best to describe SORCER's academic heritage, in the world of ideas (that can be done of course), but rather how to metaphorically *explain* the complexity of SORCER in easy-to-digest step-by-step chunks.
  6. "...imagine that a platform, ...instead of local executables... has apps... provisioned on-demand in the network at runtime..." Sure, fair enough. When I type 'sort' at the bash prompt, what I expect to happen is that the local PC will execute the local app of that name. The algorithm implemented by 'sort' might be dynamically parallelized across my 8-thread 4-core CPU, with the Linux kernel's scheduler performing the necessary "time-sharing", and conceivably the 'sort' on my machine might even make use of the GPU and/or FPU for additional horsepower. Eventually, the final answer is sent to stdout of my bash prompt. By contrast, when I type 'exert massively_parallel_gridsort.netlet' at the nsh prompt, what I expect to happen is that the SOS discoverer(?) will look around to find there are N idle compute-nodes available, the SOS provisioner(?) will dynamically launch N fresh new back-end service-providers (each of which implements massively_parallel_gridsort_worker() interface-method), and the SOS federated-filesystem will provide one-Nth of the dataset to each compute-node. After the recursion of the Merge_sort#Parallel_processing algorithm is completed, the final answer is sent to stdout of my original nsh command on my local PC, just as expected. Now, one *could* implement such a thing with ssh-calls, or with wget-calls, or some other bash-scripting trickery. What are the advantages of using SOS, rather than fancy-bash-scripting with network-aware command-line apps? And then, what are the advantages of SORCER compared to various grid-computing solutions? For the historical reseachers amongst our readership, how does SORCER compare to network-transparent distributed-operating-system projects like Amoeba (operating system), where Guido van Rossum of Python fame cut his teeth? Does SORCER support process migration, of live and running workers?
  7. "...a new invocation method, instead of invoking a single program or pipeline of programs locally, invokes a federation of back-end services in the network, for each front-end service...." Which is the FMI. However, I would just call it a multikernel system maybe, or some flavor (which?) of distributed_operating_system#Design_considerations, but definitely not wikipedia's definition of a "network operating system" and probably also not any sort of single system image.
  8. "...all other service platforms provide service collaborations at the back-end (called an applications server) only." What about peer-to-peer systems like Gnutella? What about decentralized virtualized networks like Tor?
  9. "exertion == front-end service" / usermode-program / Java-app / nsh-shell-script ... and according to the JPEG in the exertion-oriented programming article, it can also be called a front-end federation. Are all these phrases correct? Any wrong? Any misguided, or with possibly-misleading connotations? Can a front-end exertion, call *another* front-end-exertion?
  10. Paraphrasing heavily: "...service diagrams (interactive-programming-GUI-representation which becomes a netlet), netlets (textual nsh-scriptfiles in EOL which becomes an exertlet), and exertlets ( textfile and/or foo.class bytecode and/or live-in-the-JVM objects that implement the Exertion interface and interact with the SORCER-OS discovery-n-provider API), are the various forms of exertions which exist.... An exertion is a more generic concept for *any* front-end specification of a back-end federation." Is my assessment correct?
  11. "service provider == singleton back-end service" / server-side service / back-end federation / dynamically-spawned network-service / dynamically-bound network-service. Are all these correct? Any wrong? Any misguided, or with possibly-misleading connotations? How exactly are service-providers implemented? The same way as front-end-exertions, just a different name, and configured as network-visible?
  12. "federation == back-end collaboration of services" / conceptual wrapper around an exertion-defined set of service-providers / list of parallel workers executing the compute-tasks given by a parent exertion / instantiation of the 'class' which a specific exertion defines / just a bunch of web-services accessed via SOS-discovery rather than via static URLs / same thing as a front-end federation only run on hardware which cost more than a run-of-the-mill personal machine. Are all these phrases correct? Any wrong? Any misguided, or with possibly-misleading connotations?
  13. "...(these neologisms) emphasize three types of completely different service semantics in federating computing." Okay... which is a valid goal... but aren't they all just nsh-scripts, calling other nsh-scripts, sometimes across the network, and sometimes not? Because if so, explaining that they are all just nsh-scripts written in EOL (or equivalently that they are all just Java-apps written to implement the Exertion interface-spec) is going to make writing the first half of the wikipedia article much simpler. We can explain the semantic distinctions in the bottom half, so that folks will not be confused when they seek Further Reading.
  14. "...a front-end service is a collaborative service as well but at the front-end as the virtual service (realized at the back-end by its federation)." So what you're saying is that a local exertion, which doesn't actually call any service-providers (aka actual implementations of actual functionality), is basically worthless? I thought that I could create a local exertion... or mayhap a "local service provider"... which was a thin wrapper around some traditional UNIX app like grep or somesuch, specifying that my "grep-wrapper" implements the findstr() method. Later, maybe I would create a local exertion called foo, which would FMI to a back-end service-provider for searching the enterprise knowledge-base, but could also get bound to the local-on-my-PC "grep-wrapper" service-provider. Is it impossible to write a local service-provider, and call it from a local exertion?
  15. "Also, calling a front-end service as a "service script" like UNIX script is confusing due to completely different semantics of the network shell, operating system, and the processor as a collection of dynamic service federations." I'll admit that I'm pretty confused by now.  :-)   This sentence in particular made no sense to me, but maybe after some of my other questions are answered, it will start to make sense.
  16. "I assume this article is about the TTU platform architected, designed, and implemented at the SORCER lab as the extension of FIPER." No, incorrect assumption. This article is about the general topic of "SORCER" which includes SORCER'03 prototype, the SORCER'08 paper aka TTU-SORCER, the AFRL fork of SORCER, the multiple Polish forks of SORCER, the Chinese SORCER, the Russian SORCER (if any info is available), and even SORCER "version zero" also known as FIPER, plus forks of FIPER like Engenious/Dassault's fork, and possibly iSIGHT. Wikipedia should cover the history of the system, the major highlights (as specificially make WP:NOTEWORTHY by their mention in Reliable Sources), the proprietary bits, and so on. If we cannot fit it all in one article of a comfy size, it will be split into subsidiary-articles. For a complex system with a long history, see Internet Explorer which has sub-articles on Trident the core technology, MSIE8, MSIE6, MSIE2, and internal forks like IE5 for Mac as well as partially-third-party forks like AOL Explorer and Sleipnir.
  17. "Thus, please drop any unjustified relationships of the TTU SORCER technology to other organizations" See explanation above. SORCER is an encyclopedia article about the general phenomenon, meant for a general readership, and is not specific to any particular variant, organization, company, author, et cetera. We don't have enough sources to give every variant their own article (whereas with Internet Explorer there are literally *hundreds* of articles because there are tens of thousands of magazines/books/teevee/radio/confpapers/etc which document the various versions in excruciating detail).
  18. " the secondary sources regarding how SORCER is used. They spent own money on the projects related directly to they business objectives. When they say 'we develop SORCER' it means that develop tools to make SORCER easier to use with their applications." Sources are not privileged, based on who they are; as long as they are talking about the general phenomenon, they belong in this article, about the general phenomonon. That said, we want to be careful that the wikipedia article is *accurate* about the activities of the different groups, giving credit where credit is due. But because the article is not specifically called SORCER open-source codebase as maintained by the owners of and nobody else plus papers by those owners and nobody else, the article will cover GRC FIPER, Engenious FIPER, Dassault FIPER, TTU SORCER'03, TTU SORCER'08, AFRL SORCER'08, SORCER'10, SORCER'13, China SORCER, Russia SORCER, SORCER'13, and soon probably PTIIJ SORCER'14 (if that becomes a fork rather than a contribution back upstream to or or whatever variant PJIIT uses). Does this make sense? Because there is only one article at the moment, that one article covers all the variants that are WP:NOTEWORTHY according to reliable sources, giving credit where credit is WP:DUE.
  19. " is not developing the SORCER technology as well, the company is developing tools for interactive exertion-programming and var-oriented modeling. They do what Apple has done with BSD UNIX for Mac OSX." Well, kinda... but Apple used their own trademarks, whereas is using the same trademark as (and ditto for AFRL). See my long set of questions above, asking how many SORCER-or-FIPER-related repos there are, today and historically. When you say that is not developing "the SORCER technology" ... you mean that they are not working on the same repo as everybody else (they have their own open-source repo and their own proprietary internal repo I was led to understand if memory serves). Also, since they are trying to build GUI tools that are above and beyond what ships with the core SORCER technoogy, they are absolutely developing the-generic-idea-of-SORCER-related technology, and belong in this general-purpose article.
  20. "...There is no any research paper on the SORCER technology from other places than the SORCER lab ( since that core technology is open..." Emphasis added; so, yes, as far as the core open-source system goes, wikipedia will definitely cover that, to the extent that the Reliable Sources cover it. For instance, since there is not var-oriented modelling in the open-source system, wikipedia needs to say as much. Since exertion-oriented-programming was first published in 2007 while SORCER was at TTU, wikipedia needs to say as much. Since the most-cited paper is the one on FIPER from 2000, wikipedia needs to say as much. We don't give subtopics/variants/whatever any more weight than the WP:RS give them, and we don't give them any less weight, either. We try to fairly summarize the subject, based on what the Reliable Sources say. If this does not make sense, Ahnoneemoos or myself can explain in more detail.
Sorry about the WP:WALLOFTEXT, as usual. SORCER-fka-FIPER is quite complex, but I'm starting to get the gist of it... although I'm still at the point where every question that is answered, leads me to ask two brand new questions. Speaking of which, I'll ask Pawel Rubach and/or Pawel Pacewicz to try and fill me in, since they may know the answers I seek. Danke for all the help. (talk) 00:06, 5 January 2014 (UTC)

This discussion has been circular since the start[edit]

Reply to re citation counts.[edit]

Hi 74,

There are a lot of article (and deleted articles) along the lines of SORCER, and if we followed the notability guidelines in WP:NSOFT all of them would be deleted: there just isn't coverage in popular magazines and books for these kinds of topics. If we went to the other extreme and allowed peer-reviewed publications to count equally with magazines and books, we'd be flooded with low-quality articles on topics where there are only a handful of (mostly-ignored) papers we can use as citations.

So somewhere between these two extremes is something sensible. My own rule of thumb is that if a paper describing a CompSci topic has 100+ citations, then I have no problem justifying an article: other people outside of that research group think the topic is important enough to cite. If I see lots of papers with <25 citations, that looks to me like a research group is cranking out papers, but the impact outside of the immediate group hasn't been sufficient to warrant an article. (Note that a highly-cited article that only mentions the topic does not establish notability.)

I assume you're aware of how to use google scholar to get citation counts; let me know if you're not.

Did that answer your questions? I'm happy to continue the conversation here or by email if you prefer. Garamond Lethet
23:54, 2 January 2014 (UTC)

Hadn't run across it before, but WP:NSOFT is a pretty reasonable essay, so although it doesn't trump WP:GNG, your point about pet projects that are WP:SPIP for some small research group is well-taken. For the benefit of myself, but more importantly, the others who may read later, here are the essentials as applied to the SORCER/exertions/etc topic. An ideal software article should include:
  1. A short overview. See "Talk:SORCER#paragraph one" rewrite attempt, above. SORCER is part grid-computing infrastructure, and part "other things", mainly used in the field of CAE/CAD/CAM for aerospace-engineers designing & simulating new vehicles/weapons/etc
  2. An assertion of notability. Nutshell: SORCER makes the aerospace weapon-systems design-process dramatically more speedy/flexible/radical, via software-only automated-design-optimization-for-hypersonic-flight plus real-world-final-capability-prediction-from-CAD-blueprints.
  3. ... Details: as of 2012, SORCER's grid-computing stuff permits automated non-linear analysis of aircraft-designs, while they are still virtual (i.e. in CAD virtual-blueprint form), and accomplishes this in the same timeframe that traditional linear efforts take; cite is DaytonThesis. (This means initial aerospace work can proceed without the need to physically prototype for wind-tunnel work, cutting out one-or-more loops from the incremental-design-process.)
  4. ... As of 2013, the USAF published some results on using SORCER to predict final manufacturing costs && final real-world offensive/defensive capabilities, again based purely on CAD-virtual-blueprints, no physical prototype required, no full-size physical testing of previous design-variants required; cite iosPress#1 conf-paper in print-proceedings. (This means that relatively radical designs can be virtually prototyped, at low cost, and then virtually "flown" in simulation, using SORCER to speed up both the design-work and the sim-work... end result is a ton of innovative pure-software designs can be jammed out in a relatively brief timespan, with predictions of final value/ROI directly useful to the top brass && civilian leadership that decides which advanced aerospace-systems get the funding.)
  5. ... Finally, although I don't understand Mandarin so I'm handicapped on summarizing the effort, there is a good sized R&D effort in China, which has been doing traffic-noise mapping since 2009 (around ten refereed academic papers), and there is now a 2012/2013/2014/2015 high-speed-rail effort funded by NSFC (not sure if any papers from this are non-classified).
  6. A software infobox with information on version number, developer, etc. This is tricksy, because SORCER has several independent forks (GE/Dassault/USAF/SorcerSoftOrg/Poland#1/Poland#2/PJIIT/Russian/Chinese ... that I know of!). Gerda_Arendt will be disappointed that the infobox is not likely to be very helpful to this article.  :-)   It makes sense to put the main open-source repo into the infobox, but I'm not sure if that is TTU, SorcerSoftOrg, or Poland#1 aka SorcerSoftCom-open-source-fork.
  7. An appropriate comparison/timeline of significant release versions. Yes, working on this, see my upmteen questions above.  :-)

I've collected some data from Google Scholar (see above 17:15, 3 January 2014 in the 'notability discussion' section and the 'neologism' and also perhaps at 17:33, 3 January 2014 section), and come to agree with Garamond that SORCER/FIPER is not expecially academically wikiNotable as computer science ... rather, it is academically wikiNotable as computer aided engineering, methinks. WP:NSOFT#Inclusion says we need:

  1. discussed in WP:RS as significant in its particular field (distributed collaborative computer aided engineering). Methinks we've got this, see notability-discussion above.
  2. subject of instruction at multiple schools; does not apply to software merely used in instruction. We have a bit of this ... Professor Sobolewski has taught SORCER at TTU, PJIIT, and in several other countries... there is a list of his visiting-professorships in his resume, which I copied at one point, I'll paste it when I find it again.
  3. multiple printed third-party manuals/tutorials/reviews. Nope! There is no such thing as SORCER For Dummies down at the local amazon store.  :-)
  4. published software that has been recognized (by reviewers) as having historical or technical significance by reliable sources. There are a couple lit-survey-papers, see details above, but SORCER is not reviewed in PC Magazine or anything like that.

Any one of the four is good enough. Also, WP:NSOFT says this: "It is not unreasonable to allow relatively informal sources for free and open source software, if significance can be shown." Since the spin-off during 2010, SORCER is officially open-source, and we have some evidence that the folks in Russia and China are using it... beyond what GoogleScholar shows. Additionally, we also have ongoing academic publications at conferences, and a new commercial entity. But methinks these latter two are not the story; the story is the CAE work done at government and university labs. (talk) 17:52, 3 January 2014 (UTC)

Hi 74. There is a lot of "above" to see. Can you give me the pointers to the lit-review papers? Thanks! Garamond Lethet
20:48, 3 January 2014 (UTC)
Garamond, the green boxes at 17:15, 3 January 2014 and also perhaps at 17:33, 3 January 2014 should have what you need, use ctrl+f. There is compsci lit by Sobolewski and co-authors, but there is more significant breadth in the CAE lit (for aerospace-engineering and industrial-engineering folks rather than EECS folks). HTH. (talk) 21:09, 3 January 2014 (UTC)
74, I'm sorry, I wasn't clear. Which one of these is the "lit survey paper"? Garamond Lethet
21:20, 3 January 2014 (UTC)
No, my apologies, totally my reading-comprehension failure, I thought you were asking for the list of papers, aka *my* personal "lit-research" via goog-skol. My brain autocorrected a typo you hadn't actually made.  :-)   As for your answer, mhhhhmmmm, maybe Pawelpacewicz will have a better chance at answering that more fully. The one *I* knew about (but see below for another I ran across a few hours ago) was a pair of U.Cranfield papers by Goteng et al from 2007, which is about the time SORCER was starting to publish heavily, and FIPER had just peaked and newly-published papers on FIPER were going downhill. This particular lit-review paper is not cited by others, according to GoogleScholar, but the folks involved are independent academics from another subdiscipline, and the publisher is impeccable, which is why Beavercreekful brought it up. Evolutionary Computing within Grid Environment, Springer, 2007, presented(?) at [Advances in] Evolutionary Computing for System Design, published in Studies in Computational Intelligence Volume 66, isbn 978-3-540-72376-9, pages 229-248, which is 19 pages total, not sure how much ink SORCER got. Authors are Ashutosh Tiwari, Gokop Goteng, Rajkumar Roy.
  Couple years later, Goteng got their PhD at U.Cranfield, and did a more serious lit-review, with more pages[9] on FIPER-or-SORCER therein; the main TTU papers on exertion-oriented-programming and SORCER were both in 2007/2008, but methinks Goteng just talked about FIPER, because SORCER was still closed-source in 2009 (opened in 2010). Development of a Grid Service for Multi-objective Design Optimisation, Gokop Goteng PhD, "lit review & industry survey ... of grid services ... [including FIPER-or-SORCER]", 2009, School of Applied Sciences, Cranfield University. Now, although Goteng's PhD has also gotten no goog-skol-cites so far, the thesis-cmte of 2009, and the peer-reviewers-slash-editors of 2007, made both Goteng-papers into an in-depth independent Reliable Source, distinct from anybody connected with SORCER/FIPER, and therefore counting towards WP:GNG. That said....

──────────────────────────────────────────────────────────────────────────────────────────────────── That said, we can also look at the wider literature in that specific research-niche, and see that SORCER/FIPER did not become the rock-star of Multi-objective optimization within Evolutionary computing within Algorithms within Computer Science (plus application to economics and also financial markets). Yet, at least. SORCER is definitely known in the subfield, though mostly by aerospace-engineering folks, at present. FIPER is older and thus better-known, including by the "top" guy in the Multi-objective Optimization, based on google-scholar-raw-hit-counts at least.

Deeper analysis of the 75-cites-total paper which mentioned both Sobolewski and Kolonay. It turns out to be a survey-paper on engineering design optimization, which is a superset of multi-objective optimization, which in turn is a superset of mechanical/industrial multi-objective optimization (where FIPER and SORCER fit into this picture). Recent advances in engineering design optimisation,[12] 2008, by R.Roy DeptMfg U.Cranfield, S.Hinduja AeroEng U.Manchester, R.Teti ProductionEng U.Naples. Stuff in the double-parens is my interpretation, take with a grain of salt.  :-)

As you can see from the redlinks inside the two most recent green boxen, wikipedia doesn't have any articles on the EECS-and-industrial-engineering subfield known as engineering design optimization, though we do have an article about the parent-field of Engineering_optimization ... which has four sentences. <long pause> Oven on the EECS side, doing a bit of searching for Kalyanmoy Deb and Carlos Artemio Coello Coello, the academic rockstars of this subfield, it turns out we *do* actually have an article on multi-objective optimization, but it spends 95% of the article on the mathematics of software-only MOO, as used by quants in the stock market (or the economics department). That said, it *does* mention in two paragraph at Multi-objective_optimization#Optimal_design that sometimes MOO is used in the real world, and gives one single ref, Optimization issues of the broke management system in papermaking by Ropponen Ritala Pistikopoulos in 2011 (total of 8 cites in goog-skol). Sigh. List_of_optimization_software has one (1) single aerospace package, for spaceships. Sigh.

  Anyhoo, the main point here is, SORCER-fka-FIPER was already of WP:NOTEWORTHY mention by K.Deb the rockstar of MOO, back in 2008; that guy has thousands and thousands of cites. Sobolewski and Kolonay are both in the lit-survey paper on the future of engineering design optimization as of 2008, and although the software they had both been jointly working on since the previous millenium was not specifically named, clearly they and their work are both smack-dab in the middle of #5 and #6 and #7. Are those WP:N refs for SORCER? No. Do with have a huge long list of WP:N peer-reviewed fact-checked serious professional academic papers which cover SORCER and FIPER and exertions and all that jazz, in depth? Absolutely.

  On three continents (so far!) FIPER and SORCER play a significant part in real-world mechanical/industrial CAE both classified and unclassified, the latter of which Roy et al claims was about 200 of the 1100 papers published in the engineering-design-optimization subfield back in 2008. The problem here is not that FIPER and SORCER are "too small" to be in wikipedia, the problem is that wikipedia doesn't have enough editors to make the obviously-necessary articles, and our wikiCulture doesn't seem to want those editors, either. We've been driving editors away since 2007, when the five bazillion rules were codified.[13] We have 30k active wikipedians making 5+edits/mo, trying to satisfy 500m unique readers/mo. We spend most of our time arguing about whether we can "allow" an article on something like SORCER... because we don't have the personnel to document *every* important research area... or because not *enough* newspapers have yet reported on the topic... or because *only* newspapers have reported on the topic... or because this or because that.

  The worst part is, we *have* the people who can fill the gaps, we have the experts, they came to us, and are obviously more than happy to do so.  :-/   If only we'll let them. Hope this helps. (talk) 16:45, 4 January 2014 (UTC)

First, a note on being an effective editor: if someone asks you for a citation, give them the citations. Not paragraphs. We're all volunteers here and we're all trying to shepherd dozens or hundreds of articles. This is your passion. I understand that. But the best way you can help us get the article to a better state is by making your replies succinct.
From what I'm seeing here, a FIPER article would be uncontroversial and the SORCER material could be contained within that. Would that be ok with you? Garamond Lethet
19:02, 6 January 2014 (UTC)