Method to extend MES functionalities in a message routing system

Abstract

A process extends manufacturing execution system (MES) functionalities in a domain having MES lineage contextualized entities (MLCEs) and commands. The process includes selecting a command implementing the functionality to be extended; contextualizing the command with a MLCE to obtain an entity contextualized command (ECC); extending the MLCE and the ECC, to obtain an extended MLCE (EMLCE) and an extended ECC (EECC); registering in the routing system a first and second handler of the command in association with the lineage of the MLCE and the EMLCE; and communicating between domains by delivering message(s) including a name of the command and the MLCE or the EMLCE, the routing system selecting the first or the second handler, for executing the functionality or the extended functionality, based on a mapping between the lineage registered for the first or the second handlers in the routing system, and a lineage derived from the message.

Claims

1. A process to extend a functionality of a manufacturing execution system (MES) in a computer managed manufacturing execution system (CMMES) based on a messaging routing system for controlling discrete production lines and/or automotive industries, which comprises the steps of: implementing a MES functionality in a domain of a domain driven design used to design the MES, the domain including at least a MES lineage contextualized entity and a command, wherein a lineage of the MES lineage contextualized entity is a recursively resolved inheritance string of the MES lineage contextualized entity and a context of the MES lineage contextualized entity is a model of the domain with predetermined boundaries in which an entity is defined, the domain being programmed to communicate to at least another domain of the domain driven design of the MES through a message of the messaging routing system; selecting the command implementing the functionality to be extended; contextualizing the command with the MES lineage contextualized entity to obtain an entity contextualized command, the step of contextualizing including encapsulating and hiding the entity contextualized command into the MES lineage contextualized entity; extending the MES lineage contextualized entity and the entity contextualized command which implements a selected functionality, to obtain an extended MES lineage contextualized entity and an extended entity contextualized command, corresponding to an extended functionality, the step of extending including encapsulating and hiding the extended entity contextualized command into the extended MES lineage contextualized entity; and registering into the message routing system a first handler of the command, in association with the lineage of the MES lineage contextualized entity, and a second handler of the command, in association with the lineage of the extended MES lineage contextualized entity, wherein a communication of the domain with at least the another domain through the messaging routing system includes delivering from the domain a message on the messaging routing system including a name of the command and the MES lineage contextualized entity or the extended MES lineage contextualized entity, and wherein the messaging routing system selects the first handler, for executing the functionality, or the second handler, for executing the extended functionality, based on a mapping between a lineage registered in the messaging routing system for the first and second handlers, and a lineage derived from the message in the messaging routing system.

2. The process according to claim 1, wherein the step of registering into the messaging routing system the lineages further comprises: storing, in association with the first handler, a first string including, through concatenation with a special character, the name of the command and the name of the MES lineage contextualized entity, and, in association with the second handler, a second string including, through concatenation with a special character, the name of the command with the name of the MES lineage contextualized entity and with the name of the extended lineage contextualized MES entity.

3. The process according to claim 1, which further comprises deriving the lineage from the message in the message routing system by forming a topic string obtained by: if the message includes the extended MES lineage contextualized entity, deriving the MES lineage contextualized entity from the extended MES lineage contextualized entity and forming the topic string by concatenating recursively in the message routing system the name of the MES lineage contextualized entity with the name of the extended MES lineage contextualized entity and the name of the command; and if the message includes the MES lineage contextualized entity, forming the topic string by concatenating in the message routing system the name of the MES lineage contextualized entity with the name of the command.

4. The process according to claim 1, which further comprises further extending at least one of the extended MES lineage contextualized entity and the command, to obtain a further extended functionality; wherein the step of registering registers a further handler of the command including a lineage of a further extended MES lineage contextualized entity; wherein a communication is made delivering on the message routing system the message including the command and the further extended MES lineage contextualized entity; and wherein the message routing system selects the further handler when the lineage registered in the message routing system for the further handler is mapped to a lineage derived from the message in the message routing system.

