Why SORCER?
A record keeping system (writing) is crucial to a society’s evolution towards complexity. Obviously languages and nomenclature expressing problems being solved evolve in time. While languages define mankind, writing defines civilization. The Service Era following Information Era requires not only new technologies, but it requires front-end service-oriented languages that are supported by relevant Service and Communication Technologies (tSCT). Programming (software) languages have been developed for computers; service-oriented languages are required predominantly for human beings (front-end side Domain Specific languages (DSL)), e.g., people communicating within their domain in the network of ubiquitous services.
Nowadays we can say everything is a service like in the eighties everything was an object (object-orientation). Are service-oriented languages similar to object-oriented languages? From computing point of view data, applications, tools, utilities, and control strategies are services. But, a human request becomes a service itself or more precisely a service model. A runtime front-end service composition (like collaborating objects for a message sent in object-oriented programming) executing the service model is a runtime service provided by the service-oriented environment, e.g., SORCER—the network shell with the corresponding Service-oriented Operating System (SOS). These requests expressing service models are called netlets that are actualized by SOS. The Service Era requires new front-end service-oriented DSLs to support interoperability of netlets and new generation of operating systems.
Architectural attributes of small-scale and large-scale infrastructures essentially differ in scalability, complexity, and adaptability. Applying client/server architectures (including Web technologies) to complex adaptive systems becomes disappointing. For example, the excerpt from the New York Times articles “Does Not Compute” (January 22. 2005):
"The Federal Bureau of Investigation has officially entered what computer professionals call software hell. After spending $170 million to create a program that would give agents ready access to information on suspected terrorists, the bureau admitted last week that it’s not even close to having a working system. In fact, it may have to start from scratch. Shocking? Not at all. A look at the private sector reveals that software debacles are routine. And the more ambitious the project, the higher the odds of disappointment. It may not be much consolation to taxpayers, but the F.B.I. has a lot of company. Software hell is a very crowded place.
Consider Ford Motor Company’s ambitious effort to write new software for buying supplies. Begun in 2000, the goal of the project, code-named Everest, was to replace Ford’s patchwork of internal purchasing systems with a uniform system that would run over the Internet. The new software was supposed to reduce paperwork, speed orders and slash costs. But the effort sank under its own complexity. When it was rolled out for testing in North America, suppliers rebelled; according to Automotive News, many found the new software to be slower and more cumbersome than the programs it was intended to replace. Last August, Ford abandoned Everest amid reports that the project was as much as $200 million over budget.
A McDonald’s program called Innovate was even more ambitious - and expensive. Started in 1999 with a budget of $1 billion, the network sought to automate pretty much the entire fast-food empire. Software systems would collect information from every restaurant - the number of burgers sold, the speed of customer service, even the temperature of the oil in the French fry vats - and deliver it in a neat bundle to the company’s executives, who would be able to adjust operations moment by moment. Or so it was promised. Despite the grand goals, the project went nowhere. In late 2002, McDonald’s killed it, writing off the $170 million that had already been spent."
ICT is inevitably related to computer networks, SCT to networks of autonomic ubiquitous services. On the one hand, developing standalone software applications to the network reflects negligence of so called “Eight Fallacies” of network computing:
1. The network is reliable. 2. Latency is zero. 3. Bandwidth is infinite. 4. The network is secure. 5. Topology doesn't change. 6. There is one administrator. 7. Transport cost is zero. 8. The network is homogeneous.
On the other hand, technologies that are designed to cope with the Eight Fallacies (for example Jini/River, Rio, and SORCER) are not mainstream technologies since they are not easy to work with (due to lack of experts, education, and complex programming model that uses leases, distributed event, transaction, mobile code, distributed security, and distributed garbage collection). Large software corporations do not support yet these SCT technologies, as they are interested in selling existing ICT software products or updated versions, since they look predominately for return on their investments made in the Information Era.
Our conviction is that the Service Era is here; so we apply federated service technologies, beyond client/server computing, technologies that are explicitly aware of the Eight Fallacies with the innovative front-end service-oriented programming and modeling languages called an Exertion-Oriented Language (EOL) and Service Modeling Language (SML) correspondingly.