Jump to content

Talk:SORCER

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Pawelpacewicz (talk | contribs) at 12:09, 22 January 2014 (→‎paragraph one). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

note about archiving

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. 74.192.84.101 (talk) 18:02, 30 December 2013 (UTC)[reply]

notability and sourcing

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. 74.192.84.101 (talk) 18:02, 30 December 2013 (UTC)[reply]

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. 74.192.84.101 (talk) 19:24, 16 January 2014 (UTC)[reply]

PLEASE EDIT THESE SOURCE-EVALUATIONS DIRECTLY, TO FILL IN MISSING DETAILS. Thanks much.  :-)  74.192.84.101 (talk) 18:27, 13 December 2013 (UTC)[reply]

some WP:ABOUTSELF sources

Mwsobol#0

  1. sorcersoft.com (or maybe sorcer.com ??), company to market GUI systems built on top of open-source code from sorcersoft.org below, in Poland where Mwsobol teaches at PJIT

Mwsobol#1

  1. url == http://sorcersoft.org/publications/papers/2012/6.2012-5520.pdf
  2. title == "Efficient Supersonic Air Vehicle Analysis and Optimization Implementation using SORCER"
  3. collaborative university == Texas Tech University 2002-2009 , spun off as of 2010 into an open source project
AFRL / IOSPRESS x2 or x3