5. The process according to claim 2, wherein the step of registering the handlers of the command in the message routing system includes: storing the first string and the second string, as a first and second routing key, in a routing table of the message routing system; mapping the first and second routing keys to the first and second handlers, respectively; and performing the step of mapping the lineage registered in the message routing system for the command and the lineage derived from the message in the message routing system by finding a routing key in the routing table having a longest lexicographic similarity with the topic string.

6. The process according to claim 5, wherein the routing table includes at least two interfaces, including: an interface Add functionality to register a handler in the routing table; an interface Route functionality to map a routing key to the handler, wherein the Route functionality returns the handler associated to the routing key matching the lineage derived from the message in the message routing system, by means of the following steps: selecting from the routing table all routing keys starting with letters corresponding to the name of the command in the message; among selected routing keys, finding a deeper routing key, wherein a routing key is deeper than another routing key among the selected routing keys when the routing key includes more MES lineage contextualized entities concatenated with a special character than the another routing key, the deeper routing key corresponds to a most extended functionality; and returning the handler associate to the deeper routing key.

7. The process according to claim 1, wherein the domain driven design includes a plurality of servers, each server implementing one of the domain and communicating to another server through the message routing system.

8. The process according to claim 1, wherein each of the domains belong to a first layer of the domain driven design and the message routing system belongs to a second layer at a lower level in the domain driven design with respect to the first layer, wherein the second layer includes handlers of commands and the message is delivered to the message routing system from the first layer being unaware of a handler.

9. The process according to claim 1, wherein each of the MES lineage contextualized entity and the commands are contextualized together and the MES lineage contextualized entity and the entity contextualized command have a polymorphic behavior.

10. A system to extend a functionality of a manufacturing execution system (MES) in a computer managed manufacturing execution system (CMMES) based on a message routing system for controlling discrete production lines and/or automotive industries, the system comprising: a computer to: implement an MES functionality in a domain of a domain driven design used to design the MES, said domain including at least a MES lineage contextualized entity and a command, a lineage of the MES lineage contextualized entity is a recursively resolved inheritance string of the MES lineage contextualized entity and a context of the MES lineage contextualized entity is a model of said domain with predetermined boundaries, in which an entity is defined, the domain being programmed to communicate to at least another domain of the domain driven design in the MES through a message of the message routing system; select the command implementing the functionality to be extended; contextualize the command with the MES lineage contextualized entity to obtain an entity contextualized command, the contextualize step includes a tool for importing the entity contextualized command into a portion of the MES lineage contextualized entity which is hidden outside the MES lineage contextualized entity; extending the MES lineage contextualized entity and the entity contextualized command which implement a selected functionality, to obtain an extended MES lineage contextualized entity and an extended entity contextualized command, corresponding to an extended functionality, the step of extending including a tool for importing the extended entity contextualized command into a portion of the extended MES lineage contextualized entity which is hidden outside the extended MES lineage contextualized entity; register into the message routing system a first handler of the command, in association with the lineage of the MES lineage contextualized entity, and a second handler of the command, in association with the lineage of the MES extended lineage contextualized entity; and deliver from the domain the message on the messaging routing system including a name of the command and the MES lineage contextualized entity or the extended MES lineage contextualized entity to communicate between the domain and at least the another domain through the messaging routing system, wherein the messaging routing system is programmed to check a correspondence between the lineage registered in the messaging routing system for the first and second handlers, with a lineage derived from the message in the messaging routing system, and to select the first handler, for executing the functionality, or the second handler, for executing the extended functionality, based on the correspondence.

11. A non-transitory computer-readable medium comprising computer executable instructions which, when executed by a computer, cause the computer to carry out steps of method claim 1.

Description

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWING

(1) FIG. 1 is an illustration schematically representing three MES components with corresponding dependency according to the prior art;

(2) FIG. 2 is an illustration schematically representing a message routing system according to the prior art;

