EP2281271A1 - Method for process management in a collaborative service-oriented workshop - Google Patents

Method for process management in a collaborative service-oriented workshop

Info

Publication number
EP2281271A1
EP2281271A1 EP09757687A EP09757687A EP2281271A1 EP 2281271 A1 EP2281271 A1 EP 2281271A1 EP 09757687 A EP09757687 A EP 09757687A EP 09757687 A EP09757687 A EP 09757687A EP 2281271 A1 EP2281271 A1 EP 2281271A1
Authority
EP
European Patent Office
Prior art keywords
data
atelier
gt
lt
process
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
EP09757687A
Other languages
German (de)
French (fr)
Inventor
Bernard Marquez
Thierry Chevalier
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Airbus Operations SAS
Original Assignee
Airbus Operations SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to FR0853122A priority Critical patent/FR2931276A1/en
Application filed by Airbus Operations SAS filed Critical Airbus Operations SAS
Priority to PCT/FR2009/000567 priority patent/WO2009147311A1/en
Publication of EP2281271A1 publication Critical patent/EP2281271A1/en
Application status is Ceased legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00Administration; Management
    • G06Q10/06Resources, workflows, human or project management, e.g. organising, planning, scheduling or allocating time, human or machine resources; Enterprise planning; Organisational models
    • G06F30/23
    • G06F2111/02

Abstract

The invention particularly relates to a method for process management in a collaborative service-oriented workshop for processing objects associated with data representing real data or processes, each object including a structure for storing links to other objects. After determining at least one function and at least one piece of information enabling the execution of said at least one function, an object including at least one reference to said at least one function and said at least one piece of information is created.

Description

A method for process management in a collaborative service-oriented workshop

The present invention relates to computer architectures for collaborative work and more particularly to a process management method in a collaborative service-oriented workshop.

The optimization study phases of design objects such as vehicles in order to reduce costs and development time typically requires the implementation of a specific IT environment.

For example, study the aerodynamics of an aircraft involves many specialists working on different aspects of the same data, these aspects may be related or unrelated to each other. These specialists usually use different IT tools and various machines for the execution of processes implemented. In addition, these specialists may be located geographically in separate locations.

It is therefore advantageous to implement an environment based on an open architecture for sharing data and computer resources, including computing resources. Such an environment should preferably fit a set of machines and heterogeneous operating systems.

It is also advantageous to use an interface for accessing various existing separate tools. Such common interface includes being adapted to manage data to be exchanged between these tools and to enable selection and easy data access.

In addition, the environment should preferably allow easy adaptation to future needs such as integration of new tools, the management of new data types and manufacture of new types of results. Moreover, there is a need to track data to determine the origin of the data produced and their life cycle in the various modifications and applications in computing or other processes. These problems are partially solved one independently.

There are, for example, software applications such as SynfiniWay developed by Fujitsu Company (SynfiniWay and Fujitsu are trademarks) that allow optimizing the performance of tasks in a heterogeneous environment. The application allows SynfiniWay including virtualized global resources and submit applications as services linked by sequences and data dependencies to automate IT processes.

There are also scripting languages ​​such as Python and Java (Python and Java are trademarks) that automate certain tasks and to use existing tools. Python is a high-level programming language, object oriented interpreted. It can be used in many contexts and adapt to many applications using specialized libraries. The traceability of data is itself generally determined by the process that led to the data. For example, in applications such PDM (Product Data Management acronym in English terminology), the user must follow predetermined process without power waived. The origin of a given well is determined by the process that yielded the data.

However, there is no centralized and optimized environment for the study and design of systems in a heterogeneous open collaborative environment.

The invention solves at least one of the problems outlined above.

The invention thus relates to a process management method in a collaborative service-oriented workshop adapted to process objects associated with data representative of actual data or process, each object comprising a structure adapted to store links to other objects, said method comprising the following steps,

- determining at least one function; - determining at least one information enabling the execution of said at least one function; and,

- creation of an object including at least a reference to said at least one function and said at least one information.

The method according to the invention allows to handle data regardless of their own characteristics, such as their nature, their storage location and size to provide overall management thereof.

Advantageously, said at least one information is a reference to at least one object associated with a data used as input or output of said at least one function. The method according to the invention is able to run the processes represented by objects and to establish links between the objects associated with the processes executed and the objects associated with the actual data implemented by the process, that is ie, for example, used or produced by the process. According to a particular embodiment, said at least one function is a function external to said collaborative service-oriented workshop in order to use existing functions and limit software developments. The process according to the invention thus allows to avoid maintaining several similar versions of software modules. According to another particular embodiment, the method further comprises the following steps,

- determining at least a second function different from said function, called first function;

- determining at least one information enabling the execution of said at least a second function; and - adding to said subject of at least one reference to said at least one second external function and said at least one information enabling the execution of said at least one second function.

The process according to the invention thus enables to create objects associated with composite processes, that is to say, combinations of features.

According to a particular embodiment, the method further comprises a step of converting said object into an executable function by an external module to said collaborative service-oriented workshop for using the function on the outside of the collaborative service-oriented workshop without rewriting the corresponding code.

Advantageously, the runtime of a process model is similar to the process models executed by said oriented collaborative service workshop for said functions executable by an outside module to provide a function execution homogeneity.

According to a particular embodiment, the method further comprises a step of creating an object comprising at least one reference to said executable function by an external module and at least one information necessary for the execution of said executable function by a external module.

The creation process can thus be guided by the desired degree of granularity for the traceability of the data produced and / or used by the processes implemented.

Advantageously, said external function conforms to an execution engine or web tasks allowing a run compatibility of the external function with standard tools.

The invention also relates to a computer program comprising instructions adapted to the implementation of each step of the process described above. Other advantages, objects and features of the present invention emerge from the following detailed description, given by way of example, to the accompanying drawings in which: - Figure 1 schematically shows an example of architecture of a workspace for sharing data and resources of the invention;

- Figure 2, comprising Figures 2a and 2b illustrates a simplified block diagram of the data handler presented in Figure 1 and an exemplary algorithm for determining a data tree, respectively,

- Figure 3 schematically shows the Runtime functional elements illustrated in Figure 1, as well as information transmitted therebetween, for executing a process based on a type of representation Python;

- Figure 4 illustrates the collaborative service-oriented workshop according to the invention, from an application point of view, enabling the execution of executable code from external developments and specific developments;

- Figure 5 illustrates an example of encapsulation of an external function ModelCenter model type in a process model;

- Figure 6 illustrates synthetically an exemplary XML schema for the analysis of a stored process model in the form of XML-based description;

- Figure 7 illustrates an example algorithm for running unit processes instantiated process models;

- Figure 8 illustrates an example data processing can be performed from a collaborative service-oriented workshop according to the invention; and,

- Figure 9 illustrates an exemplary device adapted to implement a portion of the invention.

1 schematically shows an example of an architecture 100 of a workspace for sharing data and resources according to the invention, also called collaborative service-oriented workshop.

As illustrated, this architecture is provided around four main modules: module 105 which relates to access to data, the module 110 which is a data manager module 115 which is an execution engine module 120 and the which is to process management.

The module 105 data access module 110 is connected to data management and a centralized database 125, for instance an Oracle database (Oracle is a trademark). The unit 110 of data management is connected to the centralized database 125, the runtime 115 and 130 representing a set of distributed storage areas may be organized in different ways, such as files or databases of data. The runtime 115 is itself connected to the assembly 130 of storage areas and the module 120 process management.

Although this architecture is particularly adapted to the design of complex objects such as aircraft, the following description is based on a simple example for clarity and brevity. This example is given for illustrative purposes.

The architecture 100 is adapted to manipulate data objects representing data in the broadest sense, such data may be representative of a real object, for example an aircraft, or of such a process that a process of calculation of aerodynamic drag. Simplistically, the collaborative service-oriented workshop works on data represented by data objects based themselves on meta data representing characteristic data.

