Open Learning Service Scenarios on GRIDs

The position paper focuses on the concepts of Service Elicitation and Evaluation/Exploitation Scenarios (SEES) and, in particular, on experimental protocols for justifying, motivating, implementing and exploiting Learning GRID's services for very large numbers of potential users.


INTRODUCTION
The evolution of the technological offer associated to the GRID [1 -4] induces one to reflect on its consequences on the entire life cycle of the new generation of applications on the Internet.In the following, we highlight our understanding of the core of the OGSA concept and we derive our convictions on a new life cycle for GRID technical (infrastructural) developments and GRID applications.
In the following, a few consideration that may be useful for the LEGE WG 3rd Workshop as they may set the stage for the ELEGI EU Integrated Project under negotiation (at the time of writing).

OGSA: OPEN GRID SERVICE ARCHITECTURE
The notion of a service is radically different from the one of a product, even if there may be a smooth transition between the two viewpoints.Assuming typical products to be cars, washing machines, DMBS or Web sites consisting of collections of static HTML pages, typical services may be represented by legal, financial, medical, educational or advising services of many different kinds, including electronic services complementary to and integrated with human services.In order to simplify our subsequent arguments, we will consider "providers" and "consumers" of services, both called Agents, irrespectively on their human or artificial (software + hardware + network) nature.
In order to set the stage, hereafter a few considerations on the differences: 1.
a product is developed by the producer with a clearly predefined goal for the potential consumer, a service is offered within a service domain -or competence area, yet the consumer-specific objectives have to be defined during the initial conversations between the provider and the consumer of the service; 2. a product is supposed to be in correspondence with a well established and a clearly identified need; a service often anticipates to the customer combinations of needs that were not clearly recognised as such by him/her before; 3. a product is most often designed and prototypically developed once, produced many times; the value added by a product increases with the number of copies effectively distributed; a service must be conceived, designed, developed and distributed once for all, as it is custom made for a specific customer with specific needs; the value added by a service increases proportionally with the customer's satisfaction that entails an indirect publicity for the service producer and generates new customers ready to invest more resources in order to have similar services; 4. a product's evolution is slow, as it requires modifications in the conception, design and development; shortly; a revision of the whole life cycle.A service evolves naturally as it is a combination of basic services and products on the fly as a consequence of a service definition and tuning during the conversations with a customer; 5. a product is often chosen as a solution for an established need, even when the customer does not really "trust" the producer's performance (e.g.: even if I dislike cars and prefer a carless city centre, I need one for very practical reasons, and I choose the cheapest one because I plan to use it as little as possible); a service requires trust by the customer on the producer (e.g.: I do not go to a dentist or a lawyer unless I believe (s)he is trustable).
In general, it is quite hard to clearly cut the difference between a product and a service, but a few considerations seem to help to start a reflection on ICT services with respect to ICT products.Let us consider the most classical ICT application, i.e: an Information System, and let us reflect on a paradigm shift: from product to service -for future Information Systems.
Typical Information Systems were developed to satisfy the needs of accurate, well organised, timely updated and trustable Information.This Information is necessary in order to take decisions.
In all the cases where the Information evolves dynamically, as well as the informative needs from the customer evolve continuously, the "Information management system" has to account for both evolutions.
A classical DBMS performs very well under static assumptions, such as the persistence of the logical and physical schemes of the DBMS and of the informative needs of the user.A classical DBMS, and its application for a specific Information system, is much like a "product": developed once and used for years.Any evolution requires heavy resources to redesign the schemas, and import the old as well as the new data.Now, suppose neither the Information available to the Information system is stable, nor the information needs by the user.In this situation, more and more frequent in our organisations, the value added by an Information system becomes directly dependent from its flexibility, adaptability, dynamicity.
Let us now consider a classical query to an Information system.The success of the query depends of many assumptions, including the following three: a. the querier knows exactly what (s)he needs; b. the querier knows that the system's information may satisfy his/her need; c. the querier knows how to formulate the need.
Current daily situations are far from respecting the above outlined assumptions.Users of Information Systems, as well as navigators on the Web, for any purpose -including eCommerce -do not have a well defined need, do not know if and how the system may satisfy their need, do not know how to formulate a query correctly.The consequence of this situation is that often there is no adequacy at all between the user's real needs and the system's answers.
We may synthetically define the informative process described above as a process where Information is offered as a product while the Information needed is a service.Therefore, one needs to express his/her intentions, desires, constraints and investigate the system's available Information BEFORE being able to formulate correctly a query.The classical run time behaviour of an Information system requires as a prerequisite for the user's satisfaction to support a complex conversational phase in order the subsequently formulated query to be adequate with the user's need.
In the case that the user's needs do not fit with just one Information system (e.g.: I wish to organise my holidays next summer) each partial information (about available flights, trains, ... and about hotels ... and about cultural events, climate, ... and so on) in order to acquire a meaning for the user has to be integrated with other information coming from other information sources.Eventually, a combination of choices will emerge from a sequence of conversations between the user and several information sources, and among information sources themselves (what justifies XML and ontologies).A user wishing a "service for holidays" has currently to compose his/her own chosen "products".In the near future, those combinations will be performed by autonomous artificial Agents, operating on behalf of their owner.
Such a scenario of dynamic generation of services is the major challenge for ICTs in the next years.It is as well described as the major challenge of the OGSA: Open Grid Service Architecture.