(3) FIG. 3 is an illustration schematically representing a MES component with commands and entities according to the prior art;

(4) FIG. 3A is an illustration schematically representing another MES component with commands and entities according to the prior art;

(5) FIG. 4 is an illustration schematically representing an extension of the MES component of FIG. 3, according to a prior art process;

(6) FIG. 4A is an illustration schematically representing an extension of the MES component of FIG. 3A, according to the prior art process of FIG. 4;

(7) FIG. 5 is an illustration schematically representing an extension of the MES component of FIG. 3, according to another prior art process;

(8) FIG. 5A is an illustration schematically representing an extension of the MES component of FIG. 3A, according to the prior art process of FIG. 5;

(9) FIG. 6 is an illustration schematically representing a further extension of the MES component of FIG. 5A, according to the prior art process of FIG. 5A;

(10) FIG. 7 is an illustration schematically representing the MES component of FIG. 3, programmed according to the process of according to the present invention;

(11) FIG. 7A is an illustration schematically representing the MES component of FIG. 3A, programmed according to the process of the present invention;

(12) FIG. 8 is an illustration schematically representing an extension of the MES component of FIG. 7, according to the process of the present invention;

(13) FIG. 8A is an illustration schematically representing an extension of the MES component of FIG. 7A, according to the process of the present invention;

(14) FIG. 9 is an illustration schematically representing a user interface to contextualize commands according to the present invention;

(15) FIG. 10 is an illustration schematically representing an entity lineage of a LegacyQualityTask;

(16) FIG. 11 is a flow chart for evaluating a lineage of a type t;

(17) FIG. 12 is a class diagram for a priority routing table;

(18) FIG. 13 is a flow chart for the priority routing table;

(19) FIG. 14 is an exemplification of Sequence Diagrams for Priority Routing Table Add;

(20) FIGS. 15, 15A and 15B are illustrations of Sequence Diagrams for Priority Routing Table Route;

(21) FIG. 16 is a simplified version of FIGS. 8 and 8A;

(22) FIG. 17 is an illustration schematically representing a further extension of the MES component of FIG. 8A overridden by two peripheral domains (MES components), according to the process of the present invention, based on the possibility to invoke polymorphic behaviors;

(23) FIG. 18 is an illustration schematically representing a base and an extended entity with, respectively, a corresponding command and extended command to activate the entities, according to a method of the prior art; and

(24) FIG. 19 is an illustration schematically representing the base and the extended entities of FIG. 19, and a single command to activate the base or the extended entity, according to the method of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

(25) With reference to FIGS. 7-17, it is hereafter described an example of implementation of a process and a system to extend MES functionalities in a message routing system, according to the present invention.

(26) A manufacturing execution system (MES) is an information technology (IT) layer that integrates business systems (e.g. ERP) and production control systems of a manufacturing organization. The MES drives effective execution of manufacturing operations, by managing production operations from point of order release to manufacturing, to product delivery into finished goods, and by providing information about production activities across the manufacturing organization and supply chain.

(27) In the MES, the MES functionalities are implemented in domain of a domain driven design architecture. The operation of the domains is stored in data organized in logical entities, also referred by MES entities, bound by a plurality of relationships. When an event occurs in a domain, the MES entities needed to process it are read. The interaction among domain is based on the message routing system based architecture. For instance, data of MES entities shared among the domains are transformed from a first data model used in a database into a second data model and the message routing system is arranged to communicate with all domains. At run time, domains interact with one another through the message routing system to control the production line.

(28) A computer managed MES according to the process of the present is particularly adapted for controlling manufacturing processes in discrete production lines and automotive industries, for instance automotive assembly lines including a plurality of stations where operations are performed. In automotive assembly lines, for each station, one or more workplaces are configured, each containing the configuration for production operations. At runtime, each workplace contains a vehicle or a part thereof, represented by its production order, wherein each production order contains the actual operations that must be performed on the vehicle. Operator terminals at each workplace may show the operations of the production order that are associated with the workplace, their status and other relevant information.