The data called framework data in English terminology or FD, are therefore stored physical data, e.g., as files in a storage area 130. These data characterize a real object, for example the mesh size or the structure of a chair, or a process, for example, the steps of a relocation process. The size of these data is not limited, it can be several hundred megabytes. All data used may be stored in separate physical locations.

The objects, called Framework object in English terminology or FO, represent objects that have special meaning to the application direction. As previously stated, these objects are used to represent anything that can be manipulated by the collaborative service-oriented workshop. The objects are based on meta-data sets that can be understood as the basic elements or features elements. A set of metadata is thus associated with each object. Each set type metadata can be associated with multiple objects. The qualification of a set type metadata can form an object. If, for example, a set type of meta-data is associated with a chair, a classification of the seat forming an object may be a high chair.

For the sake of clarity, computer implementations of objects, called object framework proxies in English terminology FO or proxies, are here assimilated to the objects themselves.

Among the objects are the models instantiated process called instanciated process templates in English terminology or IPT. The instantiated process models are process models instances, that is to say, process models applied to one or more objects. Process models, process templates called in English terminology or PT, are generic. This example of a process of building a living from several chairs and a table, a process of renovation of a house or moving process. Instantiated process models are represented as objects and can be handled as such in the oriented collaborative service workshop. The metadata, called meta-data framework in English terminology or FMD, correspond to particular information data. They allow characterization data to facilitate handling. A data can be associated with several sets of meta data. The metadata are conveniently stored in the centralized database 125 in tabular or XML (Extensible Markup Language acronym in English terminology). One type is here associated with each set of metadata. Metadata include generic information such as username, date of creation and a creator name and specific information specific to the associated data, eg material, color or weight of a chair. The metadata also include links to objects that include how the data was obtained and / or how they were used. These links allow you to define data models, that is to say the data trees.

The consistency of an object is checked through the links defined in the set of metadata associated with it. For example, a table data model may be determined such that a table is related to a chair. If a table type object is actually associated with a chair type of object, then the table type object is said to be consistent within the meaning of the data model defined through its links.

Metadata are for example described using an XML-based language according to the structure presented in Annex under the reference "snippet." 1

The generic part of the metadata common to all data, so it is defined during the implementation of the collaborative service-oriented workshop. Even if the party has a priori no reason to change its definition may nevertheless evolve as needed. However, its evolution affects all managed objects in the collaborative service-oriented workshop.

The specific part of the metadata is specific to each data type and, therefore, each set type metadata. Setting this part is made by users of the collaborative service-oriented workshop. The information in the specific part of the metadata are determined by the automatic extraction operations to be carried out on the data.

The generic and specific metadata are advantageously used for searching and sorting data in the collaborative service-oriented workshop. The example given in the appendix under the reference "snippet 2" shows the XML description of a type of metadata used to describe a chair.

As described above, meta data preferably comprises a generic part and a specific part. The generic part includes here the following,

- a key to manage the access control to the data;

- a description of the object type;

- a comment that describes the data; - a creation date;

- an identifier of the data that may be a key or a URL to access the data;

- a unique ID of the data;

- information concerning the user who created the data; - the physical location of the data with its geographical location; and,

- the status of whether a change is underway and by whom.

The second part of the metadata specific to the manipulated object, a chair here, in this example includes the following attributes,

- the number of feet;

- the thickness;

- the colour ;

- matter; and the weight.

The generic and specific parties may of course include other types of information.

The identifier or address a set of metadata retrieves the data to which it is associated. The qualification of a set of meta-data representing a chair can be, in particular, "child" or "adult", allowing to achieve two different objects. Similarly, it is possible to define metadata and objects for tables. When importing an object defining a table, it is possible to define, at a data model, that this object is consistent if it is connected to at least one chair type object. Such a relationship between objects is defined by the relationship defined in the metadata. These links can also be represented in XML or in a table. When importing an object of type table, model type of data links between the table object and the chair-type objects must be installed to make this object consisting of the data model and defined. Alternatively, the metadata can be displayed as tables. For example, a table can be associated with each data type. The columns in the table represent metadata while each line represents an object. Table 1 appended illustrates a simplified example of a representation of a set type of metadata that can be associated with data type chair. It should be noted here that the links are not included in the table representing the metadata. In this example, the links are stored in a table of links.

A link table may be represented, for example, in the form of the table given in the annex under the reference table 2, where each column represents a pair of identifiers of objects between which a link is established.

Thus, the information stored in meta data tables and in the table of links used to handle all data, current and future, of the collaborative service-oriented workshop and build data models.

It may be noted here that the representation of meta-data in tables is equivalent to an XML representation and it is possible to use a conversion tool to move from one representation to another.

The representation of data characterizing physical objects or process is thus carried out at several levels:

- raw data; - metadata that represent subsets of raw data extracted from them, to characterize the raw data;

- objects based on the values ​​of metadata, which are handled by the application modules; and,

- the consistent objects are objects related to other objects.

It should be noted here that according to this structure, it is not necessary to implement synchronization processes in the collaborative service-oriented workshop. The module 105 for access to data in particular allows a user to selectively accessing centralized meta-data stored in the centralized database 125, in particular to visualize these metadata, to produce views of these meta -data for efficient sorting of all data available in the collaborative service shop and possibly follow the links between some of these data.

The module 105 can also save metadata in a centralized database 125. It is thus possible for a user to enter metadata through a man-machine interface (HMI) to specify information which is not included in the data stored in the storage areas 130. to access and store metadata, the user interface may use, in particular, of the SQL type requests (acronym for Structured query Language in English terminology ). This manual recording metadata is interesting for adding specific information that can not be automatic extraction object from the data during import of the object in the workshop.

Similarly, the module 105 data access allows a user to selectively access and centralized data stored in the storage areas 130 through the module 110 of data management as well as record data. To access and store data, user interface advantageously uses API (Application Programming Interface acronym in English terminology) and specific web services.

The data handler 110 is used to interface between the module 105 to access data, the centralized database 125, storage areas 130 and the execution engine 115 adapted to apply particular processes on data. The data manager 110 can also control the user access rights.

According to a particular embodiment, the data manager 110 consists of a client part and a server part. The client part can be implemented in a Python-like language to allow access to web services available in the server part. All standard data management functions such as import, export, publishing, collaboration and management rights are preferably available. This list is not exhaustive. The set of functions used during the data lifecycle is available through this API

The server part can be implemented, for example, in Java or Python-like language to allow interfacing with different databases and storage areas. This part also advantageously takes care of the extraction mechanisms of meta-data from the data stored in the storage areas distributed 130 to the centralized database 125 containing metadata.

The runtime 115 allows execution of processes through process-based models, for example, on business applications. An interface between the runtime 115 and storage areas 130 allows direct access via an API or data during execution of the process. The runtime 115 is preferably attached to a computing grid, for example SynfiniWay type, which manages the submission of different processes on a distributed infrastructure and moving data during execution. The runtime 115 also preferably includes an interface with applications that use workflow (workflows in English terminology) as ModelCenter applications (ModelCenter is a trademark) or SynfiniWay, that is to say the execution engines or web tasks.

The process manager 120 allows the creation of workflow high levels, called composite process that encapsulate unit treatment. These workflows can be parametric studies and sensitivity parameters and may allow the creation of role models. These features can then be used in the optimization of multidisciplinary studies.

Thus, treatment of non-unitary process, that is to say making process calls for several different functions, is managed by the process manager for example, decomposed into individual processes that are then executed by the engine 'execution.

Figure 2a is a block diagram of the data manager 110. Using, for example, a file interface or an interface of Corba (acronym for Common Object Request Broker Architecture in English terminology, Corba is a trademark), data is created in various databases (not shown).

A mechanism 200 extraction, transformation and loading, called ETL (acronym for Extract, Transform and Load in English terminology), is then implemented to extract metadata stored data in areas of storage 130. They are stored in the centralized database 125. the database collection data and information of the physical data created in the different storage areas 130 distributed.

It should be noted here that the extraction mechanism is implemented when the data are created, modified or deleted. It is specific to each type of data and metadata.