THE DYNAMIC GENERATION OF SERVICES FOR HUMAN LEARNING
In order for GRIDs associated to OGSAs to be successful, one needs first a well founded definition of services that eventually may be required by users of OGSA-based Grid applications.The problem is to identify those services in order to construct the software applications necessary to generate them on the fly.
Let us jump back to the anthropomorphic metaphors.It is perhaps necessary, but not sufficient for a doctor to know the anatomy and the physiology of the human body to become a good performing doctor.For a lawyer, the knowledge of the civil code and the jurisprudence is useful but insufficient in order to be a competitive lawyer at the court.One needs practice, examples, real cases.Further, while medical knowledge is for a large part independent from the health context (a doctor, say, in France may cure a patient in Morocco, considering that most Morochians speak French), legal knowledge is highly culture, context dependent.Even Codes are fundamentally different: a process in a Country submitted to the Roman law is quite different from the analogous one submitted to the Anglo-Saxon tradition.Certainly, the degree of context dependency is much higher in services as it is in products.
The case of Educational services is perhaps the most extreme.The service has to stimulate, evaluate and credit human learning, knowledge and skills.I believe that nothing is more context dependent as human knowledge and skills, as well as the associated emotional aspects (motivation, cultural awareness, ...).It is evident that no educational model will ever be successful for human learning if not highly linked to the socio-economic and cultural context of human users.
If we wish to build on GRIDs this kind of services, we have to identify them in an accurately contextualised way.In analogy with the lawyer and the doctor's examples above, the most secure way to identify them is to practice them concretely in well controlled experimental situations and integrate the lessons learned into new requirements and better services.
The first time, for each context, we may conceive to operate like a junior doctor or lawyer: accompanying and helping seniors, better experienced, operating exactly those services to those users.However, in our case -Education -one more difficulty emerges: there are no seniors, as the classical behaviour of parents and teachersthe two major educators known -does not at all include ICTs.
Therefore, we will have to use a quite traditional method for introducing innovation, perhaps to be called a "trojan horse", hereafter indicated in steps: 1. distribute among communities of future users the infrastructures necessary for accessing the Web and rely on their motivation and enthusiasm for a quite popular, accepted activity -access to Web Information.We have identified in ELEGI 3 of those: ▪ The ENCORE project on the construction of an encyclopaedia for Organic Chemistry [8,9]; ▪ The VIAD: Virtual Institute for Alphabetization for Development project , with three sites; one in Larzac, one in Chili, one in Brazil [5,6,7,8]; ▪ The e-Qualification project, focussing on monitoring and qualifying human learning services as well as their effects across ELEGI applications; 2. introduce local "champions" able to bind locally the human users into virtual communities, allow collaborative activities to be developed initially in order to establish mutual confidence and interests.We have some of the champions: Di Castri [5,6] and Figueroa (Easter Island, Chili), Arnaud Martin [7] (Larzac, France), Fabio Paraguaçu [8,9] (Maceio and Rondonia, Brasil), Alain Krief [9] (ENCORE, Organic Chemistry).