Shortname == iosPress#1 (there is also another one by the same author/publisher... I will add that later on).done Suggested as WP:RS to satisfy WP:NOTE.

  1. title == Physics-Based Distributed Collaborative Design for Aerospace Vehicle Development and Technology Assessment
  2. pages == 198-215
  3. url == http://ebooks.iospress.nl/publication/34808
  4. author == Raymond M. Kolonay
  5. possibly conflict == Director of MSTC/AFRL, an organization that is an enduser of Sorcer. Pawelpacewicz is of the opinion that therefore no COI exists; however, methinks AFRL is not just an enduser, but also the collaborator-slash-employer-slash-funder of the SORCER work (Professor Sobolewski among others... who is currently "Director of SORCER Lab in collab with AFRL/WPAFB and PL-JP Inst of IT"[1]), so this is somewhat of a grey area, Kolonay is a collaborator in SORCER research as well as an enduser... AFRL isn't just a typical customer in other words, cf the early history of Jeep vehicles during WWII. Background: the USAF is using Sorcer in their (aerospace-research) environment, and developing computational models to address the physics-based distributed collaborative design (i.e. aerospace-design-engineers using local exertion-scripts implemented via SORCER as the substrate-platform) for aerospace vehicle development.
  6. summary == One AFRL mission is to develop (and assess!) next-generation aerospace-system technologies i.e. fighters/bombers/missiles/etc. Currently, due to time/personnel/funding constraints, the tech-assessment work is traditionally achieved using empirical relationships and historical data associated with systems developed previously (i.e. earlier-generation fighters/bombers/missiles/etc)... this approach is fast, but not necessarily accurate, especially when neither empirical nor historical info exists! (The first version of a radical new bomber-design for instance.) Inaccurate assessment leads to poor USAF decisions about investment into future aerospace-systems. AFRL has an AerospaceSystemsDirectorate with the MultidisciplinaryScienceAndTechnologyCenter; these MSTC folks are under the author Kolonay. This group is creating tech-assessment-and-design-exploration apps/methods/processes, which are physics-based (the tech-assessment depends on weight/lift/drag/etc ... as opposed to historical data from wind tunnels and combat engagements and such ... whereas weight/lift/drag are known at CAD-design-time without needing to build a physical prototype). The aerospace-designers who work elsewhere in the USAF can work on their CAD-based designs, run SORCER-based apps that perform tech-assessment, and get quantitative estimates of cost/strength/firepower/etc (aka affordability/survivability/lethality/sustainability), which are the things USAF leadership && Congress uses to make funding-decisions. Basically, given merely an AutoCAD diagram of a radical new bomber-design, the MSTC tech-assessment app uses[vague]SORCER (how specifically?) to predict the quantitative real-world manufacturingCost/offensiveCombat/defensiveCombat/etc performance-characteristics of the hypothetical bomber, partly by running mission-simulations of various bomber-configs (different fuel-load crew-size weapon-selection whatnot). The new MSTC tech-assessment app takes the same amount of time as traditional tech-assessment. Aerospace-designers get a quantifiable usefulness-prediction-metric, repeated each time they incrementally adjust their CAD-design, and USAF leadership (and taxpayers) get better decision-making about funding for new aerospace-systems.
  7. publisher == iospress.nl
  8. was publication peer-reviewed aka refereed == Yes. By the conference board (see full list of 19-besides-Sobolewski in comment-section). Here you have the information about the committee: (https://www.engineersaustralia.org.au/20th-ispe-international-conference-concurrent-engineering/committee-information), And here you can find confirmation (at the bottom) that according to the rules of the conference proceedings each paper has to be peer reviewed: https://www.engineersaustralia.org.au/20th-ispe-international-conference-concurrent-engineering/presenter-information IOS Press confirms as well their peer-review process here:http://www.iospress.nl/service/authors/open-library-ios-press-open-access-option/ Here You have another organization which is using peer-review process by IOS Press: http://www.oapen.org/peerreview?page=ios
  9. url of iospress editorial board == Cees Bil, John Mo, Josip Stjepandić - You can find it on their page:http://ebooks.iospress.nl/book/20th-ispe-international-conference-on-concurrent-engineering
  10. is publisher independent == If I understand well your intention (correct), you would like to check if they are independent from authors-or-the-employers-of-authors of the SORCER work (correct). In my opinion the proof for this type of independency is the information on Wikipedia (https://en.wikipedia.org/wiki/IOS_Press) which shows that it was established 26 years ago, and that they are publishing approximately 90 international journals and releases and about 130 booktitles annually. (74 agrees with Pawelpacewicz... IOS press is not run by USAF nor any of the SORCER folks, but is an independent scientific publisher... however, interestingly enough, IOS Press does *not* provide their own professional editorial board, but rather, uses a subset of the peer-reviewers as their editors.) As such they’re not dependent from the author (correct) or any of the institutions for which the author works or had worked previously. (correct)
  11. is publisher a vanity press == Pawelpacewicz says: as an independent publisher of peer-reviewed scientific journal the publisher definitely doesn’t accept paid-for papers. 74 says, this seems to be mostly true. In fact the folks at IOS Press *do* require payment up front, as you can see in the link Pawelpacewicz provides, to the tune of a thousand euros per paper published. However, this is the business model of the publisher... they do not charge subscription-fees to the recipients of the papers (which is why wikipedians can see the full paper sans any paywall — the license is even Creative Commons of some sort). <grin> All papers that IOS Press publishes this way are from peer-reviewed scientific conferences (in this case the 20th ISPE ICCE), and the editorial board is also from academia slash industry (in this case RMIT*2 plus a firm in Germany). IOS is a member of STM, which also includes AAAS / ACS / AIP / AMS / AMA / APS ... that was just the first few which jumped out at me.  :-)   Seems legit; wikipedia already has about 20 computing-articles which cite iospress, plus about 20 medical-articles.
  12. was book printed, or ebook only == both: http://www.iospress.nl/book/20th-ispe-international-conference-on-concurrent-engineering/
  13. date == if you click on the link right to “Ebook” You will go to page: http://ebooks.iospress.nl/book/20th-ispe-international-conference-on-concurrent-engineering and there is info that it was published in 2013

Shortname == iosPress#2 (Mwsobol#2)

  1. url == http://ebooks.iospress.nl/publication/34826 (here is the TOC[2] for the proceedings)
  2. title == Parametric Mogramming with Var-Oriented Modeling and Exertion-Oriented Programming Languages
  3. authors == Michael Sobolewski / Scott Burton / Raymond Kolonay
  4. author homes == SORCER Soft / ((unknown)) / MTSC of AFRL
  5. editors == Cees Bil / John Mo / Josip Stjepandić
  6. editor homes == RMIT University Australia / RMIT University Australia / PROSTEP AG Germany
  7. editorial review == 2013 Proceedings of the 20th ISPE International Conference on Concurrent Engineering; 978-1-61499-301-8 (print) | 978-1-61499-302-5 (online)
  8. peer review == 20th ISPE ICCE board (see list of twenty in the comments)
  9. publisher == IOS Press
  10. possibly conflict == primary author is inventor of SORCER & FIPRE, third author is director of MTSC at AFRL which collaborates with SorcerSoft ... but editors and most peer-reviewers have no conflicts
20th IPSE ICCE peer-reviewers
reviewer at 20th ISPE ICCE[] reviewer's home university-slash-org conceivableaka possible COI
Ahmed Al-Ashaab Cranfield University, UK
Amy Trappey National Tsing Hua University, Taiwan
Cees Bil RMIT University, Australia
Eric Simmon NIST, USA maybe? NIST funded FIPRE, the predecessor of SORCER, was Simmon involved?
Essam Shehab Cranfield University, UK
Geilson Loureiro INPE, Brazil
Georg Rock University of Applied Science, Germany
Jerzy Pokojski Warsaw University of Technology, Poland maybe? Sobolewski previously taught here; possible coworker/student? - No COI - it is a completely different faculty. He works at the Faculty of Automotive and Construction Machinery Engineering (http://ipbm.simr.pw.edu.pl/prac/pokojski_jerzy.htm) Prubach (talk) 00:08, 9 January 2014 (UTC)
John Cha Beijing Jiaotong University, China
John Mo RMIT University, Australia
Josip Stjepandic PROSTEP, AG, Germany
Kazuo Hiekata University of Tokyo, Japan
Mike Sobolewski TTU, Texas, USA YES, works w/ Kolonay && funds FIPRE/SORCER
Nel Wognum Wageningen University, The Netherlands
Parisa Ghodous University of Lyon, France
Rajkumar Roy Cranfield University, UK
Ricardo Goncalves UNINOVA, Portugal
Richard Curran Delft University of Technology, The Netherlands meh ... IOS Press recently bought out Delft University Press
Shuichi Fukuda Stanford University, USA
Shuo-Yan Chou Peking University, China
TBD sources which need sorting and filling

Kazumo#12 / Mwsobol#3

  1. url == http://www.scirp.org/journal/PaperInformation.aspx?paperID=22393
  2. title == "Unified Mogramming with Var-Oriented Modeling and Exertion-Oriented Programming Languages"

Mwsobol#4

  1. url == http://repositories.tdl.org/ttu-ir/handle/2346/15257
  2. title == Max Berger's research (from Germany), a federated filesystem developed for SORCER

Kazumo#11

  1. author == M. Sobolewski
  2. editor == Anneke Kleppe
  3. chapter title == Chapter 3 "Languages and Mograms"
  4. book title == Software Language Engineering: Creating Domain-Specific Languages Using Metamodels

132

  1. url == ??
  2. title == ?? (won best-paper award)
  3. authors == Dan Kerrn, M.Sobolewski

Kazumo#13 (this is a wiki methinks?)

  1. url == http://www.intechopen.com/books/howtoreference/advances-in-computer-science-and-it/metacomputing-with-federated-method-invocation

Pawelpacewicz#73

  1. url == http://arc.aiaa.org/doi/abs/10.2514/6.2012-5520
  2. author1 == Scott Burton, American Optimization, LLC; Manager Ph.D. AIAA SEnior Member
  3. author2 == Edward Alyanak, Air Force Research Laboratory; Project Engineer Ph.D. AFRL/RQSA AIAA Senior Member
  4. author3 == Raymond Kolonay, Air Force Research Laboratory; Principal Engineer Ph.D. AFRL/RQSA AIAA Associate Fellow
  5. abstract == describes SORCER's application in ESAV project
NAN LI x3 or x4 of Beijing

Shortname == N.Li 2008. journal paper (Kozamo#1)

  1. url == http://www.cnki.com.cn/Article/CJFDTotal-HBGB200804012.htm (in Chinese)
  2. authors == ZHANG Rui-hong, LI Nan, CHA Jian-zhong, LU Yi-ping (张瑞红; 李楠; 查建中; 陆一平).
  3. type of source == journal paper w/ keyword SORCER
  4. title == A collaborative engineering design environment based on SOA (基于SOA的工程协同设计环境).
  5. publisher == (Chinese) Journal of Hebei University of Technology, vol.37, no.4 (河北工业大学学报),
  6. date == April 2008 (2008年04期),
  7. pages == 5 (pp.40-44)

Shortname == N.Li 2009. PhD thesis (Kozamo#6)

  1. url == http://cdmd.cnki.com.cn/Article/CDMD-10004-2010040776.htm
  2. authors == Li Nan (李楠).
  3. type of source == PhD Dissertation
  4. title == A design activity modelling method for distributed design resources integration (一种用于分布式设计资源集成的设计活动建模方法) ,
  5. publisher == Beijing Jiaotong University (北京交通大学)
  6. date == 2009-10-01
  7. pages == ??pgs??

Shortname == N.Li 2011_A. journal paper (Kozamo#3_A)

  1. url == ??website??
  2. authors == Nan Li; Bin Liu; Tao Feng
  3. type of source == conference paper w/ keyword SORCER
  4. title == A Loosely-Coupled Platform for Urban Traffic Strategic Noise Mapping,
  5. publisher == Proceedings of 2011 World Congress on Engineering and Technology, Vol. 07
  6. date == ??year?? (~2011)
  7. pages == ??pgs??

Shortname == N.Li 2011_B. journal paper (Kozamo#3_B)

  1. url == http://link.springer.com/chapter/10.1007/978-3-642-34522-7_20?no-access=true
  2. authors == Wensheng Xu, Nan Li,
  3. type of source == conference paper w/ keyword SORCER
  4. title == A Loosely-Coupled Platform for Urban Traffic Strategic Noise Mapping,
  5. publisher == Proc 2012 Int'l Conf on IT & SW Engin — Lecture Notes in EE, Vol.211,
  6. date == 2013,
  7. pages == 8 (pp175-182)

Shortname == N.Li 2011_C. conference paper (Kozamo#9)

  1. url == ??website??
  2. authors == Nan Li
  3. type of source == conference paper w/ keyword SORCER
  4. title == Resources Integration and Binding in Distributed Collaborative Design Process.
  5. publisher == Proceedings of the First International Conference on Networking and Distributed Computing, Hangzhou, China
  6. date == 2011
  7. pages == ??pgs??

Shortname == ICDMA'11 aka N.Li 2011_D. Suggested as WP:RS to satisty WP:NOTE.

  1. url == http://ieeexplore.ieee.org/xpl/articleDetails.jsp?tp=&arnumber=6051863&queryText%3DA+SOOA+Based+Distributed+Computing+Mechanism+for+Road+Traffic+Noise+Mapping
  2. authors == Nan Li ; Tao Feng ; Bin Liu
  3. affiliation == Sch. of Mater. & Mech. Eng., Beijing Technol. & Bus. Univ., Beijing, China ;
  4. title == A SOOA Based Distributed Computing Mechanism for Road Traffic Noise Mapping
  5. pages == 4 pages devoted (pg109-112) to this paper, 1402 pages total in the proceedings (two softcover volumes)
  6. abridged abstract == Current traffic noise mapping systems are not ideal for distributed computing in dynamic network. This paper investigates the approach and mechanism of distributed noise map generation based on SOOA. SORCER is employed to build a highly flexible distributed network services space. After that, a SOOA-based computer-aided noise-mapping system is presented.
  7. publisher#1 == 2011 Second International Conference on Digital Manufacturing and Automation (ICDMA)
  8. publisher#2 == TBD? (IEEE Press maybe?) (IEEE Press maybe?) IEEE – please take a look here:http://www.proceedings.com/13060.html in the product description,another prove you can find here:http://toc.proceedings.com/13060webtoc.pdf (they are official publisher and also methinks the sponsor of the conference)
  9. was publication peer-reviewed aka refereed by conference's independent science-board == On the conference’s web page you can find info describing the fact that papers “… are subject to both review and editing.”: http://www.icdma.org/paper-submission
  10. was publication fact-checked (or peer-reviewed) by ICDMA editorial-staff == Please see above
  11. was publication fact-checked (or peer-reviewed) by IEEE editorial-staff == Confirmation of peer review process by IEEE is described here: http://www.ieee.org/publications_standards/publications/authors/publish_benefits.html "conference papers ... undergo a thorough peer review process before acceptance for publication or presentation ... The reader or conference attendee is assured the research published is strong and credible."
  12. url of Proceedings of the ICDMA editorial/referee policy == Please see above http://www.icdma.org/paper-submission
  13. is at least one publisher independent == YES not only one: IEEE, ICDMA
  14. is publisher a vanity press == IEEE is a very reputable publisher, in particular, for computer science papers and journals and as such is definitely not a vanity press. Please take a look onhttps://en.wikipedia.org/wiki/Institute_of_Electrical_and_Electronics_Engineers
  15. conf_date == 5th-7th August 2011 (in Zhangjiajie, Hunan, China) ... published the same year
  16. doi == http://dx.doi.org/10.1109/ICDMA.2011.34
  17. isbn == 978-1-4577-0755-1 (print) , 978-0-7695-4455-7 (ebook)
  18. cited by == n/a ... "as provided in real-time from CrossRef™, Scopus™ and Web of Science™."

Shortname == N.Li 2012. journal paper (Kozamo#2)

  1. url == http://mall.cnki.net/magazine/Article/JSJY201208019.htm (in Chinese)
  2. authors == LI Nan, FENG Tao, LIU Bin1, LI Xian-hui, LIU Lei (李楠; 冯涛; 刘斌; 李贤徽; 刘磊).
  3. type of source == journal paper w/ keyword SORCER
  4. title == A distributed computing method for traffic noise mapping based on Service Object-Oriented Architecture (基于面向服务对象体系结构的交通噪声地图分布式计算方法).
  5. publisher == (Chinese) Journal of Computer Applications, vol.32, no.8 (计算机应用),
  6. date == August 2012 (2012年08期),
  7. pages == 4 (pp.2146-2149)
U.Cranfield in the UK

Shortname == Cranfield 2007. chapter (Beavercreekful#1)

  1. url == http://link.springer.com/chapter/10.1007%2F978-3-540-72377-6_10
  2. chapter title == Evolutionary Computing within Grid Environment
  3. book title == Advances in Evolutionary Computing for System Design Studies in Computational Intelligence, Vol.66
  4. date == 2007
  5. pages == pp 229-248
  6. publisher == Springer Verlag
  7. abstract == reviews SOA's including SORCER & FIPRE
RUSSIAN NEWSPAPERS x3

Beavercreekful#3

  1. url == http://vestnik_old.ulsu.ru/issues/878/4
  2. title == Техас готов к сотрудничеству" (Texas is Accepting Research Collaboration)
  3. type of source == Russian weekly newspaper
  4. publisher == Вестник - Областная еженедельная газета
  5. details == in Ulyanovsk Russia, where the largest Russian air vehicles are designed and manufactured, also the home of the Ulyanovsk State University

Beavercreekful#4

  1. url == http://vestnik.ulsu.ru/19-1145-07-iyunya-2013/takzhe-chitayte/sorcer-nam-v-pomosch
  2. title == "SORCER нам в помощь" (SORCER helps us)
  3. type of source == Russian weekly newspaper
  4. publisher == Вестник - Областная еженедельная газета
  5. date == June 7, 2013 (#19)
  6. details == in Ulyanovsk Russia, where the largest Russian air vehicles are designed and manufactured, also the home of the Ulyanovsk State University

Beavercreekful#9

  1. url == http://www.ssau.ru/files/editions/polet/2007/13-14-2007.pdf
  2. title == В СГАУ выступал профессор Техасского университета
  3. publsher == полет N13􏰁14, 30 мая 2007 г. инновационная образовательная программа
CHINESE EDU NEWS x4

Beavercreekful#5

  1. url == http://www.news.uestc.edu.cn/NewsRead.aspx?newsID=57207
  2. title == "Service oriented computing environment for BCA"
  3. publisher == News Center for UESTC, China
  4. date == 2013-03-21

Beavercreekful#6

  1. url == http://mece.njtu.edu.cn/hzjl/gjhz/6752.htm
  2. title == “SORCER and the Service-oriented Programming Model”

Beavercreekful#7

  1. url == http://mse.hust.edu.cn/news.php?id=13279
  2. author == 著名计算机专家Michael Sobolewski教授来我院学术交流,
  3. date == 发布时间:2013-03-01 发布人: 浏览次数:823

Beavercreekful#8

  1. url == http://www.hustcad.com/content.aspx?typeid=156&id=625
  2. author == Michael Sobolewski教授来我公司进行学术交流
  3. publisher == Tianyu Soft, China Industrial Application Software
PHD THESIS x4 (cf N.Li 2009 above)

Shortname == G.Goteng 2009. PhD thesis (Beavercreekful#2)

  1. url == https://dspace.lib.cranfield.ac.uk/bitstream/1826/4423/1/Gokop_Goteng_thesis_2009.pdf
  2. title == Development of a Grid Service for Multi-objective Design Optimisation
  3. type of source == PhD thesis
  4. author == Gokop Goteng
  5. abstract == lit review & industry survey ... of grid services ... (including SORCER)
  6. date == 2009
  7. publisher == Cranfield University (School of Applied Sciences)

Shortname == J.Yu 2010. PhD thesis (Kozamo#7)

  1. url == http://cdmd.cnki.com.cn/Article/CDMD-10004-1011102578.htm
  2. authors == Yu Jiaqing (于加晴).
  3. type of source == PhD Dissertation
  4. title == Research on the design process reuse method based on decomposition (基于分解的设计过程重用方法研究) ,
  5. publisher == Beijing Jiaotong University (北京交通大学)
  6. date == 2011-06-01
  7. pages == ??pgs??

Shortname == L.Kong 2013. PhD thesis (Kozamo#8)

  1. url == http://cdmd.cnki.com.cn/Article/CDMD-10004-1013279659.htm
  2. authors == Kong Lingjun (孔令军).
  3. type of source == PhD Dissertation
  4. title == Research on servitization method of design resources in the cloud manufacturing environment (云制造环境下的设计资源服务化方法研究) ,
  5. publisher == Beijing Jiaotong University (北京交通大学)
  6. date == 2013-06-01
  7. pages == ??pgs??

Shortname == DaytonThesis. Ph.D. thesis (more than one?) from from University of Dayton

  1. url == https://etd.ohiolink.edu/ap:10:0::NO:10:P10_ACCESSION_NUM:dayton1335270317
  2. permalink == http://rave.ohiolink.edu/etdc/view?acc_num=dayton1335270317
  3. title == Incorporation of Computational Fluid Dynamics into Flight Vehicle Preliminary Design
  4. author == Ernest D. Thompson
  5. thesis == Doctor of Philosophy (Ph.D.)
  6. publisher == University of Dayton and OhioLINK
  7. home == University of Dayton
  8. committee == Franklin E. Eastep PhD (CmteChair & DirectAdvisor), Jose A. Camberos PhD, Raymond M. Kolonay PhD, Ramana V. Grandhi PhD, Rolf Sondergaard PhD
  9. cmte homes == Prof Emeritus MechE&AeroE, AdjunctProf MechE&AeroE, AdjunctProf MechE&AeroE, DistinguishedProf Mech&MaterialsE Wright State, SeniorResearcher in TurbineBranch of AFRL PropulsionDirectorate
  10. also signed off by == John G. Weber PhD (AssociateDean for U.Dayton School of Engineering), Tony E. Saliba PhD (WilkeDistinguishedProf & Dean for U.Dayton School of Engineering)
  11. date == May 2012
  12. possible COI == Dayton is near Wright-Patterson AFB, the USAF facility where AFRL and SORCER are being created, Kolonay is adjunct prof @ dayton, director of MTSC @ afrl, and on thesis cmte. Grandhi supervised the WrightThesis, see above, but is prolly independent unless he get AFRL funding. Sondegaard works for AFRL, and is prolly an actual/potential enduser of SORCER for turbine-design. Seems pretty independent, by typically-insular academic standards, and as a PhD thesis, can be used with care.
  13. pages == 261 (content in 243 pages ... around 12 pages specifically about SORCER)
  14. subject == Aerospace Engineering (Air Vehicle Design)
  15. MLA == Thompson, Ernest. "Incorporation of Computational Fluid Dynamics into Flight Vehicle Preliminary Design." Electronic Thesis or Dissertation. University of Dayton, 2012. OhioLINK Electronic Theses and Dissertations Center. 25 Dec 2013.
  16. license == This material is declared a work of the U.S. Government and is not subject to copyright protection in the United States (aka public domain... can quote long passages if we wish)
details of DaytonThesis w.r.t. SORCER/exertions/SOOA

abstract == Nonlinear, high fidelity aerodynamic analysis methods are considered computationally expensive and impractical for use in the preliminary design environment. In lieu of nonlinear methods, linear aerodynamic methods are utilized in the execution of design tasks because of their computational efficiency. Linear codes are considered accurate in low Mach number flight regimes where aerodynamics is generally linear but are not accurate in transonic flight regime due to the simplified assumptions that are required by such codes. This investigation demonstrates that nonlinear aerodynamic analysis methods are necessary when performing design tasks in the presence of nonlinear phenomena. To reduce the cost of using nonlinear aerodynamic analysis, the velocity transpiration boundary condition was employed to simulate surface deformations and control surface deflections. Observations showed velocity transpiration offers significant computational savings when compared to mesh motion enabled codes. To improve turnaround, a distributed computing framework wasadopted to distribute workload and information storage across a network. A comparative design study was carried out comparing linear and nonlinear analysis tools in design. A rectangular wing's structural mass was optimized to perform both a roll and pull-up maneuver while subjected to rolleffectiveness and skin stress constraints. At a subsonic design point, the linear and nonlinear tools produced similar designs. However, at a transonic design point, the tools produced significantly different designs. The addition of aerodynamic shape variables to the design space at the transonic design point led to a further enhanced design. The results of this study reaffirm the notion that nonlinear high-fidelity aerodynamic analysis methods must be utilized when designing vehicles that will operate in nonlinear regimes. Further, several methods were demonstrated that could reduce the cost of using nonlinear analysis methods.

SORCER-related technology is covered in reasonable depth: 3 pages in ch#4, 3 pages in ch#5, 6 pages in ap#G. which is a total of a dozen pages out of 243 pages of content, aka about 5% of the thesis. That said, sorcer played *the* key part, allowing the non-linear analysis to be computationally feasible. Exertions are mentioned on about 50% of those dozen pages (and are implicit in most of the rest of them), and services were mentioned in 80% of the dozen (and very implicit in all of them). Kolonay is on the thesis cmte, gets seven bibliography entries (out of 73 total aka ~10%), is credited as author of four SORCER-packages (plus helped write a bit of new code specifically for this thesis). Sobolewski is mentioned thrice: in the bibliography, as the creator of SORCER, plus credit for writing a few of the classes used in the thesis (perhaps specifically *for* this thesis project? unclear).

selected entries of the 73-entry bibliography.

  1. N. S. Khot, F. E. Eastep, and R. M. Kolonay. Method for Enhancement of the Rolling Maneuver of a Flexible Wing. Journal of Aircraft, 35(5):688{694, September-October 1998
  2. G. Anderson, R. Kolonay, and F. Eastep. Control-Surface Reversal in the Transonic Regime. Journal of Aircraft, 35(5):688{694, September-October 1998
  3. R. Kolonay and M. Dindar. Lockheed Martin 1999 Aeroelasticity Shared Vision Project Final Report. Technical report, General Electric Corporate Research and Development, 1999
  4. P. C. Chen, D. Sarhaddi, and D. D. Liu. Volume 4; ZAERO Theoretical Manual. Wright-Patterson Technical Report 3052, AFRL, Wright-Patterson Air Force Base, OH, February 1999
  5. R. Kolonay, M. Dindar, M. Love, and A. De La Garza. A Methodology of Large Scale Compuational Aeroelasticity For The MDA/MDO Environment. AIAA Paper 2000-4789, AIAA, 2000
  6. F. Eastep, G. Anderson, P. Beran, and R. Kolonay. Control Surface Reversal in the Transonic Flight Regime Including Viscous Effects. Journal of Aircraft, 38(4):653{663, Jul.-Aug. 2001
  7. Air Force Research Laboratory, WPAFB, OH. Air Vehicles Unstructured Solver User's Manual, January 2005
  8. Raymond M. Kolonay and Franklin E. Eastep. Optimal Scheduling of Control Surfaces on Flexible Wings to Reduce Induced Drag. Journal of Aircraft, 43(6):1655{1661, November-December 2006
  9. Ernest Thompson, Raymond Kolonay, Franklin Eastep, and Jose Camberos. Aeroelastic Analysis with Transpiration Enabled Euler Flow Solver. AIAA Paper 2007-2331, AIAA, April 2007. 48th AIAA/ASME/ASCE/AHS/ASC Structures, Structural Dynamics, and Materials Conference, Waikii, Hawaii.
  10. Michael Sobolewski. Handbook On Business Information Systems, chapter Chaper 35 Object-Oriented Metacomputing with Exertions. World Scientific Publishing Co. Ore. Ltd., Toh Tuck Link, Singapore, 2010

Appendix G, on printed-page 230-245, is half-a-dozen pages explaining how SORCER works, what service-oriented means, and what exertions are. Recommended, and as pub-domain, we can reuse it if we like.

As for the aerospace-design portion of the thesis, SORCER is specifically covered in the chapters on efficient automated numerical optimization of the wing-shape during the design-phase, as well as in the conclusions (nonlinear optimization is made possible by the efficiency gains of SORCER's grid-computing network-parallelism... this is not especially helpful at Mach 0.50 speed, but it hands-down results in a better wing-design for transonic flight at Mach 0.89).

chapter four, distributed design optimization, printedPage73==pdfPage90 ...a grid-computing environment... Within SORCER the numerical optimizer and the aeroelastic solvers were exposed as services on a network. SORCER reduced the computational expense of using nonlinear aerodynamic analysis method within the preliminary design environment by allowing the computational workload to be distributed across a network of computers. SORCER allowed for multiple copies of services to be available for use when executing a design study. This effectively reduced the computational expense of using a nonlinear aerodynamic method in the preliminary design environment.

chapter four, distributed design optimization, printedPage75&76==pdfPage92&93 The numerical optimization code utilized in this investigation was Design Optimization Tools (DOT). It is developed and maintained by Vanderplaats R&D Inc. The strategy used to solve the optimization problem was constructed within SORCER. ...the code determines ... if [automated] design investigation has converged and if an optimal [wing] design has been discovered.

chapter five, conclusions, printedPage111&112==pdfPage128&129

The last set of tasks performed in this investigation involved executing the transpiration enabled aeroelastic solver in the performance of preliminary design tasks. To further improve the computational effciency of the transpiration enabled nonlinear aeroelastic solver, a preliminary design environment was constructed in SORCER. SORCER grid-computing capabilities allowed for design problems to scale across the computation resources available on a network of computers. In the execution of multidisciplinary design optimization studies, the velocity transpiration enabled computational aeroelastic solver proved quite serviceable. The solver generated optimal structural designs at a subsonic design point of Mach 0.50 and transonic design point of Mach 0.89.

The designs developed using the [SORCER-based] nonlinear aerodynamic method compared to design produced using [traditional] linear aerodynamics. At subsonic design point [Mach 0.50] the optimal designs produced by the linear and nonlinear methods were very similar there was only 14.69 slugs difference in structural mass. However, at transonic design point [Mach 0.89] the structural design were very different. The design generated using the linear aerodynamic method did not properly account for the presence of a shock wave... ...proof that linear design tools produced completely different designs than nonlinear tools in a nonlinear flight regime. ... If a designer chose to use the design obtained using linear aerodynamic analysis methods as the basis of a detailed design or prototype, the end result could be a costly redesign of the structure because the design failed to account shock wave effects.

Through the performance of the design optimization study portion of this investigation, it was demonstrated how distributed computing can be used to accelerate computational analysis through coarse parallelization of computational effort. Analysis tools were deployed across a network of computers as services. Information was transported from analysis service to analysis service via web servers, network proxies. Data was passed within service context data structures. SORCER's framework allowed for analysis tasks to be executed concurrently or sequentially depending [on] data dependencies. The design process was accelerated through the exploitation of this parallelism. A unique aspect of this work was the fact that the optimization design strategy was implemented within the design framework. One programs the network as oppose to programming individual computer systems. The framework calculated exact sensitivities via finite difference directly, selecting the appropriate network services to dynamically compute a gradient or function evaluations. The framework permitted some failure recovery in the analysis. Code was implemented to check for corrupt output. Intermediate results were archived in Java objects.

Through execution of this investigation several ideas could be implemented to improve computational efficiency of nonlinear CFD [computational fluid dynamics] in the preliminary design environment.

page113... paraphrasing: explains how greater performance could be achieved, by rewriting the CFD and CSD apps (computational fluid & structural dynamics) to be more granular, which would permit SORCER to expose subcomponents thereof as services in a parallelized pipeline (finer-grained parallelism rather than the coarse-grained parallelism actually used in the thesis project)

page113, quoting: SORCER could offer a computation advantage over the conventional analysis codes... for very large problems SORCER may offer computational advantage over the message-passing interface currently used by the CFD solver to parallelize analysis effort.

MASTERS THESIS x3

Shortname == A.Liu 2010. master's thesis (Kozamo#4)

  1. url == http://cdmd.cnki.com.cn/Article/CDMD-10004-2010260506.htm
  2. authors == Liu Anjun (刘安军).
  3. type of source == Master's Dissertation
  4. title == Research on encapsulation method of finite element analysis service in Concurrent Engineering (并行工程中基于SOA的有限元分析服务封装技术研究),
  5. publisher == Beijing Jiaotong University (北京交通大学)
  6. date == 2010-06-01
  7. pages == ??pgs??

Shortname == W.Wang 2011. master's thesis (Kozamo#5)

  1. url == http://cdmd.cnki.com.cn/Article/CDMD-10004-1012355719.htm
  2. authors == Wang Wei (王伟).
  3. type of source == Master's Dissertation
  4. title == Research of testing process modelling and management of weapon equipment systems (武器装备系统测试过程建模与管理系统研究),
  5. publisher == Beijing Jiaotong University (北京交通大学)
  6. date == 2011-05-26
  7. pages == ??pgs??

Shortname == WrightThesis. Ph.D. Master's thesis (more than one?) from Wright State university

  1. overview_url == https://etd.ohiolink.edu/ap/10?222745293673013::NO:10:P10_ETD_SUBID:86171
  2. fulltext_URL ==https://etd.ohiolink.edu/ap:0:0:APPLICATION_PROCESS=DOWNLOAD_ETD_SUB_DOC_ACCNUM:::F1501_ID:wright1316463759,attachment
  3. possible COI == Wright State is next door to Wright-Patterson AFB, the USAF facility where AFRL and SORCER are being created (some of the thesis-committee is possibly WP:COI ... student may work there now). Grandhi is a prof at Wright (both theses), Kolonay is dir of AFRL (both theses), Taylor is TBD.
  4. To use a PhD thesis as a wikiReliable_Source, the committee which reviews the thesis must be independent...
  5. ...and ideally, the published thesis itself must be widely cited.
  6. Is this the case at Wright State? Is this the case at U.Dayton? Please advise.
  7. Interestingly, although this is Master's rather than PhD, there was a committee of three (not just the one advisor); the Dayton thesis had a cmte of five.
  8. author == Karkada Nagesha Aithala
  9. title == A Collaborative Computational Framework for Multidisciplinary and Reliability-based Analysis and Optimization Using SORCER
  10. pages == 85 (content in 62 pages ... 30 pages specifically about SORCER)
  11. date == Finalized 16 Sept 2011
  12. field == Mechanical Engineering (also AeroE & CompE & CompSci)
  13. signed off by == Ramana V. Grandhi PhD (thesis director aka advisor), George P. G. Huang PhD (Mech&MaterialsE Chair), Andrew T. Hsu PhD (School of Graduate Studies Dean)
  14. final examination cmte == Ramana V. Grandhi PhD (see above), Raymond M. Kolonay PhD (AFRL), Ronald F. Taylor PhD (TBD?)
SUPERGRANTS x3 or x4

Shortname == NIST

  1. funding agency == NIST/ATP (USD$21M)
  2. title == FIPER project
  3. universities == Ohio + Stanford
  4. corporations == GE (GE GRC && GE Aviation) + BFGoodrich + Parker Hannifin + Ohio Aerospace Institute + Engineous Software

Shortname == USAF

Shortname == NSFC 2012. quad-year R&D grant (Kozamo#10)

  1. url == ??website??
  2. authors == (potentially... Kozamo et al.)
  3. type of source == (classified? TBD? high-speed-railway equipment)
  4. title == Research on manufacturing resource integration and coordination management based on SOOA in cloud manufacturing environment
  5. publisher == National Science Foundation of China project#51175033 (NSFC)
  6. date == 2012/2013/2014/2015
  7. pages == ??pgs??

Shortname == Ulanyovsk(sp) rumours

notability and sourcing, further discussion thereof

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

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")

Here is the full list of papers that GoogleScholar thinks are important, organized by author.

rank/A googHit cites notes title author,year

Sobolewski

  1. 4 43 . Federated P2P services in CE environments M Sobolewski - Advances in Concurrent Engineering, 2002
  2. 18 36 ++. (s) SORCER: Computing and Metacomputing Intergrid. M Soblewski - ICEIS (3-1), 2008 -
  3. 12 24 ++. (eop) Exertion oriented programming M Sobolewski - IADIS, 2008 -
  4. 13 21 ++. (f)Zhao Context model sharing in the FIPER environment S Zhao, M Sobolewski - Proc. of the 8th Int. Conference on Concurrent …, 2001 -
  5. 6 19 . Lapinsk Managing notifications in a federated S2S environment M Lapinski, M Sobolewski - Concurrent Engineering, 2003 - cer.sagepub.com
  6. 1 19 ++. (f) FIPER: The federated S2S environment M Sobolewski - JavaOne, Sun's 2002 Worldwide Java Developer …, 2002 - 211.68.71.80
  7. 11 16 . (fmi) Metacomputing with federated method invocation M Sobolewski - Advances in Computer Science and IT, 2009
  8. 8 15 ++. (eop) Federated method invocation with exertions M Sobolewski - … of the International Multiconference on ISSN, 1896 - proceedings.fedcsis.org
  9. 7 13 ++. (eop) Federated collaborations with exertions M Sobolewski - … Technologies: Infrastructure for Collaborative …, 2008 - ieeexplore.ieee.org
  10. 24 11 . Rubach Dynamic SLA negotiation in autonomic federated environments P Rubach, M Sobolewski - On the Move to Meaningful Internet Systems: …, 2009 - Springer
  11. 27 11 . Rubach Autonomic SLA management in federated computing environments P Rubach, M Sobolewski - Parallel Processing Workshops, …, 2009 - ieeexplore.ieee.org
  12. 30 11 ++. (eop) Object-oriented metacomputing with exertions M Sobolewski - Handbook On Business Information Systems, 2010 - mfile.narotama.ac.id
  13. 32 8 ++. (eop) Exerted enterprise computing: from protocol-oriented networking to exertion-oriented networking M Sobolewski - On the Move to Meaningful Internet Systems: OTM …, 2010 - Springer
  14. 33 6 . Turner FICUS—A federated service-oriented file transfer framework A Turner, M Sobolewski - Complex Systems Concurrent Engineering, 2007 - Springer
  15. 46 5 ++. (eop) Provisioning Object-oriented Service Clouds for Exertion-oriented Programming. MW Sobolewski - CLOSER, 2011 -
  16. 55 4 . Object-Oriented Service Clouds for Transdisciplinary Computing M Sobolewski - Cloud Computing and Services Science, 2012 - Springer
  17. 43 3 . Hard File Location Management in Federated Computing Environments C Hard, M Sobolewski - International Journal of Recent Trends in …, 2009 -

Kolonay

  1. 10 74 ++: Röhl A federated intelligent product environment PJ Röhl, RM Kolonay, RK Irani, M Sobolewski… - AIAA-2000-4902, 8th …, 2000 - Citeseer
  2. 5 39  : Kolonay Federated grid computing with interactive service-oriented programing M Sobolewski, RM Kolonay - Concurrent Engineering, 2006 - cer.sagepub.com
  3. 20 24  : Kolonay Grid interactive service-oriented programming environment R Kolonay, M Sobolewski - Concurrent Engineering: The Worldwide …, 2004 -
  4. 29 7 ++: SORCER SORCER for Large Scale, Distributed, Dynamic Fidelity Aeroelastic Analysis & Optimization RM Kolonay, M Sobolewski - International Forum on Aeroelasticity and Structural …, 2011
  5. 54 7 Burton Turbine Blade Reliability-based Optimization Using Variable-Complexity Method SA Burton, R Tappeta, RM Kolonay… - & Proceedings 저널· …, 2002 - arc.aiaa.org
  6. 21 6 ++ Sampath 2D/3D CFD Design Optimization Using the Federated Intelligent Product Environment (FIPER) Technology R Sampath, R Kolonay - 2002 - arc.aiaa.org
  7. 45 4 Tappeta Application of approximate optimization to turbine blade design in a network-centric environment RV Tappeta, RM Kolonay, S Burton - … 저널· 프로시딩즈| 기술보고서| 해외 …, 2002 - arc.aiaa.org
  8. 48 3 Burton Object Models for Distrib. Multidisc'y Analysis & Optimization (MAO) Environments that Promote CAE Interoperability RM Kolonay, SA Burton - Collection of Technical Papers-10th AIAA/ …, 2004 - arc.aiaa.org

Cera

  1. 41 67 CD Cera Role-based viewing envelopes for information protection in collaborative modeling CD Cera, T Kim, JH Han, WC Regli - Computer-Aided Design, 2004 - Elsevier
  2. 58 23 CD Cera Multi-Level modeling and access control for data sharing in collaborative design T Kim, CD Cera, WC Regli, H Choo, JH Han - Advanced Engineering …, 2006 - Elsevier
  3. 59 20 CD Cera Hierarchical role-based viewing for multi-level information security in collaborative CAD CD Cera, T Kim, I Braude, JH Han, WC Regli - 2004 - DTIC Document
  4. 71 5 CD Cera Hierarchical role-based viewing for secure collaborative CAD C Cera, I Braude, I Comer, T Kim, J Han… - Proceedings of …, 2003 - gicl.cs.drexel.edu

W.D. Li

  1. 39 64 WD Li State-of-the-art technologies and methodologies for collaborative product development systems WD Li, ZM Qiu - International Journal of Production Research, 2006 - Taylor & Francis
  2. 17 32 WD Li A Web-based service for distributed process planning optimization WD Li - Computers in Industry, 2005 - Elsevier
  3. 9 18 WD Li A Web-based process planning optimization system for distributed design WD Li, SK Ong, AYC Nee - Computer-Aided Design, 2005 - Elsevier
  4. 22 12 WD Li Collaborative product design and manufacturing methodologies and applications WD Li - 2007 - books.google.com
  5. 50 4 WD Li Cooperative and Integration Mechanisms in Collaborative Product Development. WD Li, R Roy - IJEBM, 2007 - ijebm.ie.nthu.edu.tw

Goel

  1. 36 27 . Goel Service-based P2P overlay network for collaborative problem solving S Goel, SS Talya, M Sobolewski - Decision Support Systems, 2007 - Elsevier
  2. 31 15 . Goel Trust and security in enterprise grid computing environment S Goel, M Sobolewski - Proc. of IASTED Int. Conf. on Communication, …, 2003 -
  3. 26 11 . Goel Mapping engineering design processes onto a service-grid: turbine design optimization S Goel, SS Talya, M Sobolewski - Concurrent Engineering, 2008 - cer.sagepub.com
  4. 25 10 . Goel Preliminary Design Using Distributed Service-based Computing S Goel, S Talya, M Sobolewski - … of the 12th Conference on Concurrent …, 2005 -

Yu, Cha, et al

  1. 2 22 . J Yu A CAE-integrated distributed collaborative design system for finite element analysis of complex product based on SOOA J Yu, J Cha, Y Lu, W Xu, M Sobolewski - Advances in Engineering Software, 2010 - Elsevier
  2. 28 11 . J Cha A service-oriented collaborative design platform for concurrent engineering WS Xu, JZ Cha, M Sobolewski - Advanced Materials Research, 2008 - Trans Tech Publ
  3. 14 5 J Yu A Service-Oriented Architecture framework for the distributed concurrent and collaborative design J Yu, J Cha, Y Lu, S Yao - Service Operations and Logistics, …, 2008 - ieeexplore.ieee.org
  4. 37 4 ++ J Cha A manufacturing grid architecture based on Jini and SORCER W Xu, J Cha - … Perspective for Competitive Enterprise, Economy and …, 2009 - Springer
  5. 42 3 J Yu A remote CAE collaborative design system for complex product based on design resource unit J Yu, J Cha, Y Lu, Y Zhuang - The International Journal of Advanced …, 2011 - Springer

Soorianarayanan (plus Sobolewski on all papers ... distributed filesystems is the topic)

  1. 23 22 . Soorian Service-oriented file sharing M Sobolewski, S Soorianarayanan… - Proceedings of the …, 2003 - actapress.com
  2. 35 5 . Soorian Monitoring federated services in CE grids S Soorianarayanan, M Sobolewski - CE2004: The 11th ISPE …, 2004 -

Berger (plus Sobolewski on all papers ... distributed filesystems is the topic)

  1. 16 17 . Berger SILENUS–a federated service-oriented approach to distributed file systems M Berger, M Sobolewski - Next Generation Concurrent Engineering, 2005 -
  2. 15 13 . Berger Lessons learned from the SILENUS federated file system M Berger, M Sobolewski - Complex Systems Concurrent Engineering, 2007 - Springer
  3. 19 13 . Berger A federated grid environment with replication services V Khurana, M Berger, M Sobolewski - Next Generation Concurrent …, 2005 -
  4. 44 3 . Berger A dual-time vector clock based synchronization mechanism for key-value data in the SILENUS file system M Berger, M Sobolewski - Parallel and Distributed Systems, …, 2007 - ieeexplore.ieee.org

other FIPER folks

  1. 38 12 ++ Bailey FIPER: an intelligent system for the optimal design of highly engineered products MW Bailey, WH VerDuin - NIST SPECIAL PUBLICATION SP, 2001 - Citeseer
  2. 53 10 ++ Wujek A workflow paradigm for flexible design process configuration in FIPER B Wujek, P Koch, WS Chiang - Proceedings of the 8th AIAA/USAF/ …, 2000 - arc.aiaa.org

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. 74.192.84.101 (talk) 17:15, 3 January 2014 (UTC)[reply]

dealing with terminology/jargon/neologisms

discussion with a bit more heat than light perhaps... see Talk:SORCER#paragraph two for a laser-focus, we can re-open this terminology-question thataway

Good advice, copied from the archives. 74.192.84.101 (talk) 18:02, 30 December 2013 (UTC)[reply]

  • mograms, mogramming - a new term (invented by you), which violates WP:OR. The UML? model is translated down to code, so it's just code with a service manifest. You need to explain that correctly, and get rid of mograms, mogramming. It's not cited anywhere in the firmament, except by yourself, which means it's not acceptable within WP.

"mogram (program or model or both) " with the reference to the the independent third party source "Software Language Engineering: Creating Domain-Specific Languages Using Metamodels" by the leading expert in language engineering? Tell me what's wrong with it and please stop creating circular discussions on the same topics.Mwsobol (talk) 21:50, 1 January 2014 (UTC)[reply]

  • 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. (Where is the citation for this?)
    • Please show me another one that allows to define service compositions at the front-end. The fact that front-end compositions of service collaborations can be a hybrid of executable programs and executable models (mogram) is the secondary issue. If there is no another such platform with that feature then it's the first one. Are logical implications are invalid in Wikipedia?Mwsobol (talk) 15:14, 1 January 2014 (UTC)[reply]
      • That is not the way it works. Citations are required here. If it is the first then something must show that it is the first. Otherwise it may simply be stated to be "a platform" Fiddle Faddle 16:49, 1 January 2014 (UTC)[reply]
  • Exertions Why? Not programs, applications, services? You need to explain why it was called that. I think it's the same as mogramming, re who is citing it generally, and if it's only you, it will not be acceptable.
    • Semantically different things have names, so please try to understand the semantics of exertions first. A front-end and back-end services have different semantics. A service composition at the server (back-end) is done by a programmer and deployed by a deployer before it is used by the end user. A service composition at the font-end (exertion) is created and executed by the end user at runtime. For interpreted exertions (netlets) no compilation and deployment is needed to run service compositions.Mwsobol (talk) 15:29, 1 January 2014 (UTC)[reply]
  • SORCER is the first system enabling front-end service-oriented programming with the relevant operating system and dynamic back-end service federations as its virtual processor. That's neat, but don't know if it's true. I think Gigaspaces has a similar mechanism. You will certainly need a citation for this, other wise it's a false assertion, and will need to go.
    • Gigaspaces is just the commercial implementation of JavaSpaces (one of Jini services) to support space computing. It's a space computing middleware based on the JavaSpaces technology. You can write into a Jini space any object, it's generic. In SORCER what is called an exertion space is a JavaSpace service (can be Gigaspaces, we use open source Blitz or Jini JavaSpace) to provide space computing (synchronous federations) for exertions. However with synchronous execution (PUSH vs. PULL in SORCER) the service providers are accessed directly by SOS. You can create an exertion with mix of PUSH/PULL strategies so a part of service providers is accessed directly by SOS and another part reads exertion requests from the exertion space. That is done with the unique SORCR's federated method invocation (FMI). So JavaSpace (Gigaspace) is just one of SOS modules used for FMI.Mwsobol (talk) 15:51, 1 January 2014 (UTC)[reply]
  • The rest of the unexplained, non linked article content like Providers use discovery/join protocols to publish services in the network and the SOS uses discovery/join protocols to discover registries and lookup proxies in those registries. What providers? What discovery/join protocols, etc etc etc.
    • Terms service providers (services) and discovery/join protocols come from Jini terminology. The SORCER OS implementation uses Jini technology that defines its SOOA architecture. I assume that was stated explicitly in the article.Mwsobol (talk) 15:59, 1 January 2014 (UTC)[reply]

Lastly, it's written more as a reference manual, and currently doesn't make sense, lacks context and flow. The whole product seems to be built using Java, so how is it different from you average Java EE application server, like Weblogic or WebSphere. Sorry the criticism is so heavy. I knows your trying your best. scope_creep talk17:31 12 Dec 2013 (UTC)

  • I can comment shortly (read at least one paper on SORCER if you want to see differences): SORCER is the federated platform (programming environment (exertions and var-models), service-oriented OS with FMI, and federated processor) it's not a server or a middleware. Exertion-oriented programming and var-oriented modeling in SORCER has nothing to to with Java syntax and semantics they are completely new service languages. The fact SORCER in part is implement with Java has nothing to do with the SORCER architecture and programming/modeling model.Mwsobol (talk) 16:07, 1 January 2014 (UTC)[reply]
    • Is this paper on SORCER a WP:RS? If not then it is not relevant. Please at least get to understand the Wikipedia environment. Talking for ever round this subject produces nothing except fluff and clutter. It is presumed that your own work environment has rigour. So does Wikipedia. Our rigour is an insistence on correct reference material. Talking round and round abut this topic without making forward progress reinforces my original beliefs about this. Not every workplace is WP:N. Fiddle Faddle 16:56, 1 January 2014 (UTC)[reply]
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)[reply]

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
various papers with 3+ cites, organized by year, and with jargon-count

The five jargon-keywords mentioned above are represented in this list by the first column, "x" means hit, "_" means no hit. So for instance, "__x_x" means exertions & fiper, but not sorcer/fmi/mogramming.

FIPER in computer aided engineering

  1. ____x 2000, Cited by@74 , A federated intelligent product environment. PJ Röhl, RM Kolonay, RK Irani, M Sobolewski, Kevin Kao - AIAA-2000-4902, 8th …, 2000 - Citeseer xx
  2. ____x 2000, Cited by 10 , A workflow paradigm for flexible design process configuration in FIPER B Wujek, P Koch, WS Chiang - Proceedings of the 8th AIAA/USAF/ …, 2000 - arc.aiaa.org
  3. ____x 2001, Cited by*21 , Context model sharing in the FIPER environment S Zhao, M Sobolewski - Proc. of the 8th Int. Conference on Concurrent …, 2001 - sorcersoft.org
  4. ____x 2001, Cited by 12 , FIPER: an intelligent system for the optimal design of highly engineered products MW Bailey, WH VerDuin - NIST SPECIAL PUBLICATION SP, 2001 - Citeseer
  5. ____x 2002, Cited by^17 , A distrib.component based integration env.for multidisc'y optimal & quality design BA Wujek, PN Koch, M McMillan… - 9th AIAA/ISSMO …, 2002 - arc.aiaa.org
  6. ____x 2003, Cited by^18 , Towards a standardized engin'g framework for distrib, collab.product realization HJ Choi, JH Panchal, JK Allen… - Proceedings of …, 2003 - westinghouse.marc.gatech.edu
  7. ____x 2004, Cited by*20 , Hierarchical role-based viewing for multi-level info.sec.in collab. CAD CD Cera, T Kim, I Braude, JH Han, WC Regli - 2004 - DTIC Document
  8. ____x 2004, Cited by@67 , Role-based viewing envelopes for information protection in collaborative modeling CD Cera, T Kim, JH Han, WC Regli - Computer-Aided Design, 2004 - Elsevier dtic.mil
  9. ____x 2005, Cited by 09 , A distributed mechanical system simulation platform based on a “gluing algorithm” J Wang, ZD Ma, GM Hulbert - Journal of Computing and Information Science in …, 2005
  10. ____x 2005, Cited by@53 , Tech'y solutions for collab. product lifecycle mgmt–status review & future trend XG Ming, JQ Yan, WF Lu, DZ Ma - Concurrent Engineering, 2005 - cer.sagepub.com
  11. ____x 2005, Cited by^18 , A Web-based process planning optimization system for distributed design WD Li, SK Ong, AYC Nee - Computer-Aided Design, 2005 - Elsevier
  12. ____x 2005, Cited by*32 , A Web-based service for distributed process planning optimization WD Li - Computers in Industry, 2005 - Elsevier
  13. ____x 2006, Cited by@64 , State-of-the-art tech's & methodologies for collab. product development systems WD Li, ZM Qiu - International Journal of Production Research, 2006 - Taylor & Francis
  14. ____x 2006, Cited by*27 , Document-driven design for distrib. CAD services in service-oriented architecture Y Wang, BO Nnaji - Journal of computing and …, 2006 - www-old.me.gatech.edu
  15. ____x 2006, Cited by*23 , Intellectual property protection in collab.des.thru lean info.modeling & sharing JC Brustoloni, BO Nnaji - Journal of computing and …, 2006 - www-old.me.gatech.edu
  16. ____x 2006, Cited by*23 , Multi-Level modeling and access control for data sharing in collaborative design T Kim, CD Cera, WC Regli, H Choo, JH Han - Advanced Engineering …, 2006 - Elsevier
  17. ____x 2007, Cited by 05 , An adaptable service-based framework for distributed product realization JH Panchal, HJ Choi, JK Allen, D Rosen… - Collaborative Product …, 2007 - Springer
  18. ____x 2007, Cited by*27 , Service-based P2P overlay network for collaborative problem solving S Goel, SS Talya, M Sobolewski - Decision Support Systems, 2007 - Elsevier
  19. ____x 2007, Cited by 12 , Collaborative product design and manufacturing methodologies and applications WD Li - 2007 - books.google.com
  20. ____x 2007, Cited by 04 , Cooperative and Integration Mechanisms in Collaborative Product Development. WD Li, R Roy - IJEBM, 2007 - ijebm.ie.nthu.edu.tw
  21. ____x 2008, Cited by 04 , Complex product collab. des. & sim'n based on product master model technology J Ji, D Zhang, S Li, B Wu, B Chen - … Technology and Automation …, 2008 - ieeexplore.ieee.org
  22. __x_x 2008, Cited by 11 , Mapping engineering design processes onto a service-grid: turbine design optim. S Goel, SS Talya, M Sobolewski - Concurrent Engineering, 2008 - cer.sagepub.com

SORCER == in computer science

  1. x____ 2001, Cited by 05 , Context Model Sharing in the SORCER Environment S Zhao, M Sobolewski - 2001 - forthcoming
  2. x____ 2003, Cited by*22 , Service-oriented file sharing M Sobolewski, S Soorianarayanan, Ravi-Kiran - Proceedings of the …, 2003 - actapress.com
  3. x___x 2003, Cited by^15 , Trust and security in enterprise grid computing environment S Goel, M Sobolewski - Proc. of IASTED Int. Conf. on Communication, …, 2003 - sorcersoft.org
  4. x____ 2004, Cited by 03 , Grid computing at texas techuniversity using sas R Bremer, J Perez, P Westfall - Proceedings of the 14th Annual South- …, 2004 - scsug.org
  5. x____ 2004, Cited by 05 , Monitoring federated services in CE grids S Soorianarayanan, M Sobolewski - CE2004: The 11th ISPE …, 2004 - sorcersoft.org
  6. x____ 2007, Cited by 03 , A dual-time vector clock based sync'n mechanism for key-value data in SILENUS f.s. M Berger, M Sobolewski - Parallel and Distributed Systems, …, 2007 - ieeexplore.ieee.org
  7. xxx_x 2007, Cited by^15 , Federated method invocation with exertions M Sobolewski - … of the International Multiconference on ISSN, 1896 - proceedings.fedcsis.org
  8. x____ 2008, Cited by 05 , Service-oriented programming M Sobolewski - 2008 - SORCER Technical Report SL-TR- …
  9. xxx_x 2008, Cited by 13 , Federated collaborations with exertions M Sobolewski - … for Collaborative Enterprises, 2008. WETICE'08 …, 2008 - ieeexplore.ieee.org
  10. xxx_x 2008, Cited by*24 , Exertion oriented programming M Sobolewski - IADIS, 2008 - sorcersoft.net
  11. xxx_x 2008, Cited by*36 , SORCER: Computing and Metacomputing Intergrid. M Soblewski - ICEIS (3-1), 2008 - http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.123.4371&rep=rep1&type=pdf
  12. xxx_x 2009, Cited by^16 , Metacomputing with federated method invocation M Sobolewski - Advances in Computer Science and IT, 2009 - sorcersoft.org
  13. xxx__ 2009, Cited by 03 , File Location Management in Federated Computing Environments C Hard, M Sobolewski - International Journal of Recent Trends in …, 2009 - sorcersoft.net
  14. xxx__ 2009, Cited by 11 , Dynamic SLA negotiation in autonomic federated environments P Rubach, M Sobolewski - On the Move to Meaningful Internet Systems: …, 2009 - Springer
  15. xxx__ 2009, Cited by 11 , Autonomic SLA management in federated computing environments P Rubach, M Sobolewski - Parallel Processing Workshops, …, 2009 - ieeexplore.ieee.org
  16. xxx__ 2010, Cited by 08 , Exerted enterprise computing: from protocol-oriented networking to EO networking M Sobolewski - On the Move to Meaningful Internet Systems: OTM …, 2010 - Springer
  17. xxx_x 2010, Cited by 11 , Object-oriented metacomputing with exertions M Sobolewski - Handbook On Business Information Systems, 2010 - mfile.narotama.ac.id
  18. xxxxx 2011, Cited by 05 , Provisioning Object-oriented Service Clouds for Exertion-oriented Programming. MW Sobolewski - CLOSER, 2011 - sorcersoft.org
  19. xxxxx 2012, Cited by 04 , Object-Oriented Service Clouds for Transdisciplinary Computing M Sobolewski - Cloud Computing and Services Science, 2012 - Springer

SORCER in computer aided engineering

  1. x____ 2004, Cited by 03 , Object Models for Distributed MAO Environments that Promote CAE Interoperability RM Kolonay, SA Burton - Collection of Technical Papers-10th AIAA/ …, 2004 - arc.aiaa.org
  2. x____ 2005, Cited by^17 , SILENUS–a federated service-oriented approach to distributed file systems. M Berger, M Sobolewski - Next Generation Concurrent Engineering, 2005 - sorcersoft.net CS + CAE
  3. x____ 2005, Cited by 13 , A federated grid environment with replication services V Khurana, M Berger, M Sobolewski - Next Generation Concurrent …, 2005 - sorcersoft.org CS + CAE
  4. x_x_x 2007, Cited by 13 , Lessons learned from the SILENUS federated file system M Berger, M Sobolewski - Complex Systems Concurrent Engineering, 2007 - Springer CS + CAE
  5. xx__x 2007, Cited by 06 , FICUS—A federated service-oriented file transfer framework A Turner, M Sobolewski - Complex Systems Concurrent Engineering, 2007 - Springer CS + CAE
  6. x_x__ 2008, Cited by 11 , A service-oriented collaborative design platform for concurrent engineering WS Xu, JZ Cha, M Sobolewski - Advanced Materials Research, 2008 - Trans Tech Publ CS + CAE
  7. x___x 2008, Cited by 05 , A Service-Oriented Architecture framework f' distrib. concurrent & collab. design J Yu, J Cha, Y Lu, S Yao - Service Operations and Logistics, …, 2008 - ieeexplore.ieee.org
  8. x____ 2009, Cited by 05 , The physics of an optimized flapping wing micro air vehicle C Chabalko, D Snyser, P Beran, G Parker - Proceedings of the 47th …, 2009 - arc.aiaa.org
  9. x_x_x 2009, Cited by 04 , A manufacturing grid architecture based on Jini and SORCER W Xu, J Cha - … Perspective for Competitive Enterprise, Economy and …, 2009 - Springer
  10. xxx_x 2010, Cited by*22 , A CAE-integ.distrib.collab.des.sys.for fin.el.analy.of complex prod.based on SOOA J Yu, J Cha, Y Lu, W Xu, M Sobolewski - Advances in Engineering Software, 2010 - Elsevier
  11. xx___ 2010, Cited by 06 , 面向复杂产品的分布式协同设计系统 于加晴, 查建中, 陆一平, 徐文胜. 中南大学学报: 自然科学 edu.zndxzk.com.cn/down/upfile/soft/2010428/26-p0539-08609.pdf
  12. x_x__ 2011, Cited by 03 , Network alliance for the total life cycle of reconfigurable machine tool L Ma, J Li, W Xu, J Liu - Management Science and Industrial …, 2011 - ieeexplore.ieee.org
  13. xxx_x 2011, Cited by 03 , A remote CAE collab.des.sys. for complex product based on des. resource unit J Yu, J Cha, Y Lu, Y Zhuang - The International Journal of Advanced …, 2011 - Springer
  14. x____ 2011, Cited by 07 , SORCER for Large Scale, Distri, Dynamic Fidelity Aeroelastic Analysis & Optim. RM Kolonay, M Sobolewski - International Forum on Aeroelasticity and Structural …, 2011

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. 74.192.84.101 (talk) 17:33, 3 January 2014 (UTC)[reply]

todo list

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. 74.192.84.101 (talk) 15:20, 29 December 2013 (UTC)[reply]

paragraph one

  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]

Rewrite attempt. See WP:Footnotes#Footnotes:_predefined_groups for the 'efn' squiggly-syntax.

  1. SORCER[a]
  2. is a cloud-based grid computing platform (typically using Java to write network-shell-scripts called exertions which implement location-agnostic web services).
  3. SORCER's grid-computing capability is primarily used to speed up computerized analysis of aerospace simulations and traffic noise, as of 2013.
  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.[b]
  6. SORCER Labs was founded in November 2002 at TTU;
  7. in 2010, SORCER Labs became a spin-off organization, funded primarily by the USAF's AFRL[c], and the source code was partially opened.
  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 using SORCER include Beijing Jiaotong University in China, Cranfield University in the United Kingdom, and Ulyanovsk State University in Russia.

Notes

  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. ^ Air Force Research Labof Ohio's Wright-Patterson Air Force Base funded by the United States Air Force, especially the MSTC Directorate under Raymond Kolonay.

Anybody else like this version better? 74.192.84.101 (talk) 15:20, 29 December 2013 (UTC)[reply]

I find it easier to read, thus it is, by definition, better. It lacks the main requirement of an opening paragraph, though. It does not tell me why this is important. From a journalist's or marketeer's persepctive, and, amusingly, from an encyclopaedia's perspective this is a must have. "Tell me why I should read this material and why it is here." Something like "By deploying SORCER, recorded costs savings/ productivity increases [quantify and verify] have been made." That is at least highly desirable. (oops, failed to sign) Fiddle Faddle 13:44, 31 December 2013 (UTC)[reply]
It sounds better and more like Wikipedia. But in my opinion we shoud not compare it to grid computing as:
  • SORCER works on higher layers
  • SORCER delivers logic for processing - grids doesn't (tools for grids does provide it but not grids itself);
  • SORCER delivers language to operate on integrated systems - and grids does not.

Pawelpacewicz (talk) 13:34, 31 December 2013 (UTC)[reply]

Well, there *is* a new language from sorcerSoft the company-slash-organization-twins, but "SORCER" is not the language, it is the nsh and the FMI-stuff and the service-configuration-backend... whereas EOL is the language, which is built on Groovy, which is built on JVM-bytecode. But, one can always just use straight Java as the language, which proves that EOL and SORCER *are* distinct, right? EOL is a language that can be used to program exertion-scripts for nsh to execute, and EOL has some special features not included in the base Groovy/Java languages. Anyways, we'll get to a paragraph about languages-used-with-SORCER, further down in our list of paragraphs.
  As for the definition of SORCER as a type of grid-computing-infrastructure, it is a quote straight from DaytonThesis, by Thompson. What is SORCER called in other reliable sources? Sometimes it is referred to as a meta-operating-system, but that's not how it is often used currently. It is a capability, which might be used in the classified literature, but not in the sources we have at present, right? That is what we have to stick to. What is SORCER called in the 2007 lit-review from U.Cranfield, for instance?
  As for Tim's question, see fragment#3 ("primarily used to" is my codephrase meaning "primarily Notable for being used to") that same DaytonThesis also gives us a good quote about the purpose (or at least *one* purpose) for which SORCER is notable... using the extra speed that SORCER's spread-the-load-across-the-grid-related-features offer, aircraft-designers like Thompson can perform full-fledged non-linear analysis of aircraft-designs in simulations, rather than the traditional linear-analysis. When the DaytonThesis simulated the aircraft-wing-design at mach 0.50 there was no difference in the optimality of the design; linear was just as good as non-linear. However, when the same pair of design-methodologies was applied to the same aircraft-wing-design at mach 0.89 ... which is getting close enough to the sound barrier that weird things come into play ... the SORCER-powered non-linear analysis-methodology created a *much* more-optimal automated wing-design, using the same amount of time & personnel & whatnot. So at least from Thompson's DaytonThesis perspective, SORCER is purely a grid-computing-infrastructure-platform, which permits spreading the computations across a grid of machines, and thus gives better wing-designs without the need to fabricate physical models and test them in the wind-tunnel. What do our other WP:RS say, is the chief advantage of using SORCER, as opposed to other software-options? What is the big advantage of SORCER for Nan Li, and the traffic-noise-mapping work? HTH. 74.192.84.101 (talk) 23:06, 31 December 2013 (UTC)[reply]

My proposal below: ((Be aware that WP:WikiFauna have modified the original comment! redundant information was snipped and strikethru insert syntax was added.))

  1. ok
  2. is a cloud-based grid computing platform (typically using Java to write network-shell-scripts called exertions which implement location-agnostic web services). is a distributed computing platform implemented in Java. SORCER uses the Jini infrastructure to create wrappers and expose functionalities (other applications, native or java libraries etc.) as services. SORCER introduces the front-end service-oriented programming model, where the user writes network-shell-scripts (similar to Bash scripts) that when executed by SORCER's network shell bind dynamically using Jini's discovery and join protocols to services anywhere in the Jini/SORCER network and execute the operations specified in the script on these services. This is different from Unix shell scripts that execute on one machine or on one Cluster_(computing).
  3. SORCER's grid-computing capability is primarily used... SORCER is often utilized in similar scenarios to those where grids are used (Grid computing) to run parallel tasks
  4. ok
  5. ok
  6. ok
  7. in 2010... the source code was partially opened. SORCER core's source code was made public in 2013 under the Apache open source license.
  8. ok
  9. ok

Prubach (talk) 14:31, 16 January 2014 (UTC)[reply]

Concerning fragment#3 of paragraph#1, what is SORCER currently actually used for, besides speeding up CAE work? I understand the SORCER is *designed* to be more than just a grid-computing-platform, and we can *say* that it was designed to do more than just grid-computing, but my reading of the sources (which of course cannot hope to be as broad and deep as folks who are intimately familiar with SORCER so take this with a grain of salt) is that SORCER is *only* used for grid-computing. DaytonThesis, which is from 2012, flat-out defines SORCER as a grid-computing solution. Are there other WP:RS which define SORCER differently, and in particular, are there other WP:RS which show SORCER being actually used for 'distributed computing' which is interestingly different from 'grid computing' aka speeding up computations via custom-programmed coarse-grained parallelism?
  On frag#2, there is no doubt your longer explanation is more correct.  :-)   But this is the first sentence of the first paragraph of the article. We have to distill down the essence of what SORCER is, to something a tenth-grade-HTML-wiz has a shot at understanding. My first frag#2_B used 2-dozen words to get it wrong, and your frag#2_C uses 8-dozen words to get it right. Can we boil it down into a dozen-or-two words, that still get it right? Here's 3.5-dozen words, do you like it? frag#2_D. is a distributed computing platform (in Java), providing network-based Jini-discoverable services (often wrappers around existing applications). Services are programmatically controlled via network-shell scripts ("exertions"), which dynamically bind at runtime to unloaded network-nodes (see distributed operating system) via Jini " joins". 74.192.84.101 (talk) 19:24, 16 January 2014 (UTC)[reply]

I like version proposed by Prubach but I agree that 1st paragraph should be easy so short version proposed by 74 is good direction. I would propose to add at the end some simple and high level explanation for example: "It allows to write network-programs (exertions) that operates on wrapped applications spread in the network" Pawelpacewicz (talk) 11:26, 17 January 2014 (UTC)[reply]

I understand the point - I too much wanted to keep with your initial idea of explaining what it does. I propose the following for frag#2:

  1. ...is a distributed computing platform implemented in Java. It allows to write network-programs (called exertions) that operates on wrapped applications (services) spread in the network.

The rest of my current content of frag#2 I'd move to par.2.

Concerning your comment on fragment#3 of paragraph#1 it is true that SORCER is designed to do much more and that's what I'm currently also trying to look at - where and how this technology could be applied but it is also true that current use-cases are practically only in grid-computing (some students at TTU used it for running genetic research on mupltiple machines) and in CAE with the exception of this Chinese article on traffic noise. BTW I've never actually heard about it until you've found it ;) Prubach (talk) 14:17, 17 January 2014 (UTC)[reply]

So looks like we are agreed with final version of paragraph 1. 74 - could I then ask You to make proper updates to 1st paragraph and then we will move to 2nd paragraph? Pawelpacewicz (talk) 12:09, 22 January 2014 (UTC)[reply]

paragraph two

Current.

  1. Overview. SORCER is a computing platform that allows the end user
  2. to program dynamic front-end compound services, called exertions,
  3. bound at runtime by the SORCER OS (SOS)
  4. to federations of service providers as new back-end dynamic services.
  5. The SOS utilizes the service object-orient architecture (SOOA) and a federated method invocation.
  6. The front-end services created by the end users
  7. are service collaborations of users' applications, tools, and utilities with their data and corresponding control strategies.
  8. The end users in understandable domain specific languages (DSL)
  9. define only their service-oriented process expressions
  10. and the SOS makes that process expressions actualized by the corresponding dynamic service federations in the network.

Rewrite.

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

Notes

  1. ^ Stands for 'network shell'.
  2. ^ Called exertions in the literature.
  3. ^ Sometimes called the "SORCER operating system" in the literature, but SORCER is not a bare metal bootable operating system; it is more of a software platform.
  4. ^ SORCER is an implementation of a service-based object-oriented architecture; see also object-oriented programming and web services for similar concepts.
  5. ^ federated method invocation
  6. ^ Using configuration-data called a control-strategy in the literature.
  7. ^ Although sometimes domain-specific languages are full-fledged programming environments, often they are far more English-like and/or GUI-driven than general-purpose programming languages.

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

Updated. 74.192.84.101 (talk) 19:24, 16 January 2014 (UTC)[reply]

paragraph three

Current.

  1. SORCER is a federated service-oriented platform with a front-end federated service-oriented programming environment,
  2. a matching operating system, and a federated virtual processor.
  3. The architecture of SORCER is based on the concept: Everything Anywhere Anytime As a Service (EaaaS).
  4. Therefore the end user service requests (front-end expression) as well service providers (back-end federations) are treated as services.
  5. 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.
  6. The exertion-oriented programming has its roots in the FIPER project.
  7. An exertion as the front-end service composition defined by the user is bound by the SORCER OS (SOS) to service providers (local and/or remote) to form a matching collaborative service federation at runtime - a virtual service processor of the SORCER platform.

Rewrite.

  1. Speaking abstractly, SORCER implements a service-oriented model of computation, with an associated standardized programming environment.
  2. 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.
  3. 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).
  4. "Services" can call other services, either on the same machine or across the network; which *particular* callee is bound to the caller, varies dynamically with compute-load on the various network-nodes (see the hardware-operating-system metaphor above). This phenomenon, wherein an individual service (whether front-end or back-end — it does not matter) can call another set of helper-services in parallel and/or asynchronously, which can "pop up" on any node in the network which has compute-capacity to spare, is called a "federated method invocation" because a federation of abstractly-network-visible helper-services do the work (contrast with remote method invocation in which a single helper-service on a single fixed-network-node does the work).
  5. 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"[3] from model + program).
  6. The discipline of writing network-shell-scripts ("exertions") which are executed in the distributed computing environment provided by SORCER has been dubbed "exertion-oriented programming" with the first academic papers on this topic published in 2007 (but as with SORCER itself the roots of exertion-oriented programming can be found in the FIPER predecessor-project). An extension of the Groovy language (which runs on the Java JVM platform) has been implemented, which provides an Exertion Oriented Language, a new programming syntax for writing nsh shell-scripts ("exertions") as an alternative to writing SORCER-apps in Java (and calling the SORCER API).
  7. Metaphorically, then, instead of talking about a programmer who writes network-shell-scripts in a JVM language for SORCER's nsh, which can call remote Jini-discoverable network-visible backend services, that dynamically execute on the available compute-nodes anywhere on the LAN, we can instead speak about a mogrammer writing exertions in EOL for the SOS, which performs federated method invocations (and speak of the LAN as a "virtual CPU" for everything-a-service exertion-oriented mogramming techniques).
  8. to form a matching collaborative service federation at runtime - a virtual service processor of the SORCER platform.

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

how many source-code repos are there?

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 SorcerSoft.com, located in Poland, who got trained by Mwsobol during 2013
  11. SorcerSoft.com is now just starting to develop commercial GUI-tools for SORCER
  12. SorcerSoft.com's proprietary work is based on a private repo, an internal fork of the open-source codebase, is not available to the public,
  13. SorcerSoft.com'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 SorcerSoft.com's? Different from SorcerSoft.org's repo, if any?)
  15. SorcerSoft.org ... which is not officially connected to SorcerSoft.com ... 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 http://sorcersoft.com
  25. one particular repo was developed at TTU, and is now maintained by sorcerSoft.com
  26. Github contributors page , https://github.com/sorcersoft/sorcer/graphs/contributors
  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 ... [4]
  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 SorcerSoft.org , 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. 74.192.84.101 (talk) 01:48, 1 January 2014 (UTC)[reply]

"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 github.com/sorcersoft/ - 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)[reply]
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? 74.192.84.101 (talk) 19:24, 16 January 2014 (UTC)[reply]

technical question, about exertions versus federations

"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? "...so 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. 74.192.84.101 (talk) 01:48, 1 January 2014 (UTC)[reply]


  • 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)[reply]

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. — 74.192.84.101 (talk) 19:36, 4 January 2014 (UTC)[reply]


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)[reply]

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? 74.192.84.101 (talk) 19:36, 4 January 2014 (UTC)[reply]


  • 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)[reply]

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? 74.192.84.101 (talk) 19:36, 4 January 2014 (UTC)[reply]


  • 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)[reply]

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,[5] "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. 74.192.84.101 (talk) 19:36, 4 January 2014 (UTC)[reply]

back-end-federated-programming

"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: [6]) - 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

"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)[reply]

  • Some techie-questions, see here.[7] 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? 74.192.84.101 (talk) 19:24, 16 January 2014 (UTC)[reply]


  • 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? 74.192.84.101 (talk) 19:24, 16 January 2014 (UTC)[reply]


  • 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. 74.192.84.101 (talk) 19:24, 16 January 2014 (UTC)[reply]


How to explain SORCER conceptualizations?

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 SORCERsoft.com 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. SORCERsoft.com 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 (sorcersoft.org) 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)[reply]

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. "...to 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 (foo.java 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. "...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." 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 SorcerSoft.org 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, SorcerSoft.org SORCER'10, SorcerSoft.org SORCER'13, China SORCER, Russia SORCER, SorcerSoft.com SORCER'13, and soon probably PTIIJ SORCER'14 (if that becomes a fork rather than a contribution back upstream to SorcerSoft.org or SorcerSoft.com 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. "...SORCERsoft.com 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 SorcerSoft.com is using the same trademark as SorcerSoft.org (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 SorcerSoft.com 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 (sorcersoft.org) 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. 74.192.84.101 (talk) 00:06, 5 January 2014 (UTC)[reply]

This discussion has been circular since the start

AfD#2 was ended with a 'keep' so we are making progress, AfD#1 could only manage 'no consensus'

Despite enormous efforts by experienced Wikipedia editors to find WP:RS, to show WP:N and to ensure WP:V, the discussion has proved to be an endless round of:

  1. Show me that this is notable
  2. It is notable because it is notable
  3. Give me the reference
  4. The reference is somewhere in this list of probably non WP:RS material
  5. If I find it, show me that this source is WP:RS
  6. It must be reliable because I say it is reliable
  7. Return to number 1

This has been going on for a couple of days short of two months. This alone shows me that the topic is not notable. Were it to be notable this would have been proven a long time ago. Doubtless people use this environment. Good. Maybe it will become notable one day. Today it is not.

Yes, we have WP:NODEADLINE, but there is a threshold of notability all articles must pass. We cannot faff around for ever with those who work in SORCER telling us for ever that their project is notable without clarity of answers to questions. It is time for clear answers. If the SORCER folk can show that this is WP:N by proving the bona fides of their sources to be WP:RS, now is the time. Fiddle Faddle 17:18, 1 January 2014 (UTC)[reply]

support-- TRPoD aka The Red Pen of Doom 17:36, 1 January 2014 (UTC)[reply]
(( redacted beginning-editor frustration ... will discuss on their talkpage ))    — 74.192.84.101 (talk) 17:54, 3 January 2014 (UTC)[reply]

Reply to 74.192.84.101 re citation counts.

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
c
23:54, 2 January 2014 (UTC)[reply]

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 sorcersoft.org 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. 74.192.84.101 (talk) 17:52, 3 January 2014 (UTC)[reply]

Hi 74. There is a lot of "above" to see. Can you give me the pointers to the lit-review papers? Thanks! Garamond Lethet
c
20:48, 3 January 2014 (UTC)[reply]
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. 74.192.84.101 (talk) 21:09, 3 January 2014 (UTC)[reply]
74, I'm sorry, I wasn't clear. Which one of these is the "lit survey paper"? Garamond Lethet
c
21:20, 3 January 2014 (UTC)[reply]
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[8] 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.

analysis of the MOO literature, per goog-scholar, first line is search-term, number results are hits-with-cites

Multi-objective Optimisation "SORCER"

  1. Aeroelastic Optimization of a Two-Dimensional Flapping Mechanism DE Bryson, TA Weisshaar, RD Snyder… - … 국내연구성과| IP 제공정보 …, 2010 - arc.aiaa.org Cited by 2 2010 AIAA for CAE , not ACM/IEEE for EECS
  2. Efficient Supersonic Air Vehicle Preliminary Conceptual Multi-Disciplinary Design Optimization Results E Alyanak, R Kolonay, -, 2012 - arc.aiaa.org Cited by 2 2012 AIAA for CAE , not ACM/IEEE for EECS
  3. Standard Platform for Benchmarking Multidisciplinary Design Analysis and Optimization Architectures J Gray, KT Moore, TA Hearn, BA Naylor - AIAA journal, 2013 Cited by 1 2013 AIAA for CAE , not ACM/IEEE for EECS

Multi-objective Optimisation "FIPER" Multi-objective Optimisation "FIPER"

  1. Current trends in evolutionary multi-objective optimization K Deb - … Simulation and Multidisciplinary Design Optimization, 2007 - ijsmdo.org Cited by 33 2007 6 cites/yr for rockstar K.Deb
  2. MOB a European distributed multi-disciplinary design and optimisation project AJ Morris - Proceedings of the 9th AIAA/ISSMO Symposium on …, 2002 - arc.aiaa.org Cited by 28 2002 FIPER
  3. Design search and optimization in aerospace engineering AJ Keane, JP Scanlan - … Transactions of the Royal …, 2007 - rsta.royalsocietypublishing.org Cited by 11 2007
  4. Introduction to evolutionary multiobjective optimization K Deb - Multiobjective Optimization, 2008 - Springer Cited by 27 2008 5 cites/yr for rockstar K.Deb
  5. CAD based shape optimization for gas turbine component design D Brujic, M Ristic, M Mattone, P Maggiore… - … Optimization, 2010 - Springer Cited by 6 2010
  6. iSIGHT-FD, a tool for multi—objective Data Analysis A Van der Velden, B Wujek, P Koch - … 프로시딩즈| 기술보고서| 해외연구 …, 2008 - arc.aiaa.org Cited by 3 2008
  7. Multidisciplinary Design Optimization of Missile Based on FIPER Software T LI, L GU - Computer Simulation, 2009 - en.cnki.com.cn Cited by 1 2009
  8. Multidisciplinary optimization of naval ship design and mission effectiveness J Vianese - 2004 - DTIC Document Cited by 5 2004
  9. A hierarchical federated integration architecture for collaborative product development H Sun, W Fan, W Shen, T Xiao… Journal …, 2012 - Taylor & Francis Cited by 2 2012
  10. Knowledge Based Engineering (KBE) Past, present and Future A Prijic, C Chapman, P Burton - Beograd 2005 EAEC European Automotive Congress Cited by 2 2005
  11. Use of CAPE-OPEN Standard in US-UK Collaboration on Virtual Plant Simulation SE Zitney - AIChE 2007 Annual Meeting, 4th Annual US CAPE- …, 2007 - co-lan.org Cited by 2 2007
  12. Towards a standardized engineering framework for distributed, collaborative product realization HJ Choi, JH Panchal, JK Allen, Proceedings, 2003 gatech.edu Cited by 18 2003 FIPER
  13. PROGRESS REPORT ON NEW MODELLING TECHNIQUES D Brujic, M Ristic, M Mattone, P Maggiore… - 2005 - modefrontier.de Cited by 1 2005
  14. Ein Beitrag zur interdisziplinären Prozessintegration und automatischen Mehrzieloptimierung am Beispiel einer Verdichterrotorschaufel, D Otto - 2009 - opus.kobv.de Cited by 1 2009
  15. Developing a Design Space Model Using a Multidisciplinary Design Optimization Schema in a Product Lifecycle Management System… NL Fife - 2005 - Citeseer Cited by 3 2005
  16. Facilitating meta-design via separation of problem, product, and process information JH Panchal, MG Fernández… - 2005 ASME …, 2005 - westinghouse.marc.gatech.edu Cited by 6 2005
  17. Computational workflow management for conceptual design of complex systems: an air-vehicle design perspective LK Balachandran - 2007 - dspace.lib.cranfield.ac.uk Cited by 2 2007
  18. Addressing Geometry Needs of Systems Engineering with DaVinci Software G Roth, J Livingston, C Dailey, A Cline - 49th AIAA, 2011 - arc.aiaa.org Cited by 1 2011
  19. An adaptable service-based framework for distributed product realization JH Panchal, HJ Choi, JK Allen, D Rosen… - … Product Design and …, 2007 - Springer Cited by 5 2007
  20. Feasibility assessment in preliminary design using Pareto sets A Gurnani, S Ferguson… - ASME Design …, 2005 - does.eng.buffalo.edu Cited by 11 2005 Gurnani#1
  21. An Approach to Feasibility Assessment In Preliminary Design S Ferguson, A Gurnani, J Donndelinger… - ASME Design …, 2005 - atsv.psu.edu Cited by 5 2005 Gurnani#2
  22. Design and analysis of computer experiments in multidisciplinary design optimization: a review TW Simpson, V Toropov, V Balabanov…, 2008, aiaa.org Cited by 106 2008 21 cites/yr for this lit-review by AIAA ... gold? Could not find full paper online, paywall[9] shows only first page, U.Leuv(sp) used to have PDF but site was offline when I checked. Author emails listed, maybe one will help out?
  23. e-Design Systems BO Nnaji, Y Wang, KY Kim - The Handbook of Industrial and …, 2005 - 203.158.253.140 Cited by 2 2005
  24. Thermo-economic assessment of externally fired micro-gas turbine fired by natural gas and biomass AM Pantaleo, SM Camporeale, N Shah, 2013 - Elsevier Cited by 3 2013
  25. Towards a design support system for distributed product realization JH Panchal - 2003 - srl.gatech.edu Cited by 3 2003
  26. Cost-Effective Product Realization-Service-Oriented Architecture for Integrated Product Life-Cycle Management BO Nnaji, Y Wang, KY Kim - 7th IFAC, 2004 Cited by 8 2004
  27. Nesting automated design modules in an interconnected framework JM Young - 2005 - Citeseer Cited by 3 2005
  28. A design tool architecture for the rapid evaluation of product design tradeoffs in an Inernet-based system modeling environment JJA Wronski - 2005 - mit.edu Cited by 8 2005
  29. Multi-objective evolutionary optimization in time-changing environments I Hatzakis - 2007 - dspace.mit.edu Cited by 2 2007

Multi-objective Optimisation ("M. Sobolewski" OR "M Sobolewski" OR "Mike Sobolewski" OR "Michael Sobolewski" OR "Sobolewski, M" OR "Sobolewski, M" OR "Sobolewski, Mike" OR "Sobolewski, Michael")

  1. Transmission systems design--decisions, multi-criteria optimization in distributed environment J Pokojski, K Niedziółka - Proceedings, 2006 - dl.acm.org Cited by 3 2006
  2. Multi-objective Optimization Model and Algorithms for Partner Selection MM Hassan, EN Huh - Dynamic Cloud Collaboration Platform, 2013 - Springer Cited by 1 2013 Hassan#1
  3. Dynamic Cloud Collaboration Platform: A Market-oriented Approach MM Hassan, EN Huh - 2013 - books.google.com Cited by 1 2013 Hassan#2
  4. A constraint-based approach to feasibility assessment in preliminary design A Gurnani, S Ferguson, K Lewis, J Donndelinger - AI EDAM, 2006 - Cambridge Univ Press Cited by 17 2006 Gurnani#3 ... 2.4 cites/yr
  5. Multi-objective optimization of multicast overlays for collaborative applications K Rzadca, JTT Yong, A Datta - Computer Networks, 2010 - Elsevier Cited by 3 2010
  6. Product, process and methodology systematization to handle structural and computational complexity in product realization B Prasad, 2001 - Wiley Online Library Cited by 2 2001
  7. Recent advances in engineering design optimisation: Challenges and future trends R Roy, S Hinduja, R Teti - CIRP Annals-Mfg Technology, 2008 - Elsevier Cited by 75 2008 15 cites/yr[10] by R.Roy DeptMfg U.Cranfield, S.Hinduja AeroEng U.Manchester, R.Teti MatEng&ProductionEng U.Naples. See analysis in section green box, immediately below.
  8. A hierarchical decision model to select quality control strategies for a complex product Y Liu, KW Hipel, 2012 - ieeexplore.ieee.org Cited by 4 2012

Multi-objective Optimisation .... aka this particular sub-sub-field in general, only the top 20 hits-with-cites are shown

  1. Multi-objective optimization K Deb - Multi-objective optimization using evolutionary …, 2001 - netscale.cse.nd.edu Cited by 8354 2001 700 cites/yr for rockstar K.Deb
  2. Multi-objective optimization K Deb - Search Methodologies, 2005 - Springer Cited by 122 2005 15 cites/yr for rockstar K.Deb
  3. A fast elitist non-dominated sorting genetic algorithm for multi-objective optimization: NSGA-II K Deb, S Agrawal, A Pratap, 2000 - repository.ias.ac.in Cited by 2796 2000 200 cites/yr for rockstar K.Deb
  4. Survey of multi-objective optimization methods for engineering RT Marler, JS Arora - Structural and multidisciplinary optimization, 2004 - Springer Cited by 916 2004
  5. A Multi-Objective Algorithm based upon Particle Swarm Optimisation, an Efficient Data Structure and Turbulence. JE Fieldsend, EQ Uk, S Singh - 2002 - Citeseer Cited by 258 2002
  6. A critical survey of performance indices for multi-objective optimisation T Okabe, Y Jin, B Sendhoff, CEC'03, 2003 - ieeexplore.ieee.org Cited by 123 2003
  7. Multi-objective optimization using genetic algorithms: A tutorial A Konak, DW Coit, AE Smith - Reliability Engineering & System Safety, 2006 - Elsevier Cited by 778 2006
  8. Evolutionary multi-objective optimization: a historical view of the field CA Coello Coello - Computational Intelligence Mag, IEEE, 2006 - ieeexplore.ieee.org Cited by 477 2006
  9. Strategies for finding good local guides in multi-objective particle swarm optimization (MOPSO) S Mostaghim, J Teich - …, SIS'03., 2003 - ieeexplore.ieee.org Cited by 404 2003
  10. Multi-objective global optimization for hydrologic models PO Yapo, HV Gupta, S Sorooshian - Journal of hydrology, 1998 - Elsevier Cited by 570 1998 classic
  11. Multi‐objective combinatorial optimization problems: A survey EL Ulungu, J Teghem - Journal of Multi‐Criteria Decision …, 1994 - Wiley Online Library Cited by 333 1994 classic
  12. Scalable multi-objective optimization test problems K Deb, L Thiele, M Laumanns… - Proceedings of the …, 2002 - repository.ias.ac.in Cited by 554 2002 50 cites/yr for rockstar K.Deb
  13. Multi-class ROC analysis from a multi-objective optimisation perspective RM Everson, JE Fieldsend - Pattern Recognition Letters, 2006 - Elsevier Cited by 75 2006
  14. PDE: a Pareto-frontier differential evolution approach for multi-objective optimization problems HA Abbass, R Sarker, C Newton, 2001. Proc, ieeexplore.ieee.org Cited by 332 2001
  15. Genetic local search for multi-objective combinatorial optimization A Jaszkiewicz - European journal of operational research, 2002 - Elsevier Cited by 460 2002
  16. Fundamentals of computational swarm intelligence AP Engelbrecht - 2005 - lavoisier.fr Cited by 1168 2005
  17. Multi-objective optimisation using the bees algorithm DT Pham, A Ghanbarzadeh - Proceedings of IPROMS 2007 …, 2007 - people.stfx.ca Cited by 59 2007
  18. Multi-objective optimisation applied to industrial energy problems G Leyland - 2002 - lania.mx Cited by 99 2002
  19. An evolution strategy with probabilistic mutation for multi-objective optimisation S Huband, P Hingston, L While…, CEC'03. The …, 2003 - ieeexplore.ieee.org Cited by 57 2003
  20. Evolutionary algorithms for solving multi-objective problems CAC Coello, GB Lamont, DA Van Veldhuisen - 2007 - books.google.com Cited by 3709 2007

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,[11] 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.  :-)

an overview of the major research areas in engineering design optimization, especially the CAE stuff

Section 10. Future challenges in algorithmic engineering design optimisation. Considering the growth in publications using the algorithmic approach for EDO, this approach has the best potential to improve a design. Fig. 10 shows lack of popularity of algorithmic approach for mechanical systems design optimisation compared to non-mechanical systems. ((JPEG: papers published per year, 1997 through 2006, in the field of design-optimization-generally-aka-mostly-for-software-apps versus the subfield of design-optimization-for-mechanical-parts-aka-trains-planes-and-automobiles. 400/yr to 1100/yr strong growth for non-mechanical EDO, versus only 50/yr to 200/yr tepid growth for mechanical EDO... which is FIPER and SORCER's speciality.)) This section identifies the major challenges of algorithmic approaches for real life optimisation and then comments on the possible reasons for lack of interest in the mechanical systems design community. The major challenges are:

  1. 1. Real life features: .... ((MATH == applied math context versus theoretical computer science context ... elegant algorithms often have pathological corner cases in practice that make the airplane-design go awry))
  2. 2. Model development: .... ((CAD&CAE == fundamental features))
  3. 3. Designer confidence: .... ((EECS == GUI design + knowledge-based systems AI))
  4. 4. Design improvement process: .... ((MBA == management buy-in and process re-engineering and other people-problems))
  5. 5. ((CAD&CAE == applied grid computing)) Computational expense of design evaluation: One approach to deal with computationally expensive design evaluation models is to develop surrogate models to replace the expensive design models. Increasingly there is demand to work with more accurate models and find ways to deal with the computational costs. In line with this there is increasing interest to solve real life large-scale design optimisation problems. Recently, use of grid and distributed computing is beginning to address this issue for large-scale optimisation problems.[141,142] This is discussed in more detail in Section 11. ((typo in original... they said 12 but obviously meant 11.))
  6. 6. ((CAD&CAE == advanced statistical features)) Qualitative design space: .... ((this is what Kolonay and Sobolewski are working on nowadays... predicting vehicle-defensive-capabilities *directly* from the raw CAD model giving length/weight/etc physical-data))
  7. 7. ((CAD&CAE == advanced simulation-based features)) Integration with CAD and simulation: The bidirectional interface between feature-based parametric CAD models and optimisation/analysis models that ensure automatic bidirectional conversions do not exist at present. Several researchers have identified this deficiency.[143,144] Nosner noted[143] that after the shape or topology optimisation stage, the design engineer still has to interact with the results to ensure that features are integrated into the CAD model in an appropriate way. Researchers[143,145] have noticed that the lack of feature information prevents the application of meaningful engineering constraints. Addressing these needs requires high level geometric reasoning such as feature technology/recognition to be more integrated into the analysis algorithms and the optimisation procedure to achieve what has been termed feature-based optimisation.[145] When these are addressed, several advantages will make optimisation techniques more attractive to engineers in industry who are not experts in optimisation techniques. For example, most loading and boundary conditions can be automatically extracted from feature-based CAD model of a product. Also, it would be easier to automatically generate intuitive visualisation which has been identified by Hernandez et al.[146] as a key need in order for engineers in industry to be comfortable with the use of optimisation techniques. The application of geometric modelling and reasoning will allow analysis (e.g. FEA), optimisation algorithms and parametric feature-based CAD systems to be transparently and intuitively integrated. In the short term, this may mean an integrated information backbone or infrastructure[147((==Kolonay/Burton'04))] that is flexible to support changes in geometry, meshes etc and able to dynamically link with FEA or optimisation and CAD systems through data exchange of native parametric CAD formats. In the long-term, it would require an extendible integrated information infrastructure for CAD/FEA/Optimisation based on international interoperability standards such as STEP (ISO 10303).
  8. 8. Selecting an appropriate optimisation algorithm: .... ((EECS == algorithms))
  9. 9. Dynamic optimisation: .... ((EECS == evolutionary computing))
  10. 10. Education of designers: .... ((EDU == pedagogy for aero-engineering))
  11. 11. Inherent uncertainty: .... ((EECS == fuzzy sets and other AI techniques))

Section 11. Future approaches to engineering design optimisation. It is observed from the analysis presented above there are three major areas of improvement when it comes to use of computing to address engineering design optimisation: improve efficiency and speed of optimisation and use human knowledge effectively where necessary. The two following sections will discuss role of Grid and distributed computing to speed up the optimisation and involve multiple experts in the design process; and emergent computing techniques for better efficiency and speed in the optimisation. Subsection 11.1. Engineering design optimisation using grid and distributed computing. Large-scale EDO of complex mechanical systems such as aerodynamic wing design and gas turbines involve complex processes with multiple iterative steps that require huge data and computational resources to obtain satisfactory optimum solutions.[153((==Goel/Talya/Sobolewski07)),154] The use of control theory and parallel distributed computing has proved to greatly improve the speed of aerodynamic shape optimisation of supersonic aircraft design.[155] ...This section presents the advantages of using high performance computing (HPC) and grid computing for the optimisation. ... Subsection 11.2. Emergent computing techniques. Swarm intelligence was identified as a promising new.... Simulated annealing is another popular optimization technique.... Other recent approaches with potential.... Quantum computing is....

Section 12. Summary and concluding remarks. EDO ((engineering design optimization)) has evolved with time from a totally manual process to computer-based approaches. This paper proposes a classification of the optimisation problems....

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.[12] 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. 74.192.84.101 (talk) 16:45, 4 January 2014 (UTC)[reply]

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
c
19:02, 6 January 2014 (UTC)[reply]