A function qualifying 205 allows to qualify the metadata extracted to form objects that can be stored in the central database 125. After qualifying, a check is made on the consistency of the object. This consistency can be achieved through links with stored metadata or not, these links can be of different types such as version, configuration, data model and user.

A set of links between objects, defining a data model can be used to determine relationships between objects. Links are associated with metadata. As described above, they are stored with the latter or separately, for example in a link table stored in the centralized database 125.

The links allow subsequently establish traceability data, that is to say the traceability between the various data produced or used during the execution process. There are many types of links, including the following,

- users links manually determined by the user between data; - models links to define a data model. These links are determined generically when creating a data model;

- configuration links for linking a set of objects to manage the configuration, that is to say, to allow the application of identical features such as export duties, import and right shift;

- version of the links that manage the same object in different versions; and,

- production linkages that establish a performance link between a set of objects. This type of link is automatically created when the data release phase during or at the end of the execution of an instantiated process (IPT).

All these links placed in pairs provides traceability supported by the data: the data contains all historical especially regarding the process of executions, versions, configurations, users and templates. It is thus possible to build complete tree of objects linked by metadata and specific connections. In the example of the chair and the table, a shaft allowing to know the meta-data (color and position) of the table checks the data model relating to chairs having as metadata a specific color. Thus, step by step, it is possible to reconstruct the complete tree of obtaining data.

It should be noted here that the data models, that is to say the data trees, are specific to the data manipulated in the collaborative service-oriented workshop. However, if the data model can be derived from relationships between objects, they do not exist as such in the collaborative service-oriented workshop. They are implicitly created when defining objects, that is to say of corresponding sets of metadata to particular types of data.

As shown in Figure 2a, a function 210 110 Data Manager provides access to links and objects to form a consistent view of the objects, that is to say, a view showing the relationship between objects, which can be transmitted to a user in the form of views of data models 215.

Similarly, users can visualize objects and relationships as views of objects 220 and 230 views of relationships, such lists.

Thus, according to this embodiment, the user, that is to say, the client part of the data manager 110 has the following three types of views,

- a view through the metadata on objects in different databases;

- views of the data models created in the architecture 100; and,

- a view to navigate between different objects through links defined in the database metadata, or associated with them, such as the release of links, user links, configuration links and links Production for traceability. An XML-based description of the proxy object type objects containing all the metadata associated with each data is advantageously created to be used, for example, the runtime 115 to access data stored in areas storage 130 during the execution process.

2b illustrates an exemplary algorithm for determining a data tree from the objects handled in the collaborative service-oriented workshop, these objects representing either actual data or processes. After selecting a first object (step 230), for example through a man-machine interface, a link to a second object, contained in the first object, is accessed (step 235). Next, a link to a third object, contained in the second object, is accessed (step 240) to allow to establish a link between the first object and the third (step 245) or between the data associated with the first object and those associated the third object.

Alternatively, a link to a third object, contained in the first object, is accessed (step 250) to allow to establish a link between the second object and the third (step 255) or between the data associated with the second object and those associated the third object.

As suggested by the arrow in dotted lines, these steps may be repeated iteratively, for determining a data tree that leaves represent data (or objects associated with the data) and the branches represent the links between the data ( or between objects associated with data).

3 schematically shows the functional elements of the execution engine 1 15 illustrated in Figure 1, as well as information transmitted therebetween, for executing a process based on a Python type of representation. The runtime engine 115 is activated by an object consisting of a model 300 instantiated process depicted here as an XML document type. The model 300 instantiated process is analyzed in a parser 305 of XML, called XML parser in English terminology, to extract the information for process execution. In particular, parameters, code and information about the data necessary for the execution of the process are extracted from the XML document. Similarly, the data used by the process, forming the inputs of the process, are found using links on the objects concerned. All the information needed to process execution extracted from the XML document is transmitted to the core 310 of the runtime.

The model code 300 instantiated process, that is to say, the data associated with the object representing the model instantiated process directly corresponds to instructions executable by the execution engine, executable instructions through specific interface, for example Python code type, or functions or external modules called by the runtime such as ModelCenter functions.

The execution of the process associated with the instantiated process model

300 may result in the creation of new objects 315, forming the output of the process. These objects are treated the same way as previously described objects. In particular, meta-data and links stored in the centralized database 125 as well as data stored in the storage areas 130 are associated with these objects. Alternatively or additionally, the input of the process can be modified during the execution thereof. Modified entries forming an outlet of the process are called input / output.

The core runtime 310 is preferably a 320 call runtime environment, also called the execution context of the instantiated process model. The runtime environment is especially designed to keep a history of the execution of the process (325) to make the data available in the runtime format (330), such as type objects python, monitor the execution of the process (335) and provide the interfaces 340 necessary for the implementation of plug-ins to the runtime of the core.

When a process is executed and, in particular, when new objects are created, one or more links are automatically created in the metadata associated with the data used by the process

(Inputs, outputs and inputs / outputs) as well as metadata associated with the model instantiated process.

Before a process is executed, metadata associated with the model instantiated process include references to objects associated with data to be used but contain no link.

Links are thus created in each object when the process is executed.

For example, when a given process uses to produce a result, the following links are created during the execution of the process,

- a link to the object associated with the process model is created in the object associated with the input data;

- a link to the object associated with the input data is created in the object associated with the process model;

- a link to the object associated with the output data is created in the object associated with the process model; and - a link to the object associated with the process model is created in the object associated with the output data.

Figure 4 shows an example of implementation of the collaborative service-oriented workshop of the invention, an application point of view, allowing the execution of executable code 400 from external developments (405) and specific developments (410). As shown, the execution of instantiated process models is recursive.

Depending on the nature of the executable code and the implementation of the collaborative service-oriented workshop, the executable code is executed by the collaborative service-oriented workshop or an external application. To illustrate, here is the executable code executed by the collaborative service-oriented workshop if type

Python and an external application if, for example, type ModelCenter

(TM). The executing external functions to the collaborative service-oriented workshop is performed according to an encapsulation mechanism external functions in process models. 5 illustrates an example of encapsulating a ModelCenter model in a process model. If the executable code is Python type, the data necessary for the execution of code, including in particular the references to input and output data as well as the runtime environment, are formatted according to the format python (module 415). The thus formatted process is then encapsulated (module 420) in a process model which can be handled by the collaborative service-oriented workshop as a standard object (module 425). As illustrated by the arrow connecting the module 425 to the module 415, the process model uses the Python interface when the process should be executed.

Similarly, if the executable code is type ModelCenter, the data necessary for the execution of code, including in particular the references to input and output data as well as the runtime environment, are encapsulated according to the size ModelCenter (module 430). The thus formatted process is then encapsulated (module 435) in a process model which can be handled by the collaborative service-oriented workshop as a standard object (module 425). Again, as illustrated by the arrow connecting the module 425 to the module 430, the process model uses the suitable interface, here interface ModelCenter when the process should be executed to enable the execution of the outside process the collaborative service-oriented workshop. As suggested by the reference 460, other formats may be used.

The instantiation of the process model may be carried out after the encapsulation process using a human-machine interface, i.e. here between the modules 420 and 425 and between the modules 435 and 425. encapsulation is especially intended to adapt the process models according to a predetermined format. Specifically, encapsulation allows to check the validity of the data, to determine the necessary parameters and impose default values ​​for missing parameters and copy and / or generate the appropriate code. Optionally, the encapsulation also allows you to define implementation guidelines, that is to say to set, for example, what are the machines that are to be executed processes or parts of processes.

The encapsulation of external functions in a process model is preferably performed using the following XML sections

- inputs and outputs: links to objects associated with the data managed in the collaborative workshop for their use in external features;

- parameters settings used by the external functions; and,

- code: call to the external function.

5 illustrates an example of encapsulating a ModelCenter 500 model in a model of process 505. As shown, a link is established between each section of the process model and the corresponding fields of ModelCenter model. The call to the executable code ModelCenter model here is done through a Python script 510.