3.
offer support to developments that are selected, identified and described by the communities themselves, coordinated by the "champions"; 4. highlight, underline and make explicit the relations between any development of the community and the associated human learning; develop human learning strategies and practices as a support to higher priority goals, such as economic and cultural survival of each member of the community; 5. study the communicative processes in order to identify the technological and human requirements of services adapted to each community, then formulate the requirements as functional specifications for the next generation of GRID's services.
Hereafter, as a consequence of the above consideration, what we believe to be a very innovative definition of software developments for GRID applications, i.e.: the new radically different function of testbeds accompanying OGSA developments for eLearning.

SERVICE ELICITATION AND EVALUATION/EXPLOITATION SCENARIOS (SEES)
In classical software engineering, the major phase was roughly: 1. software functional (informal) specification; 2.
generation of new guidelines in order to loop to 1. and 2. until satisfied.
Testing and evaluation occurs at the end of the process by means of carefully planned and controlled experiences with real potential customers.This life cycle reflects a "product" view of software applications.
When services have to be supported by software, as it is our case, we envision a different life cycle for successful service generation and use, briefly outlined in the following.We will call the two classes of scenarios for each class of actors involved in this new life cycle: SDS (Service Developer's Scenarios) and SUS (Service User's Scenarios).Each scenario is timed by / belongs to a "phase".Each new "phase" adds up the previous ones as a new task cumulating for a holistic integrated approach.Notice that the distinction between SUS and SDS reflects the wide spectrum of meanings the word "service" adopts: from a quite high level, domain dependent meaning (eg: the learning service for a minimal competence on business accounting) , to a low granularity, domain independent, technical meaning (eg: the authentication service for a Peer to access to another Peer, both being software processes). 1.
Service motivation for SUS.In this phase, one has to make sure that the potential users are aware of the value added by the service and wish to be able to use it, once it will be available.Motivation in e-Learning in our case comes from locally empowered virtual communities that experience in their practice the interest for collaborating on the Web.It is not to be excluded that, as a side effect, proposals will emerge from the "durable development" SEES' champions in the direction of developments supporting cultural heritage, otherwise in danger.For instance, it has been reported that natural languages, otherwise disappearing as practised by a few dozens of humans, are currently learned thanks to Courses on the Web.

2.
Service definition by SUS.During this phase, potential users, coordinated by seniors -the "champions" that are aware of the opportunities potentially offered by technological innovations -formulate and discuss among themselves and with other peers initially vague, yet more and more precise functional specifications of the services they might need for their own purposes.Scenarios are generated.From scenarios, drafts of collaborative protocols are extracted.These functional specifications are then used as an input to GRID's technologists working in different workpackages on OGSA for Learning (SDS).

3.
Service use by SUS.While SDS are specifying, designing and developing innovative services, SUS use state of the art (Web + some GRID) technologies for their goals, including progressively e-Learning, generating new experimentally founded considerations, guidelines, observations to be fed back to SDS.

4.
Service evaluation by SUS.During this phase, we wish the services to be evaluated, as well as their e-Learning effects, by submitting SUS to the evaluation and e-qualification procedures suggested by the corresponding workpackage.

5.
Service abstraction and generalisation by SUS and SDS.This task allows one to propose and realise a significant upgrade of the "old" Service Elicitation and Evaluation/Exploitation Scenarios and the identification and implementation of completely new SEES.For instance, from the ENCORE scenario, one may propose biologists to use the services for their own construction of ontologies; from the Easter Island scenario, one may generalize the offer to all EU islands; from the Brasil scenario one may implement experiments in EU suburban areas, currently a real source of socioeconomic problems.

CONCLUSIONS
The paper focuses on the notion of service and the wide spectrum of meanings this notion may take within the ELEGI EU Integrated Project.It also justifies the SEES in ELEGI as an instance of a generic methodology for software service engineering, including design, implementation, monitoring and evolution, as opposed to the classical one aiming mainly to the development of software products.