(29) Among the functionalities that MES includes are resource allocation and status, dispatching production orders, data collection/acquisition, quality management, maintenance management, performance analysis, operations/detail scheduling, document control, process management and product tracking.

(30) The message routing system is a software engine implementing the procedural dependencies between domains in an event-oriented manner. In other words, instead of having routines that call other routines or subroutines, there are dependencies among events. Message routing system receives events or messages and dispatches them to the appropriate domains. For each domain, adapters adapt the event (or message) to the protocol used by the different domains. The message routing system allows avoiding direct communication between domains and a certain degree of reduction in complexity is obtained by delegating the inter-domain communication to a lower level which is implemented by the message routing system.

(31) Inter-domains communications through the message routing system is improved to support fine-tuning of domains or modification thereof, for functional or infrastructural needs due to evolution of the manufacturing organization, as well as supporting extension or specialization of domains, due a corresponding extension or specialization of the manufacturing processes in the organization.

(32) The process is adapted to be applied to a composite architecture where different domains interact by a layer based on a message routing system. When a domain needs to perform a Remote Procedure Call, the message routing system notifies all the domains that a task must be performed (the procedure call) and the single domain capable of executing the task executes it transactionally, i.e. based on a procedure handling.

(33) Simatic IT UAF of Siemens Corporation may be used as a base for the above mentioned composite architecture. Simatic IT UAF is adapted to manage events which are routed to more than one destination MES component (domain) in a non-transactional way.

(34) According to the process of the present invention, also a transactional execution is supported. Therefore, Simatic IT UAF may be adapted to implement a transitional execution and to support both non-transactional execution and transactional executions.

(35) More particularly, still according to the present invention, polymorphism is provided to the message routing system although command and entities are defined in a not polymorific paradigm.

(36) In order to extend the domains according to the process of the present invention, commands (for instance commands represented in FIGS. 3, 3A of the prior art) bound to the semantics of an existing entity are identified and encapsulated into the existing entity.

(37) Commands and entities with no logical connection remain unchanged. With reference to FIGS. 7 and 7A, for instance, this happens for command FreezeProc and WorkOrder (FIG. 7) and StartOp and Operation Entity (FIG. 7A).

(38) These operations are indicated with extensibility refactoring and allows to transform the domain of FIGS. 3 and 3A into domains 7, 7a respectively.

(39) When needs arise to extend the entities contained in the existing domains 7, 7a the following steps are executed:

(40) a) Identifying the entity to be extended; and

(41) b) Extend the relevant parts, including properties or commands.

(42) For example, instead of domains 3, 4 obtained as extension of domains 1, 2 according to the prior art process represented in FIGS. 4, 4A and instead of domains 6, 7 obtained as extension of entity 1, 2 according to the other process disclosed by the prior art and described with reference to Figs. of 5, 5A, according to the process of the present invention, domains 9, 11 are the result of the extension of domains 8, 10 obtained by extensibility refactoring of domains 1,2.

(43) A graphic user interface is provided to support introduction of command call. For instance, starting from a Graphic User Interface already available in Simatic IT UAF, which allows a developer to define entities with properties, the Graphic User Interface is adapted to allow the developer to add command calls, preferably including the following features:

(44) a) Feature to contextualize commands with an existing entity by means of a keyboard or a mouse; and

(45) b) Feature to visualize entities contextualized commands together with properties on a canvas.

(46) FIG. 9 is an example of a Graphic User Interface to contextualize commands according to an aspect of the process of the present invention.

(47) In order to support the extension of the MES functionality, the following steps are also provided:

(48) a) Enabling or developing a routing capable of delivering command calls, preferably including the following entity contextualized commands:

(49) b) Command Handlers topic: <MethodName>.<EntityLineage>.#