Thus, a process model may use an external function to the collaborative service-oriented workshop. Due to the structure of the objects associated with the process models and in particular links, traceability of data used as input or output process models using external functions is possible.

Similarly, it is also possible to encapsulate process models in external functions, for example in ModelCenter models. Thus, process models developed in the collaborative service-oriented workshop can be directly used by external applications. Via this mechanism, it is possible to use and link process models to other external functions while retaining, at runtime, the use of data managed in the collaborative service-oriented workshop and traceability associated.

The execution of process models from an external application is achieved by the neutral execution module of the integration layer of the collaborative service-oriented workshop called SRUN used to perform the instantiated process models.

A process model can encapsulate external functions and can be encapsulated in external functions. In this dual encapsulation mechanism, the degree of data traceability is thus determined by the functions performed by the collaborative service-oriented workshop and external applications.

To illustrate, if a process model A of the collaborative service-oriented workshop uses functions B 1 C and D, B and C are process models of the collaborative service-oriented workshop and D being a model ModelCenter which itself uses E and F functions, where E is an external function and F being an encapsulated process model of collaborative service-oriented workshop, you can follow the links between B, C and D but not between E and F (simply between input E and output F), performed outside the oriented collaborative service workshop. It is thus possible to determine the level of granularity desired for data traceability.

As previously reported, the data associated to objects characterizing instantiated process models can be represented as files, such as XML file type. process models descriptions advantageously comprise several sections, specific to each type of information.

Process models can be composed themselves process sub-models that can be stored in sections of process models. The process of sub-models here are references to process models available in the collaborative service-oriented workshop. Thus, it is possible to create composite process models with reference to several models of unit processes or themselves composite.

The attributes of an instantiated process model are for example the following,

- the version of the XML schema for extracting process model information; - ID, name, version, and the process model of the kind;

- the identifier of the instantiated process model;

- the identifier of ModelCenter type of execution if the instantiated process model refers to a type of function ModelCenter; - paths mechanisms for implementing the secure way to process (called sandboxes in English terminology);

- the execution state of the process model that specifies what state execution is instantiated process model, eg subject, running, successfully executed or executed with error;

- the state of the process model defining its internal state, for example primary, partially instantiated, instantiated, running or executed; and,

- comments. The section on the inputs, outputs, the inputs / outputs and parameters of a model of instantiated process includes for example the name, type and class. Other information may be associated with inputs, outputs, the inputs / outputs and parameters of a model of instantiated process such as the type of user concerned, a description and help. One section is used for each input, output, input / output and parameter.

The section on the execution context of a model instantiated process includes a classification section specifying the tools used during the execution of the instantiated process model. The section on the execution context of a process instantiated model also includes a context creation section for storing the execution context of the instantiated process model and a current execution context section specifying the configuration to be used to perform the process and for storing the choices performed by the calculation grid controller. The section on the execution context of an instantiated process model may also include a runtime server section to specify the configuration of the worksheet chosen during the process model instantiation and a section of implementation report completed at the end of the execution of the process containing such an error code or business information related to the execution of the process. The attributes of the context of creation of sections and current execution context are for example the following,

- the name and type of the machine used to run the process and the type of operating system; and,

- the date of creation of the context or process execution.

The relative data section of an instantiated process model is provided for storing private data in the process model, available during the execution of the process. This section can include itself sections such as sections specific to particular processes such as ModelCenter type of process.

The section on the code of a model instantiated process includes the code of the process to be executed. The attributes in this section are for example the language such as Python, code version and possibly comment.

A model instantiated process may also include a description of the list of available servers and / or preferred server to execute the process.

6 illustrates an exemplary synthetic scheme of XML 600 for analyzing a stored process model in the form of XML-based description. The type of XML schema 600 describes the different sections contained in a process model representing files and links to XML sections of data management and parts management processes.

Links in continuous bold lines represent the inclusion links in solid lines represent the concept of import and the dotted Trait links represent the notion of implicit import. PT type extensions (Process Template) are associated with process models, that is to say at runtime, type the extensions DM (Data Management) are associated with the data, that is to say, the data manager, and the MC type extensions are associated with ModelCenter, that is to say for a particular manager process.

As illustrated, a process model 605 comprises several subassemblies 610-640 here corresponding to the sections of inputs, outputs, parameters, servers, execution context, data and code, respectively. The sections related to inputs, outputs and parameters include themselves arguments 645.

The process model implicitly includes information on specific models 650-1 to 650-n such as EDMG models (Editor Template Generalized acronym) ModelCenter and Excel (Excel is a trademark). The ModelCenter model of the process model receives information of a particular model 655.

a reference to the function to be noted here that the Excel template used be used, for example a URL (Uniform Resource Locator acronym in English terminology) while ModelCenter model is due to encapsulation, included in the process model.

The data specified in sections 610, 615 and 620 are derived from the 660 objects that themselves comprise links (665 and 670) to other objects. Therefore, references 600 to 650 are associated with the generic process model while the set of references corresponds to a model of process instantiated. It should nevertheless be noted here that the parameters 520 can also be changed manually by the user.

Figure 7 illustrates an exemplary algorithm 700 for running unit processes instantiated process models.

The model 705 instantiated process is first analyzed (step 710) to check its validity using a predetermined XML schema 715. If it is not valid, the process execution is stopped and a another model instantiated process can be treated. If the model instantiated process is valid, the information contained in this model are extracted (step 720). The extraction of information serves in particular to determine the configuration of the execution context 725 as well as the execution environment 730 may in particular comprise the inputs, outputs, inputs / outputs, parameters and / or specific data pattern instantiated process. In a preferred embodiment, the configuration of the execution context 725 and the runtime environment are determined by the Python format.

The execution context configuration is then controlled according to the validity of the execution domain (step 735). Indeed, the creator of a process can specify a range of validity, such as a specific version of software. If a user wants to use a different version, it can be alerted or forced to change his choice, the condition of validity of execution domain was not satisfied. If the configuration is invalid, the process execution is stopped and another instantiated process model can be treated.

If the configuration is valid, the conditions on the inputs and the inputs / outputs are checked (step 740). When instantiating the process it may be that the user has referenced an object that can not be used in this process because it does not meet the conditions set by the creator of the process. In the example on the table and chair, the moving process can, for example, have a specific color as a condition of the chair. If the user chooses a chair of another color, the removal process can not take place. If the conditions on the inputs and the inputs / outputs are not valid, the process execution is stopped and another instantiated process model can be treated.

If the conditions on the inputs and the inputs / outputs are valid, the execution of the process is implemented according to the code of the instantiated process model (step 745), that is to say according to the data associated with the object representing the model instantiated process. The code of the instantiated process model is then executed

(Step 750). Generally, the core of the execution module called SRUN, loads the inputs, the inputs / outputs and the Python modules necessary for execution of the code. If necessary, a runtime environment distributed, based on the capabilities of SRUN execution module can be implemented.

In the case of composite process models instantiated, Runtime SRUN created in memory as instances of process models and executes successively as unitary process models instantiated. Consistency between different unit process is then provided by the runtime workflow or workflow. During process execution, the script containing the code is executed in the corresponding execution environment, possibly on a different machine from the data manager, depending on the choice of the calculation grid manager. Preferably, the mechanisms for the execution of securely processes are used for reading and writing the physical data, to store the execution history of the process and for the temporary storage of data.

After running the script, that is to say the process, the runtime sends the output to the appropriate domain and stores the implementation report. Figure 8 illustrates an exemplary data processing 800 may be performed in a workshop oriented collaborative service according to the invention. In this example, data 805 correspond to information on a ruined house. An object, referring to the metadata is associated with the data, specifying the ruined state, and other information deemed relevant, here the number of parts and the number of windows. 810 data correspond to the information relating to a living house. Again, an object, referring to meta data associated with the data, specifying a state, here the living state, and information deemed relevant, that is to say the number of parts here and the number of windows. The data 810 can be obtained from the object-related data 805, and thus from the data 805, using an object representing a model instantiated renovation process 815. Similarly, the object corresponding to the data 810 can be combined with a type of object dining room data-bound 820 and an object of type bed-related data 825 in an instantiated process model. Moving 830 to create an object type house inhabited related to data 835. The metadata related to data 835 specify here inhabited status and the number of rooms and windows.

The example given in the appendix under the reference "snippet 3" illustrates a simplified example of metadata associated with the data 805 of Figure 8 prior to the execution of the renovation process. As shown in this example, metadata include generic information, including the type and name of the object and the link to access the relevant data, and specific information by the state, the number of windows and the number of room. Note that the meta-data of the IN type, ie they do not correspond to data created by a model instantiated process.

The model renewal process that can be used to treat the above example represents a ruined house can be described generically as presented in the appendix under the reference "snippet." 4 This model process takes as input a house type object created as output another house type object. This process model can be instantiated to contain such, references to objects associated with data 805 and 810 of Figure 8. The model instantiated process is then, for example, that given in Annex under the reference "snippet 5 ". As indicated, the instantiated process model further comprises execution parameters, identification of the execution machine, the application configuration used and the historic execution links between the objects associated with the data 805 and instantiated process model 815 and between objects associated with instantiated process model 815 and data 810.

After executing the process corresponding to this model instantiated process metadata related to data 805 are altered to add a historical link to the traceability of data. The metadata associated with the data 805 may, therefore, after the execution of the process, be represented in the manner given in the appendix under the reference "snippet." 6 As specified in this example, a link was established between the objects associated with data 805 and the model instantiated process 815. Thus, using the object associated with instantiated process model 815, it is possible to a link between the objects associated with data 805 and 810.

Similarly, after the execution of the process, the data 810 and the metadata associated with them, including the links are created. The metadata associated with the data 810 can then be represented in the manner given in the appendix under the reference "snippet." 7

As before, a link was established between the object associated with the data 810 and the object associated with instantiated process model 815. Thus, using the object associated with instantiated process model 815, it is possible establish the link between the data 805 and 810. note that metadata are here OUT type, ie they correspond to data created by an instantiated in the process model 'collaborative service-oriented workshop. Similarly, a second process model can be created and instantiated to process data 810, 820 and 825 to create the data 835 and the associated object. When the second model instantiated process 830 characterizes a moving process is executed, metadata associated with the data 810 are amended to incorporate the link induced execution of the instantiated process model 830. The metadata associated with the data 810 can then be expressed in the form given in Annex under the reference "snippet." 8

The link established between the associated object data 810 and the object associated with instantiated process model 830 enables, using this object, to establish the link between objects associated with data 810 and 835.

Moreover, during the execution of the second model instantiated process 830, the data are created 835 as well as the associated object. The associated meta data can be represented in the form given in Annex under the reference "snippet." 9

The link established between the associated object data 835 and the object associated with instantiated process model 830 enables, using this object, identify links between objects associated with data 835 and 810, between the associated objects data 835 and 820 and between objects associated with data 835 and 825.

A device adapted to implement a portion of the invention is illustrated in Figure 9. The device 900 is for example a microcomputer, a computer or workstation.

The apparatus 900 here comprises a communication bus 902 to which are connected:

- a central processing unit or microprocessor 903 (CPU, Central Processing Unit acronym in English terminology); - a read only memory 904 (ROM, acronym for Read Only Memory in English terminology) may contain programs "Prog", "Prog1" and "Prog 2";

- a random access memory or cache memory 906 (RAM, Random Access Memory acronym in English terminology) having registers adapted to record variables and parameters created and modified during execution of the aforementioned programs; and,

- a communication interface 918 adapted to transmit and receive data.

Optionally, the device 900 may also have: - a screen 908 for displaying data and / or as a graphical interface with the user who can interact with the programs according to the invention, using of a keyboard and a mouse 910 or other pointing device, a touch screen or a remote control;

- of a hard drive 912 that can comprise the programs "Prog", "Progi" and "Prog2" above and data processed or to be processed according to the invention; and - a memory card reader 914 adapted to receive a memory card 916 and to read or write to data processed or to be processed according to the invention.

The communication bus permits communication and interoperability between the different elements included in the device 900 or connected thereto. The representation of the bus is not limiting and in particular the central unit is able to communicate instructions to any element of the device 900 directly or via another element of the device 900. The executable code of each program enabling the programmable device to implement the process according to the invention can be stored, for example, in the hard disk 912 or ROM 904.

Alternatively, the memory card 916 may contain data as well as the executable code of the aforementioned programs which, once read by the apparatus 900, will be stored in the hard disk 912.

According to another variant, the executable code of the programs can be received, at least partially, via the interface 918, to be stored in an identical manner to that previously described.

More generally, the program or programs can be loaded into a storage means of device 900 before being executed.

The CPU 903 controls and directs the execution of the instructions or portions of software code of the program or programs according to the invention, instructions which are stored in the hard disk 912 or in ROM 904 or in the other elements of aforesaid storage.

When powering up, the program or programs which are stored in a nonvolatile memory, such as hard disk 912 or the ROM 904, are transferred into the random access memory 906 which then contains the executable code of at least one part of the program or programs according to the invention as well as registers for storing the variables and parameters necessary for implementation of the invention. Naturally, to satisfy specific needs, a person competent in the field of the invention can apply modifications in the foregoing description.

ANNEX

Snippet 1:

<Atelier.DM:FrameworkMetaData> <Atelier.DM:Atiributes. Generic />

<Atelier.DM:Attributes.Specific /> </AteIier.DM:FrameworkMetaData>

Snippet 2: <Atelier.DM:FrameworkMetaData xmlns: Atelier.DM = "http://www.societe.com/egat/Atelier/DM">

<= Atelier.DM:Attήbutes.Generic acl_name "Prive" comments = "None" = creation_date "2006-04-27 10:29:43" = db_type ΕLEMENT "externaljd = 'chaise_numero_0010100432325" id- "1411" lock_owner =' None "lock_state =" 0 "mdb_instance =" MDB_exploit "modification_date =" 2006-04-27 10:29:43 "name =" chaise1 "owner =" nom_prenom "publication_level-" Prive "shared_state =" None "website =" Toulouse " source = "LOCAL" status = "Phve" version_comments = "None" version_number = "None" version_owner = "None" version_state = "None" version_ tag- "None" />

<Workshop. DM: Attributes. Specifies nb_pieds = "4" thickness = "5cm" color = "red" material = "timber" weight = "2kg" />

</Atelier.DM:FrameworkMetaData>

Snippet 3:

<Atelier.DM:EEObjectProxy xmlns: Atelier.DM- "http://www.societe.com/egat/Atelier/DM" publish = "0" state = "O" type = "IN"> <Atelier.DM: OriginalPointer>

<Atelier.DM:Pointer external_id- "description for access to the physical data" /> </Atelier.DM:OriginalPointer> <Atelier.DM:ObjectProxy type≈ "HOME"> <Atelier.DM:Pointer external_id = "description access to the physical data "/>

<Atelier.DM:FrameworkMetaData xmlns: Atelier.DM = "http://www.societe.com/egat/Atelier/DM">

<Atelier.DM:Attributes. Generic acl_name = "Prive" db_type = "HOUSE" external_id = "description for access to the physical data" id = "identifier" mdb_instance = "MDB_exploit" modification_date = "" name = "my blue house" source = "CMSDK" status = "Private" />

<Atelier.DM:Attributes.Specific state = "ruined" nb_fenetre = "4" nb_pieces = "10" /> </Atelier.DM:FrameworkMetaData> </ Workshop. DM: ObjectProxy> </ Workshop. DM: EEObjectProxy>

Snippet 4:

<? Xml version = "1.0"?>