(50) c) Command Calls routing-key: <MethodName>.<InstanceLineage>. or

(51) d) Command Calls routing-key: <MethodName>.<EntityLineage>., where <MethodName> is the name of the command.

(52) The lineage of an entity is a string that gathers the name of the entity and, recursively, the lineage of its base entity.

(53) FIG. 10 schematically represents the Lineage for a LegacyQualityTask entity (in FIG. 10 entity is indicated with class).

(54) In the given hierarchy, the lineage of type LegacyQualityTask is: Task.QualityTask.LegacyQualityTask..

(55) The reference to <EntityLineage> is used to refer to the lineage at compile time, whereas the reference to <InstanceLineage> is used to refer to the lineage at run time. Two different string or nomenclatures may be used to distinguish entity contextualized commands at compile time from entity contextualized commands at run time.

(56) With reference to the diagram block of FIG. 11, it is schematically given the procedure to start evaluating lineage of a entity (in drawing 11 referred as the lineage of type).

(57) The lineage is evaluated when a command is registered into the message routing system or when the domain delivers a message to the message routing system as a request of service, including the command name and the entity. The evaluation is made in the lower layer constituted by the message routing system, in order to retrieve the handler of the command to be executed, being the command unknown in the upper layer including the domain making the request.

(58) In the following, some examples of possible implementation of the process are given.

(59) A routing table is stored in the message routing system.

(60) The routing table can be represented by a simple interface having two functionalities:

(61) a) Add functionality, to register a command handler; and

(62) b) Route functionality, to map a routing key to a command handler.

(63) FIG. 12 represents a class Diagram for Priority Routing Table.

(64) In case of Command routing, any Route function return zero or one handler associated to a routing key that matches the call topic (see below for topic matching and routing key sorting).

(65) The term topic relates to a string formed in the lower layer constituted by the message routing system on the base of a message request delivered from a domain in the upper layer for executing a command, such a request including the name of the command and the corresponding type (or class or instance). Advantageously, the domain of the upper layer is not aware of the command or domain to which the request will be forwarded by the message routing system; it is the message routing system that, taking in input the command name and entity, construct a topic to be matched with the routing key in the routing table for retrieving the handler of the command (in the figures also indicated as method).

(66) In the case of the process of present invention, the Route function has the capability to return the handler associated to the first routing key matching the call topic.