<Atelier.PT:ProcessTemplate comment = "my first treatment" creator = "creator" id = "identifier" name = "Renovation home" schemaVersion = "0.1" state = "primary" execution_state = "not_submitted" type = "action" Version = "0.1" xmlns: Atelier.DM = "http://www.societe.com/egat/Atelier/DM" xmlns: Atelier.MC = "http://www.societe.com/egat/Atelier/MC" xmlns: Atelier.PT = "http://www.societe.com/egat/Atelier/PT" xmlns: xsi = "http://www.w3.org/2001/XMLSchema-instance" xsi: schemaLocation = "http : //www.societe.com/egat/Atelier/PT Atelier.PT.ProcessTemplate.xsd http://www.societe.com/egat/Atelier/DM Atelier.DM.xsd ">

<Atelier.PT:SandboxPointer external_id = "" source_name = "" source_site≈ "" source_type = "" type = "" /> <Atelier.PT:lnput category = "object" desc = "ruined house" name- "" type = "HOME">

<Atelier.PT:Condition>

<! [CDATA [number of windows> 3]]> <i Workshop. PT: Condition> </Atelier.PT:lnput> <Atelier.PT:Output category = "object" desc = "habitable house" name = "" type = "HOME">

</Atelier.PT:Output>

<Atelier.PT:Parameter desc = "execution parameters" name = "parajist" type = "list" /> <Workshop. PT: Server>

<Atelier.PT:ValidServer> <! [CDATA [keyword values ​​and describing the machine features]]>

</Atelier.PT:ValidServer> <Workshop. PT: DefaultServer>

<! [CDATA [keyword and defaults machine features]]> </Atelier.PT:DefaultServer> </Ateiier.PT:Server>

<Atelier.PT:ExecutionContext>

<Atelier.PT:Classification ProcessType = "batch"> <Atelier.PT:Suite name = "Suite1" /> <Atelier.PT:Tool name = "Tool1" /> </Atelier.PT:Classification>

<Atelier.PT:CreationContext class = "" date = "" hostname = "" osname = "" type = "">

<! [CDATA [[configuration] keyword and value that describes the application configuration by default

[Validity] validity condition of the application configuration]]> </Atelier.PT:CreationContext>

</Atelier.PT:ExecutionContext> <Atelier.PT:Data/> <Atelier.PT:Code comment = "Comment on the code" language ^ "python" version = "">

<! [CDATA [Code execute]]> </Atelier.PT:Code>

</Atelier.PT:ProcessTemplate>

Snippet 5:

<? Xml version = "1.0"?> <Atelier.PT:ProcessTemplate comment = "my first treatment" creator = "creator" id = "identifier" name = "Renovation home" schemaVersion = "0.1" state = "primary" execution_state = "not_submitted" type = "action" version = "0.1" xmlns: Atelier.DM = "http://www.societe.com/egat/Atelier/DM" xmlns: Atelier.MC = "http: // www. societe.com/egat/Atelier/MC "xmlns: Atelier.PT =" http://www.societe.com/egat/Atelier/PT "xmlns: xsi =" http://www.w3.org/2001/ XML Schema-instance "xsi: schemaLocation =" http://www.societe.com/egat/Atelier/PT Atelier.PT.ProcessTemplate.xsd http://www.societe.com/egat/Atelier/DM Atelier.DM. xsd ">

<Atelier.PT:SandboxPointer extemal_id = "" source_name = "" /> <Atelier.PT:lnput category = "object" desc = "ruined house" name = "Donnée_805" type = "HOME">

<Atelier.PT:Condition>

<! [CDATA [number of windows> 3]]> </ Workshop. PT: Condition> <Atelier.DM:EEObjectProxy publish = "0" state = "O" type = "IN">

<Atelier.DM:OriginalPointer> <Atelier.DM:Pointer extemal_id ~ "description for access to the physical data" />

</Atelier.DM:OriginalPointer> <Ateiier.DM:ObjectProxy type = "HOME"> <Atelier.DM:Pointer external_id = "description - for access to the physical data" />

<Atelier.DM:FrameworkMetaData xmlns: Atelier.DM = "http://www.societe.com/egat/Atelier/DM">

<Atelier.DM:Attributes.Generic acl_name = "Prive" dbjype≈ "HOUSE" external_id = "descήption for access to the physical data" id- "identifier" mdb_instance = "MDB_exploit" modification_date = "" name = "my blue house" source = "CMSDK" status = "Private" />

<Atelier.DM:Attributes.Specific state = "ruined" nb_fenetre = "4" nb_pieces = "10" /> <Atelier.DM:Links>

<Atelier.DM:ϋnk comments = "description of the link" date = "" id_FO_1 = "data identifying 805" id_FO_2 = "815 identifying IPT" mdb_instance = "MDB_exploit" owner = "to39751" subtype- "in the link type" Type = "HI STORY" xmlns: Atelier.DM = "http://www.societe.com/egat/Atelier/DM" /> </Atelier.DM:Links>

</Atelier.DM:FrameworkMetaData> </ Workshop. DM: ObjectProxy> </Atelier.DM:EEObjectProxy> </Atelier.PT:lnput> <Atelier.PT:Output category≈'Object "desc =" habitable house "name =" Donnée_810 "type =" HOME ">

<Atelier.DM:EEObjectProxy publish = "1" state- "1" type = "OUT"> <Workshop. DM: SandboxPointer>

<Atelier.DM:Pointer external_id = "description to access the sandbox" source_name = "" source_site = "" source_Jype = "" type = "" /> </Atelier.DM:SandboxPointer> <Atelier.DM:FinalPointer>

<Atelier.DM:Pointer extemal_id = "description for access to the physical data" /> </Atelier.DM:FinalPointer>

<Atelier.DM:ObjectProxy type = "HOME">

<Atelier.DM:Pointer external_id- "description for access to the physical data" />

<Workshop. DM: FrameworkMetaData xmlns: A telier. DM = "http: // www society com / egat / Workshop / DM..">

<Atelier.DM:Attributes.Geneήc acl__name = "Prive" db_type = "HOUSE" external_id = "description for access to the physical data" id = "identifier" mdb_instance = "MDB_exploit" modification_date = "" name = "my blue house" source = "CMSDK" status = "Private" /> <Atelier.DM:Attributes.Specific state = "Living" nb_fenetre = "6" nb_pieces = "12" />

<A telier. DM: Links>

<Atelier.DM:Link comments = "description of the link" date = "" id_FO_1 = "815 identifying IPT" id__FO_2 = "ID Data 810" mdb_instance = "MDB_exploit" owner = "to39751" subtype = "subtype relationship" kind = "HISTORY" xmlns: Atelier.DM≈ "http://www.societe.com/egat/Atelier/DM" />

</Atelier.DM:Links> </Atelier.DM:FrameworkMetaData> </ Workshop. DM: ObjectProxy> </Atelier.DM:EEObjectProxy>

</Atelier.PT:Output>

<Atelier.PT:Parameter desc = "execution parameters" name = "para_list" type = "list"> <Atelier.PT:ParameterValue> <! [CDATA [of performance parameter]]> </Atelier.PT:ParameterValue> </Atelier.PT:Parameter> <Atelier.PT:Server> <Atelier.PT:ValidServer>

<! [CDATA [keyword values ​​and describing the machine features]]> </Atelier.PT:ValidServer> <A telier. PT: DefaultServer>

<! [CDATA [keyword default and the machine characteristic values]]> </Atelier.PT:DefaultServer>

</ Workshop. PT: Server> <Atelier.PT:ExecutionContext>

<Atelier.PT:Classification ProcessType = "batch">

<Atelier.PT:Suite name = "Suite 1" /> <Atelier.PT:Tool name = "Tool1" />

</Atelier.PT:Classifιcation> <Atelier.PT:CreationContext class = "" date = "" hostname = "" osname = "" type = "">

<! [CDATA [[configuration] keyword and value that describes the application configuration by default [validity] validity condition of the application configuration]]>

</Atelier.PT:CreationContext> <Atelier.PT:RunContext class = "" date = "" hostname = "" osname≈ "" type = "">