(67) The concept of matching a topic with a routing key can be implemented in different ways based on the underlying technologies. For sake of simplicity, the following example makes use of a string comparison with the use of a universal wildcard (#) but other implementations can be used, considering the actual tool implementing the message routing system. For instance, commercial software widely adopted, such as *RabbitMQ*, may be used to this purpose.

(68) Regarding the implementations of topic/routing key matching, the following is noted.

(69) The need of matching topics to routing key called for by the process of the invention can be implemented in any way satisfying the requirement to test if a given topic starts with a given routing key. For instance, topic a# will match any string starting with a. Besides, different implementations may be used, depending on the underlying technologies, also based on different constraint.

(70) Also the concept of sorting topics according to length can be implemented in different ways based on the underlying technologies. For sake of simplicity, the example given below makes use of a string length sorting, but other measures can be used.

(71) Regarding the implementations of routing key sorting, the following is noted.

(72) The need of sorting routing key called for by the command of the present invention can be implemented in any way satisfying the requirement to test if a given routing key is deeper than another routing key. For instance, routing key a.b.c, consisting in three parts, is deeper than routing keys consisting of fewer parts. Another simple way of implementing depth is length comparison, irrespective of internal structure.

(73) Regarding the implementations of routing the first routing key matching the topic, the following is noted.

(74) The algorithm to support the sorted fetch in the Route function is based on the use of a sorted dictionary. The idea of sorting inherently routing keys to obtain a quicker retrieval at runtime is trivial in the prior art but not necessary. Better ad hoc algorithms might be used, if supported by an embedding technology.

(75) The implementation code of the PriorityRoutingTable might be, for instance, in the form:

(76) TABLE-US-00001 public void Add(MethodHandler methodHandler) { string topic = methodHandler.GetMethodType( ).Name + Lineage(methodHandler.GetClass( )); routingTable.Add(topic, methodHandler); } public MethodHandler Route(Type entityType, Type methodCallType) { string routingKey = methodCallType.Name + Lineage(entityType); KeyValuePair<string, MethodHandler> routingPair = routingTable.First(h => Accepts(h.Key, routingKey)); return routingPair.Value; }

(77) FIG. 13 schematically represents the flow Charts for Priority Routing Table.

(78) FIG. 14 is an exemplification of Sequence Diagrams for Priority Routing Table Add and FIG. 15 is an Exemplification of Sequence Diagrams for Priority Routing Table Route.

(79) In details, with reference to FIGS. 8 and 16 (this last being a miniature of FIG. 8), different cases apply.

(80) In the case of domains 8 and 10 of FIG. 7: Command handler will be registered with a topic of the type <MethodName>.<EntityLineage>.# (where # is a wildcard for zero or more characters), such as FreezeBOP.BOP.# or StartTask.Task.#, since BOP and Task are underived entities.

(81) Command calls will be submitted to the message routing system with a routing key of the type <MethodName>.<EntityLineage>. and <MethodName>.<InstanceLineage>., such as FreezeBOP.BOP. or StartTask.Task., since BOP and Task are underived entities.

(82) The message routing system will activate the command handler having the most derived topic (i.e. lexicographically longest) matching (i.e. lexicographically starting with) the routing key submitted, for example StartTask.Task.# matches StartTask.Task..

(83) In the case of extensions of entities of domains 9 and 11: Same behaviors can be exemplified by topics FreezeBOP.BOP.BOPExt.# or StartTask.Task.ToolTask.#, since BOPExt (in domain 9) and ToolTask (in domain 11) are entities derived respectively from BOP and Task.

(84) Same behavior with routing keys such as FreezeBOP.BOP.BOPExt. when call is performed on BOPExt or StartTask.Task.ToolTask. when call is performed on ToolTask, since BOPExt (in domain 9) and ToolTask (in domain 11) are entities derived respectively from BOP and Task. Same behavior with routing keys such as FreezeBOP.BOP. when call is performed on BOP or StartTask.Task. when call is performed on Task.

(85) Same behavior with routing keys such as FreezeBOP.BOP.BOPExt. when call is performed on a BOPExt variable or StartTask.Task.ToolTask. when call is performed on a ToolTask variable. Same behavior with routing keys such as FreezeBOP.BOP. when call is performed on a BOP variable or StartTask.Task. when call is performed based on a Task variable.

(86) The message routing system will activate the command handler having the most derived topic (i.e. lexicographically longest) matching (i.e. lexicographically starting with) the routing key submitted, for example StartTask.Task.ToolTask.# matches StartTask.Task.ToolTask. before StartTask.Task.#.

(87) With reference to FIGS. 18 and 19, differences and advantages of the method of the present invention (FIG. 19) over a prior art method (FIG. 18) are presented, making reference to portions of code.

(88) In both figures a base entity task and an extended entity toolTask are represented.

(89) According to the prior art method, one command has only one command handler. Therefore, command activateTask is defined for the base entity task and a specialized (extended) command activateToolTask is defined for the extended entity ToolTack.

(90) The above commands according to the prior art method have trivial routing keys ActivateTask and ActivateToolTask. The routing keys relates to commands having different names (ActivateTask and ActivateToolTask).

(91) A call to these commands is implemented as follows: Platform. CallCommand(new ActivateTask(taskId)); and Platform. CallCommand(new ActivateToolTask(toolTaskId));

(92) The command handler for ActivateTask may be as follows:

(93) TABLE-US-00002 Declaration of Activate Task Handler (topic: Activate Task) [Handler(HandlerCategory.BasicMethod)] public partial class ActivateTaskHandlerShell { [HandlerEntryPoint] private ActivateTask.Response ActivateTaskHandler(ActivateTask command) { var task = Platform. GetEntity < ITask > (command.TaskId); task. Status = Activated; Platform.Submit(task); return new ActivateTask.Response( ); } }

(94) The command handler for ActivateToolTask is a code reduplication of the command handler for ActivateTask, with the specific code added (underlined below):

(95) Declaration of Activate Tool Task Handler (topic:

(96) TABLE-US-00003 ActivateToolTask) [Handler(HandlerCategory.BasicMethod)] public partial class ActivateToolTaskHandlerShell { [HandlerEntryPoint] private ActivateToolTask.Response ActivateToolTaskHandler(ActivateToolTask command) { a) var task = Platform.GetEntity<IToolTask>(command.TaskId); b) var tool=Platform.Automation.Read(task.Tool); c) tool.Activated=true; d) Platform.Automation.Write(tool); e) task. Status = Activated; f) Platform.Submit(task); g) return new ActivateToolTask.Response( ); } }