<! [CDATA [[configuration] keyword and value that describes the application configuration used]]> </Atelier.PT:RunContext>

<Atelier.PT:RunServer>

<! [CDATA [keyword and value that describes the execution machine used]]> </Atelier.PT:RunServer> <Atelier.PT:ExecutionReportreturn_code= "0"> <! [CDA TA [execution report]]>

</Atelier.PT:ExecutionReport> </Atelier.PT:ExecutionContext> <Atelier.PT:Data />

<Atelier.PT:Code comment = "Comment on the code" language = "python" version = ""> <! [CDATA [Code run]]>

</Atelier.PT:Code>

</Atelier.PT:ProcessTemplate>

snippet 6: <Atelier.DM:EEObjectProxy xmlns: Atelier.DM = "http://www.societe.com/egat/Atelier/DM" publish = "0" state = "O" type = "IN"> <Atelier.DM:OriginalPointer>

<Atelier.DM:Pointer external_id = "description for access to the physical data" source_name = "" source_site = "" source_type = "" type = '' /> </Atelier.DM:OriginalPointer>

<Atelier.DM:ObjectProxy type = "HOME">

<Atelier.DM:Pointer externship Jd = "description for access to the physical data" /> <Atelier.DM:FrameworkMetaData xmlns: Atelier.DM = "http: // www. Societe.com/egat/Atelier/DM"> <Atelier.DM:Attributes.Generic acl_name = "Prive" db_type = "hOUSE" extemaljd = "description for access to the physical data" id = "identifier" mdb_instance = "MDB_exploit" modification_date = "" name = "my blue house" source = "CMSDK" status≈ "Private" />

<Atelier.DM:Attributes.Specific state = "ruined" nb_feneire = "4" nb_pieces = "10" /> <Atelier.DM:Links> <Atelier.DM:Link comments = "description of the link" date≈ "" id_FO_1 = "ID Data 805" id_FO_2 = "815 identifying IPT" mdb_instance = "MDB_exploit" owner = "to39751" subtype = "subtype link" type = "HISTORY" xmlns: Atelier.DM = "http: // www. societe.com/egat/Atelier/DM "/>

</ Workshop. DM: Links> </Atelier.DM:FrameworkMetaData> </ Workshop. DM: ObjectProxy>

</ Workshop. DM: EEObjectProxy>

Snippet 7:

<Atelier.DM:EEObjectProxy xmlns: Atelier.DM = "http://www.societe.com/egat/Atelier/DM" publish = "1" state = "1" type = "OUT"> <Atelier.DM: SandboxPointer>

<Atelier.DM:Pointer external_id = "description for access to the sandbox" /> </Atelier.DM:SandboxPointer>

<Atelier.DM:FinalPointer>

<Atelier.DM:Pointer external_id = "description for access to the physical data" /> </ Workshop. DM: FinalPointer> <Atelier.DM:ObjectProxy type = "HOME"> <Atelier.DM:Pointer external_id = "description for access to the physical data" />

<Workshop. DM: FrameworkMetaData xmlns: Atelier.DM- "http://www.societe.com/egat/Ateiier/DM">

<Atelier.DM:Attήbutes.Generic acl_name = "Pήve" db_type = "HOUSE" external_id = "description for access to the physical data" id≈'ïdentifiant "mdb_instance =" MDB_exploit "modification_date =" "name =" my blue house " source = "CMSDK" status = "Private" />

<Atelier.DM:Attributes.Specific state = "Living" nb_fenetre = "6" nb_pieces = "12" /> <Atelier.DM:Links>

<Atelier.DM:Link comments = "descήption link" date = "" id_FO_1 = "875 identifying IPT" id_FO_2 = "ID Data 810" mdb_instance = "MDB_exploit" owner = "to39751" subtype = "subtype relationship" kind = "HI STORY" xmlns: Atelier.DM = "http://www.societe.com/egat/Atelier/DM" />

</ Workshop. DM: Links> </Atelier.DM:FrameworkMetaData> </Atelier.DM:ObjectProxy>

</Atelier.DM:EEObjectProxy>

Snippet 8:

<Workshop. DM: EEObjectProxy xmlnsΛtelier. DM = "http: // www society com / egat / Workshop / DM.." Publish≈ "1" state = "1" type = "OUT"> <Atelier.DM:SandboxPointer>

<Atelier.DM:Pointer external_id = "description for access to the sandbox" source_name = "" source_site = "" source_type = "" type- "" />

</ Workshop. DM: SandboxPointer> <Atelier.DM:FinalPointer>

<Atelier.DM:Pointer external_id≈ "descήption for access to the physical data" /> </Atelier.DM:FinalPointer> <Atelier.DM:ObjectProxy type = "HOME">

<= Atelier.DM:Pointer external_id "descήption to access the physical data" /> <Atelier.DM:FrameworkMetaData xmlns: = Atelier.DM "http://www.societe.com/egat/Atelier/DM '>

<Atelier.DM:Attributes. Generic acl_name = "Prive" db_type = "HOUSE" external_id = "description for access to the physical data" id = "identifier" mdb_instance = "MDB_exploit" modification_date = "" name = "my blue house" source = "CMSDK" status = "Private" />

<Atelier.DM:Attributes.Specific state = "Living" nb_fenetre = "6" nb_pieces = "12" /> <Atelier.DM:Links> <Atelier.DM:Link comments = "description of the link" date = "" id_FO_1 = "identifier IPT

815 "id_FO_2 =" ID Data 810 "mdbJnstance =" MDB_exploit "owner =" to39751 "subtype =" subtype "type =" link HISTORY "xmlns: Atelier.DM =" http://www.societe.com/ egat / Workshop / DM "/>

<Atelier.DM:ϋnk comments = "description link" date = "" id_FO_1 = "ID Data 810" id_FO_2≈ "IPT identifies 830" mdb_instance = "MDB__exploit" owner = "to39751" subtype = "subtype relationship" kind = "HISTORY" xmlns: Atelier.DM = "http://www.societe.com/egat/Atelier/DM" />

</ Workshop. DM: Links> </Atelier.DM:FrameworkMetaData> </Atelier.DM:ObjectProxy>

</ Workshop. DM: EEObjectProxy>

Snippet 9:

<Atelier.DM:EEObjectProxy xmlns: Atelier.DM = "http://www.societe.com/egat/AteIier/DM" publish = "1" state = "1" type = "OUT"> <Workshop. DM: SandboxPointer>

<Atelier.DM:Pointer external_id = "description for access to the sandbox" /> </Atelier.DM:SandboxPointer> <Atelier.DM:FinalPointer> <Atelier.DM:Pointer external_id = "description for accessing the physical datum "f>

</Atelier.DM:FinalPointer> <Atelier.DM:ObjectProxytype= "HOME">

<Atelier.DM:Pointer external_id = "description for access to the physical data" /> <Workshop. DM: FrameworkMetaData xmlnsiA telier. DM = "http: // www society com / egat / Workshop / DM..">

<Atelier.DM:Attributes. Generic acl_name = "Prive" db_type = "HOUSE" externaljd = "descήption for access to the physical data" id = "identifier" mdb_instance = "MDB_exploit" modification__date = "" name = "my blue house" source = "CMSDK" status = "Pήvate" /> <Atelier.DM:Attributes.Specific state = "live" nb_fenetre = "6" nb__pieces = "12" />

<Atelier.DM:Links>

<Atelier.DM:Link comments = "description of the link" date = "" id_FO_1 = "830 identifying IPT" id_FO_2 = "ID Data 835" mdb_instance = "MDB_exploit" owner = "to39751" subtype = "subtype relationship" kind = "HISTORY" xmlns: Atelier.DM = "http://www.societe.com/egat/Atelier/DM" />

<Atelier.DM:Link comments = "description of the link" date = "" ^ id_FO_1 "IPT identifies 830" id_F0_2 = "ID Data 835" mdb_instance = "MDB_exploit" owner = "to39751" subtype = "subtype relationship" kind = "HISTORY" xmlns: Atelier.DM = "http://www.societe.com/egat/Atelier/DM" /> <Atelier.DM:ϋnk comments ^ description of the link "date =" "^ id_FO_1" IPT identifier