(97) To the contrary, according to the invention, one command may have two or more command handlers. Without changing the model (base and extended entities in FIG. 18), the new command handler is declared as linked to the ToolTask entity:

(98) The call must provide a way to infer the routing key (lineage string), providing one of the following:

(99) 1. Entity type

(100) 2. Id of an Entity

(101) E.g., with a wrapper decorating commands with an entity type:

(102) Platform. CallCommand(new CommandContext<ITask>(new ActivateTask(taskId)));

(103) Platform. CallCommand(new CommandContext<IToolTask>(new ActivateTask(toolTaskId)));

(104) The model remains the same end the code for the new entity does not need to define a new command. In this respect, ActivateToolTask is not defined, according to the method of the present invention.

(105) TABLE-US-00004 [Handler(HandlerCategory.BasicMethod)] public partial class ActivateToolTaskHandlerShell { [HandlerEntryPoint] private ActivateTask.Response ActivateToolTaskHandler(ActivateTask command) { a) var task = Platform.GetEntity<IToolTask>(command.TaskId); b) var tool=Platform.Automation.Read(task.Tool); c) tool.Activated=true; d) Platform.Automation.Write(tool); e) task. Status = Activated; f) Platform.Submit(task); g) return new ActivateTask.Response( ); } }

(106) Topics Change as Follows:

(107) Activate Task Command (routing key: ActivateTask.Task.#)

(108) Activate Task Handler (topic: ActivateTask.Task.)

(109) Activate Tool Task Handler (topic: ActivateTask.Task.ToolTask.)

(110) The routing policy will select the longest topic matching (i.e. starting with) the routing key.

(111) The topic of the command handler in prior art method is the name of the command (<MethodName>) while, according to the present invention, it further includes the lineage (<MethodName>.<Lineage>.).

(112) In the example given with FIG. 19, the MES lineage contextualized entity is the base entity Task, the command is ActivateTask, the lineage of the MES lineage contextualized entity is Task, and the step of contextualizing the command with the MES lineage contextualized entity is implemented by the wrapper decorating command CommandContext in the code

(113) Platform.CallCommand(new CommandContext<ITask>(new ActivateTask(taskId))).

(114) Still with reference to FIG. 19, the extended MES lineage contextualized entity is ToolTask and the extended entity contextualized command is the same command ActivateTask, wherein the step of contextualizing the extended command with the extended MES lineage contextualized entity is implemented by the wrapper decorating command CommandContext in the code

(115) Platform. CallCommand(new CommandContext<ITask>(new ActivateTask(taskId))).

(116) In the message routing system it is registered a first handler (ActivateTask.Task) of the command (ActivateTask), in association with the lineage of the MES lineage contextualized entity (Task), and a second handler (ActivateTask@Task.ToolTask) of the command (ActivateTask), in association with the lineage of the MES extended lineage contextualized entity (Task.ToolTask).

(117) The communication of a domain with another domain through the messaging routing system includes delivering from a domain a message on the messaging routing system including the name of the command (ActivateTask) and the MES lineage contextualized entity (ActivateTask@Task) or the extended MES lineage contextualized entity (ActivateTask@Task.ToolTask).

(118) The messaging routing system selects the first handler (ActivateTask@Task), for executing the functionality, or the second handler (ActivateTask@Task.ToolTask), for executing the extended functionality, based on a mapping between the lineage registered in the messaging routing system for the first and second handlers, and a lineage derived from said message in the messaging routing system.

(119) Here below the advantages of the process of the present invention are summarized.

(120) The process of the present invention allows to:

(121) a) address command calls in a way similar to that of Object Oriented Programming, although a not polymorphic paradigm is used to define commands and entities;