830 "id_F0_2 =" ID Data 835 "mdb_instance =" MDB_exploit "owner =" to39751 "subtype =" subtype "type =" link HISTORY "xmlns: Atelier.DM =" http://www.societe.com/egat / Workshop / DM "/>

</ Workshop. DM: Links> </Atelier.DM:FrameworkMetaData>

</ Workshop. DM: ObjectProxy>

</Atelier.DM:EEObjectProxy>

Table 2 •

ID1 5 8 3 5 ...

ID2 8 5 1 1 ... ...

Claims

1. Process control method in a workshop oriented collaborative service implemented in a computer system, said method being characterized in that said collaborative service-oriented workshop is adapted to process objects associated with data representative of actual data or process each object comprising a structure adapted to store links to other objects, and in that the method comprises the following steps,
- determining at least one function (510);
- determining at least one information (500) for performing said at least one function; and - creating an object (505) comprising at least one reference to said at least one function and said at least one information.
2. Method according to the preceding claim wherein said at least one information is a reference to at least one object associated with a data used as input or output of said at least one function.
3. The method of claim 1 or claim 2 ia wherein said at least one function is an external function to said oriented collaborative service workshop.
4. A method according to any preceding claim further comprising the following steps,
- determining at least a second function different from said function, called first function;
- determining at least one information enabling the execution of said at least a second function; and - adding to said subject of at least one reference to said at least one second external function and said at least one information enabling the execution of said at least one second function.
5. A method according to any preceding claim further comprising a step of converting said object into an executable function by an external module to said oriented collaborative service workshop.
6. A method according to any preceding claim wherein the runtime environment (750) of a process model is similar to the process models executed by said oriented collaborative service workshop for said functions executable by a module outside.
7. A method according to claim 5 or claim 6 further comprising an object creating step comprising at least one reference to said executable function by an external module and at least one information necessary for the execution of said executable function by an external module.
8. A method according to any preceding claim wherein said external feature is consistent with a runtime or series of tasks.
9. A computer program comprising instructions adapted to the implementation of each step of the method according to any preceding claim.
EP09757687A 2008-05-14 2009-05-14 Method for process management in a collaborative service-oriented workshop Ceased EP2281271A1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
FR0853122A FR2931276A1 (en) 2008-05-14 2008-05-14 Method of managing processes in a workshop oriented collaborative service
PCT/FR2009/000567 WO2009147311A1 (en) 2008-05-14 2009-05-14 Method for process management in a collaborative service-oriented workshop

Publications (1)

Publication Number Publication Date
EP2281271A1 true EP2281271A1 (en) 2011-02-09

Family

ID=40011034

Family Applications (1)

Application Number Title Priority Date Filing Date
EP09757687A Ceased EP2281271A1 (en) 2008-05-14 2009-05-14 Method for process management in a collaborative service-oriented workshop

Country Status (5)

Country Link
US (1) US8984016B2 (en)
EP (1) EP2281271A1 (en)
JP (1) JP5524187B2 (en)
FR (1) FR2931276A1 (en)
WO (1) WO2009147311A1 (en)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105723659B (en) * 2013-11-12 2019-06-14 艾思玛太阳能技术股份公司 The method for communicating system control unit with more generating equipments
US10372789B2 (en) * 2014-08-22 2019-08-06 Oracle International Corporation Creating high fidelity page layout documents
US20170032057A1 (en) * 2015-07-30 2017-02-02 Siemens Product Lifecycle Management Software Inc. Collaborative Virtual Mechanical Routing Development System and Method
US9910762B2 (en) * 2015-08-21 2018-03-06 Oracle International Corporation Unified sandbox
US10382374B2 (en) * 2017-04-06 2019-08-13 International Business Machines Corporation Privileged and protected announcements, broadcasts, or posts

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH08286962A (en) * 1994-12-16 1996-11-01 Internatl Business Mach Corp <Ibm> Method for scheduling processing system and object activity
WO1997038386A1 (en) * 1996-04-10 1997-10-16 Konnersman Paul M Computer-based system for work processes that consist of interdependent decisions involving one or more participants
US5991535A (en) * 1996-07-03 1999-11-23 Sun Microsystems, Inc. Visual composition tool for constructing application programs using distributed objects on a distributed object network
US5860004A (en) * 1996-07-03 1999-01-12 Sun Microsystems, Inc. Code generator for applications in distributed object systems
US6067477A (en) * 1998-01-15 2000-05-23 Eutech Cybernetics Pte Ltd. Method and apparatus for the creation of personalized supervisory and control data acquisition systems for the management and integration of real-time enterprise-wide applications and systems
US20020188735A1 (en) * 2001-06-06 2002-12-12 Needham Bradford H. Partially replicated, locally searched peer to peer file sharing system
CH703081B1 (en) * 2003-03-19 2011-11-15 Roland Pulfer Analysis of a model of a complex system.
US7653688B2 (en) * 2003-11-05 2010-01-26 Sap Ag Role-based portal to a workplace system
US8554596B2 (en) * 2006-06-05 2013-10-08 International Business Machines Corporation System and methods for managing complex service delivery through coordination and integration of structured and unstructured activities
US7720579B2 (en) * 2006-12-20 2010-05-18 The Boeing Company Method, system, and computer program product for performance monitored aircraft rejected takeoff braking

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2009147311A1 *

Also Published As

Publication number Publication date
US20110087712A1 (en) 2011-04-14
FR2931276A1 (en) 2009-11-20
US8984016B2 (en) 2015-03-17
WO2009147311A1 (en) 2009-12-10
JP5524187B2 (en) 2014-06-18
JP2011521339A (en) 2011-07-21

Similar Documents

Publication Publication Date Title
Kazman et al. View extraction and view fusion in architectural understanding
Harold et al. XML in a Nutshell
US7895315B2 (en) Supporting extensions to production event message schemes via production database server versioning
Krishnakumar et al. Managing heterogeneous multi-system tasks to support enterprise-wide operations
Abiteboul et al. The Active XML project: an overview
KR100269258B1 (en) Integrated case information repository for process meta-model methodologies and systems that support integrated way
US20030182461A1 (en) Service mapping method of enterprise application modeling and development for multi-tier service environments
JP2005510790A (en) Method and apparatus for creating software objects
US8887130B2 (en) Software design and development in a service oriented environment
US10324690B2 (en) Automated enterprise software development
CN101794226B (en) Service software construction method and system adapting to multiple business abstraction levels
US7590972B2 (en) Role-oriented development environment
US20080082569A1 (en) Smart Integration Engine And Metadata-Oriented Architecture For Automatic EII And Business Integration
US8412813B2 (en) Customizable asset governance for a distributed reusable software library
JP2013541784A (en) Management of dataset objects in data flow graphs representing computer programs
US20030167456A1 (en) Architecture for building scalable object oriented web database applications
Deelman et al. Workflows and e-Science: An overview of workflow system features and capabilities
JP2004535021A (en) Managing reusable software assets
US9483238B2 (en) Declarative software application meta-model and system for self-modification
US8959481B2 (en) Determining system level dependencies
US20030177481A1 (en) Enterprise information unification
US7783697B2 (en) Method and apparatus creating network services
US20050203718A1 (en) Knowledge management system with integrated product document management for computer-aided design modeling
EP1015969B1 (en) Method and system for database application software creation requiring minimal programming
US20090007061A1 (en) Meta-model information associated with an enterprise portal

Legal Events

Date Code Title Description
AX Request for extension of the european patent to:

Countries concerned: ALBARS

17P Request for examination filed

Effective date: 20101103

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO SE SI SK TR

DAX Request for extension of the european patent (to any country) (deleted)
17Q First examination report despatched

Effective date: 20110929

REG Reference to a national code

Ref country code: DE

Ref legal event code: R003

18R Application refused

Effective date: 20130618