(122) b) extend existing entities with new properties;

(123) c) modeling according to the domain driven design;

(124) d) use a routing procedure integrated in the message routing system, capable to deliver to the correct procedure handler (i.e. command handler).

(125) e). It is possible to leverage the power, simplicity and elegance of contextualized commands in a modern architecture based on polymorphism and message routing system architecture, event when not polymorphic paradigm are used.

(126) This advantage is apparent with respect to a message routing system architecture not including contextualized commands.

(127) i) Simulated OOP Design:

(128) The software tool devised in the invention gives the possibility of designing architectures based on a message routing system with polymorphic features, so the software engineer is free to use common or simulated OOP patterns (for instance, Visitor pattern to implement multiple dispatch).

(129) i) Class Based Dependency Update:

(130) If some entity contextualized command are not overridden in a derived entity, the depending callers (e.g. FreezeProc Command) which make use of new instances will automatically, in any domain, start the new logic contained in the latter version by calling the old command call; dependent code behaviors adapts dynamically.

(131) i) Code Reuse:

(132) If the base code (e.g. based on behavior regarding the security constraints, common to the two versions) changes, the code will have to be modified in the base versions: the first call in derived command will usually be that of calling the base command. If Version 1 is not useful anymore, for instance in case of obsolescence, code will still be used in subsequence builds.

(133) i) Applicability of Liskov Substitution Principle (LSP):

(134) The behavior of calls will be transparent to the developers and analyst: new instances will trigger new behaviors (functionalities); old instances will trigger old behaviors. In case a behavior has not been overridden, calls will still trigger old behaviors. In case a behavior must not depend on runtime instances, calls will still be viable.

(135) i) Cyclomatic Low Complexity:

(136) Since all scenarios require the developer to adjust well identified sections of code, no interlocking between old and new logic is called for.

(137) FIG. 17 is a schematic representation of the core base domain overridden by two peripheral Domain Driven Design domains.

(138) Further benefits associated to the process of the present invention are:

(139) Ease to Find Skill:

(140) The possibility to leverage on typical OOP features makes easier to find software engineers proficient in the skill, with no need to train in specific design practices.

(141) Local impacts on development and deploy in case of changes:

(142) When a behavior changes, there is no need to look for and this can reduce the time to carry out changes and minimize the risk to introduce bugs in the software. It also eases the process of delivering to production environments, since fewer modules will have to be replaced with new versions.

(143) Code Reuse:

(144) Code reuse can reduce the risk to introduce regression bugs and makes software life cycle easier, resulting in better quality software.

(145) Backward Compatibility:

(146) Since old instances will automatically show old behavior, backward compatibility is assured with no change in the source code, granting software a longer life span.

(147) Stable and Minimal Software:

(148) Scenarios are stable after each step of software update (the creation of new classes, the creation of new property, the development of new commands, the use of the code), so each modification can be gradual and tested in smaller steps.

(149) The modifications needed are less and the number of classes does not increase exponentially. More compact and easy code is easier to maintain, reducing the risk of regression bugs.