This description relates to process models.
Modeling languages may be used as meta-languages to describe and execute underlying processes, such as business processes. For example, process modeling languages allow an enterprise to describe tasks of a process, and to automate performance of those tasks in a desired order to achieve a desired result. For instance, the enterprise may implement a number of business software applications, and process modeling may allow coordination of functionalities of these applications, including communications (e.g., messages) between the applications, to achieve a desired result. Further, such process modeling generally relies on language that is common to, and/or interoperable with, many types of software applications and/or development platforms. As a result, for example, process modeling may be used to provide integration of business applications (e.g., software services), both within and across enterprise organizations.
Thus, such modeling languages allow a flow of activities to be graphically captured and executed, thereby enabling resources responsible for the activities to be coordinated efficiently and effectively. The flow of work in a process is captured through routing (e.g., control flow) constructs, which allow the tasks in the process to be arranged into the required execution order through sequencing, choices (e.g., decision points allowing alternative branches), parallelism (e.g., tasks running in different branches which execute concurrently), iteration (e.g., looping in branches) and synchronization (e.g., the coming together of different branches).
Choreography modeling refers to a type of process modeling that is generally concerned with a coordination of a plurality of organizations, persons, groups, stakeholders, or other entities. Generally, each such entity may have its own area(s) of expertise and may have its own associated process models. A choreography model may thus serve as a global or over-arching process model, which provides a contract or framework within which the various entities may execute their own process models (also known as local process models or orchestration models), while having confidence that their partner entities will behave in an expected, predictable, and workable manner.
Since choreography models, by their nature, often deal with a large number of entities having complex types and sequences of interactions, it may be difficult to design and implement a choreography model. Even if a monolithic choreography model is successfully constructed, it may be overly complex for some participating entities to use in a desired or intended manner. Moreover, once wholly or partially implemented, it may be difficult to modify the monolithic choreography model, due, for example, to the interrelated nature of the entities and associated message interactions (e.g., modification of one portion of the choreography model may cause an unintended effect in another portion). Consequently, for these and other reasons, an ability of users to design, use, and benefit from choreography models may be limited.
According to one general aspect, a system may include a choreography manager configured to manage a choreography model governing interactions between at least two entities. The choreography manager may include a first choreography modeler configured to provide a first view of the choreography model, the first view including first constructs that are associated with a first sequence degree characterizing a degree to which a sequence of the interactions between the entities is provided, a second choreography modeler configured to provide a second view of the choreography model, the second view including second constructs that are associated with a second sequence degree characterizing the degree to which the sequence of the interactions between the entities is provided, and a choreography mapper configured to relate the first view to the second view, and configured to relate the first constructs to the second constructs.
According to another general aspect, a system may include a choreography manager configured to manage a choreography model governing interactions between at least two entities. The choreography manager may include a first choreography modeler configured to provide a first view of the choreography model, the first view including entity-based constructs representing at least one of the entities, a second choreography modeler configured to provide a second view of the choreography model, the second view including action-based constructs representing actions taken by at least one of the entities during execution of the choreography model, and a choreography mapper configured to relate the first view to the second view, and configured to relate the entity-based constructs to the action-based constructs.
According to another general aspect, a method may include determining one or more of a domain view and a role-based view of a choreography model governing interactions between at least two entities, determining one or more of a milestone view and a scenario view, relating one or more of the domain view and the role-based view to one or more of the milestone view and the scenario view, and providing the choreography model, based on the relating.
The details of one or more implementations are set forth in the accompanying drawings and the description below. Other features will be apparent from the description and drawings, and from the claims.
In the present description, examples of the choreography model 104 are primarily given in terms of interacting business partners (e.g., entities 106, 108 of
When the choreography model 104 is used in the specific example of business process modeling, the focus is generally on the collaboration between the partners (e.g., the entities 106, 108), rather than on detailed descriptions of individual processes of each partner. Specifically, such collaboration may include exchanges of messages or documents in a sequenced or orderly fashion (for example, a purchase order message must precede a shipment confirmation). Similarly, the entities 106, 108 may use the choreography model 104, for example, to make pre-arrangements regarding their interactions with one another (e.g., arrangements governing messages, message formats, or message types). The interactions may be captured and expressed as part of a series of tasks or actions, illustrated as actions 110 in the conceptualization of the choreography model 104 of
As referenced above, the entities 106, 108 may participate in the choreography model 104 using software services, e.g., applications having one or more specific functionalities that are exposed to other applications, often over a network (e.g., the Internet) by way of a service interface (where an operation and use of the interface may be known or determined, as needed). When such a service (and/or an interface of the service) is exposed/available over the World Wide Web (referred to herein as the WWW or the web), then the service may be known as a web service. For example, such services may provide virtually any functionality that may be provided by an application over a network, including, for instance, providing stock quotes, providing airline or other reservations, providing purchasing/invoicing functionalities, or providing some aspect of supply chain management or inventory control.
Generally speaking, the use of such services and service interactions to implement local process or orchestration models may be referred to as a service-oriented architecture (SOA), and processes that rely on services to realize process steps may themselves be deployed and accessed as services, which may be referred to as process-based service composition. Languages exist, such as, for example, the Business Process Execution Language (BPEL), that are designed to provide such compositions of services (e.g., web services), and thus provide a top-down, process-oriented approach to the SOA. Accordingly, BPEL or other such languages (such as, for example, the Web Services Flow Language (WSFL), the eXtensible language (XLANG), and/or the Business Process Modeling Language (BPML)), or modifications/extensions thereof, may be used.
In the specific setting of choreography modeling, languages using Unified Modeling Language (UML) activity diagrams and Business Process Modelling Notation (BPMN) may provide support for choreography modeling. Further, languages such as the Business Process Service Schema (BPSS) and Web-Services Choreography Description Language (WS-CDL) also may be used, and may provide support for developing, and ultimately deploying, the choreography model 104. Additionally, or alternatively, the choreography modeling language Let's Dance may be used to design the choreography model 104, particularly at early stages of development thereof, whereupon, for example, WS-CDL may be used as an implementation language for a model constructed using Let's Dance.
They system 100 of
Thus, in
For example, in
Conversely, then, the second choreography modeler 114 may be an “action-based” modeler, in which models or views are represented as including action-based constructs associated with actions performed by the entities 106, 108 (such as exchanging messages). Thus, for example, the second choreography modeler 114 may provide conventional interaction views, or may include a milestone model or view, in which major points of progress of the choreography model 104 are illustrated using milestone constructs, while omitting a layer of detail regarding interactions that may occur between the milestone constructs. Of course, the characterization of the first view as “entity-based” and of the second view as “action-based” should not imply that the entity-based view may not include some action-based constructs (and vice-versa).
As referenced above, many of the difficulties in designing and implementing the choreography model 104 relate to the fact that a final version of the choreography model 104 may be highly-ordered or extensively sequenced, as described, in order to capture the various inter-dependencies between the entities 106, 108 (and other entities, not shown in
Thus, in the example of
Thus, the first view 116 may be said to have a first sequence degree that is low relative to a second sequence degree of the second view 118. In this context, the term sequence degree does not refer just to a serial ordering of a plurality of actions or other constructs within the views 116, 118, but rather more generally refers to a degree or amount of virtually any ordering that is present in the views 116, 118. For example, the second view 118 may specify that the first entity 106 and the second entity 108 execute a plurality of message exchanges in parallel with one another (such as when the first entity 106 sends a plurality of availability requests for alternative items to the second entity 108, and receives responses in parallel, as well). Meanwhile, the first view 116 may capture or reference the same message exchange(s) simply to the level of specifying that the first entity 106 and the second entity are expected to exchange messages, or are expected to exchanges messages of a type related to requests for availability.
When the first view 116 is associated with the entity-based view of the first choreography modeler 112, the first sequence degree may be considered to effectively be zero, so that no express or implied ordering is provided. For example, if the first view 116 includes a role-based view in which roles of the entities 106, 108 are specified, then a plurality of communication channels between the roles may be defined, without specifying any order of messages sent over such channels (as described in more detail below, e.g., with respect to
Although the example of
A choreography mapper 120 may be provided to map or otherwise relate the views 116, 118 (and other views) to one another. For example, a particular entity (or entity-related construct) of the first view 116 may be associated with an instance of the second view 118. For example, a domain view as the first view 116 may include a particular domain that is associated with a milestone view as the second view 118. For example, for a delivery domain, there may be a milestone view including milestones for selecting a carrier and scheduling the delivery. Further examples and details of how the choreography mapper 120 may relate the views 116, 118 are provided herein.
For example, a consistency checker 122 may be used to ensure a desired level of consistency between the views 116, 118. Detailed examples for performing such consistency checks are provided herein (e.g., with respect to
The choreography mapper 120 also may include a choreography aggregator 124, which may be configured to aggregate or otherwise combine one or more of the views 116, 118 to obtain the choreography model 104 for execution thereof, while retaining the various views and relationships therebetween (e.g., for use by designers in understanding or modifying the choreography model 104). For example, in a case where both a milestone view and an interaction view are present, then the choreography aggregator 124 may be used to insert some or all of the interaction view within and between milestones of the milestone view.
Further, the choreography manager 102 may include a display generator 126 that is configured to receive an output of the first choreography modeler 112, the second choreography modeler 114, and the choreography mapper 120, and configured thereafter to display first constructs 128 and second constructs 130 of the first and second views 116, 118, respectively, on a display 132. For example, where the first view 116 includes a role-based view, then the first constructs 128 may be role-based constructs, such as block identifying each role of the entities 106, 108. Similarly, where the second view 118 includes a milestone view, then the second constructs 130 may be a designated shape associated with illustrating milestones.
The views 116, 118 may be provided in juxtaposition with one another on a single screen of the display 132 (perhaps with an illustration of the relationship between the views 116, 118), or may be selectable for individual viewing and modification. The display generator 126 may receive a selection of all or part of a view being displayed, and may determine from the choreography mapper 120 whether and how to display a corresponding or related portion of another view (e.g., may receive a selection of a domain of a domain view, and provide a corresponding milestone view in response).
The display generator 126 also may provide a consistency selector 134 and an aggregation activator 136. The consistency selector 134 and the aggregation activator 136 may be provided by simply providing one or more selectable icons for the display 132. For example, selecting the consistency selector 134 in one embodiment may automatically provide consistency checking for all available views, while in another example embodiment the consistency selector 134 may be used to perform more selective or specialized consistency checking (e.g., checking consistency between some sub-set of available views, or only checking consistency in a uni-directional manner between two specified views). Similar comments may apply to the aggregation activator 136, which may be used to perform all-inclusive aggregations using the choreography aggregator 124, or which may be used to perform incremental or selected aggregations.
The display 132 may be associated with a computing device 138 as either a local computing device or a remote computing device accessed over a network. The choreography manager 102 may thus be implemented as part of a process modeling suite, e.g., using an enterprise application server, that may include various other conventional functionalities that are not described herein in detail (e.g., orchestration engines and messaging infrastructures). One or more of the entities 106, 108 may be responsible for implementing the choreography manager 102, in collaboration with one another, so that the entities 106, 108 may create versions of the views 116, 118 that may need to be merged or synchronized with one another.
In general, it may be appreciated that entity-based views may be associated with lower sequence degrees than action-based views. Consequently, entity-based views may be associated with high-level or early stage development of the choreography model 104, where it is not necessary, and indeed may be disadvantageous, to provide detailed information regarding ordering of message interactions. Therefore, in the example of
Relationships may be determined between the entity-based view and the action-based view (206). For example, the choreography mapper 120 may be used to determine a relationship between one of the first constructs 128 (e.g., a domain construct for a domain view or a role-based construct for a role-based view) and the second view 118 (e.g., a milestone view or an interaction view, respectively, as described in more detail, below. Of course, the choreography mapper 120 may determine relationships between multiple entity-based views, or multiple action-based views, as well. As part of determining the relationships, consistency checking may be performed (206) between the various views.
The choreography model may then be provided, based on the relationships (210). For example, the choreography aggregator 124 may perform aggregation of the entity-based first view 116 and the action-based second view 118, in order to determine the choreography model 104, so that linked views therebetween may be provided (212), e.g., by the display generator 126.
As shown, operations of the flowchart 200 may continue in an iterative manner. For example, a new action-based view and/or entity-based view may be provided (or an existing view modified) even after consistency checking and/or aggregation have been performed. The nature of the iterative operations of the flowchart 200 is provided by the feedback loops of
Thus, with reference to
Domains views may be considered to be entity-based in the sense that portions of entities 106, 108 may be defined to be within one or more domains. For example, organizational artifacts or groups within the entity 106 (e.g., an enterprise or company) may be used to define domains, such as organizational units, business policies, or functional groups within an enterprise (e.g., a payroll processing group or human resources group). Of course, new domains may be defined with respect to one or more of the entities 106, 108, which may be useful to the choreography model 104, even if a corresponding group does not already exist in an organizational structure of the entities 106, 108. Further, a single domain may span two or more participating entities, e.g., where two entities share or coordinate actions within a particular domain.
Thus, in the example of
More detailed examples of domain views are provided below, but in general from
In practice, an enterprise project (e.g., a supermarket supply chain) may be assigned a set of domains (e.g. product merchandizing, delivery), such as the set of domains 302-306 of
A domain may (recursively) consist of sub-domains to allow for arbitrarily complex domains (as seen with respect to the domain delivery 306, and as seen in more detail in
Role-based views may thus provide the highest level of choreography viewpoint within a particular domain, as shown with respect to
Thus, as opposed to including only a single context in which collaborations between partner entities is illustrated using actual interactions therebetween, the role-based view 300b provides information regarding interaction relationships, rather than actual interactions. That is, as shown, the channel 312 may merely indicate that the roles 308, 310 may have some need (and some ability) to communicate with one another, without specifying exactly when, whether, or how such interactions may occur. For example, retailers and manufacturers may need to communicate, but in a role-based view, such communication may be characterized as the communication channel 312, without providing implementation details or mechanisms (e.g., message queues, ports, email boxes) that may need to be specified at a later stage of design.
Thus, as with the domain view 300a, the role-based view 300b provides an example of the first (entity-based) view 116, which may be suitable for relatively early stages of development and design of the choreography model 104. Also similarly to the domain view 300a, which includes domain constructs, by including the first constructs 128 as role-based constructs, the role-based view 300b allows for the removal of virtually any implication or representation of sequencing or ordering message interactions, and, consequently, (in the terminology of
Thus, in
In the examples described herein, role-based views include boxes representing the roles in question, connected by lines with holes where the holes represent the corresponding channel(s) between connected boxes (roles). The lines (channels) may be designated as a one-to-one interaction relationship (shown by the numeral “1”s in
A role may be aggregated from more than one role type, so that, for example, interactions may be related to the aggregated role, with a deferred selection of which of the constituent roles will actually be involved. In these examples, a designer or modeler may specify rules which are used as the basis for determining such a selection. For example, the role of consignee may be used to aggregate roles such as “distribution center” and “store,” so that interactions may occur with, or between, any of these roles. Somewhat similarly, a role may be specialized into more than role (e.g., a carrier may be a Land Carrier, Rail Carrier, Ocean Carrier or Air Carrier, where such sub-roles may carry the same interaction relationships as the super-role, as well as further interactions.
Similarly with domains, roles may be associated with modeled artifacts of organizations, such as organizational units, business policies, and responsible organizational actors. Channels may be associated with implementation-oriented configurations, such as, for example, BPEL partner links.
Considering the domain view 300a and the role-based view 300b, and as described in more detail below with respect to
In the example of
More specifically, the connector 319 may be referred to as a “precedes” or “precedence” or “strong precedes” connector, in which a first milestone (represented by the milestone construct 318) must complete execution before a second milestone (here, the milestone represented by the milestone construct 320) may begin execution. Meanwhile, the connector 326 may be known as an inhibitor, which, as referenced above, acts to prevent one milestone from being reached once another milestone is reached (e.g., in
Milestone analysis may be performed after, or in conjunction with, domains and roles have been identified and expressed. Typical lines of analysis for milestone-based models or views may involve a broad operational understanding of coordination, centered on major points of progress. For example, milestones involved in a functional area may be identified, along with their ordering dependencies. Aspects of collaboration between partners which relate to achieving milestones may be identified, and coordination of milestones may be structured to optimize efficiency.
In the examples provided herein, and as shown in
Analogously to domain views and role-based views, the milestone view 300c may be related to modeled artifacts of organization(s), such as, for example, detailed goals, objectives, or policy outcomes. Milestone views may be implemented in conjunction with implementation-oriented configurations/models, e.g., as specially-designated tasks/events. For example, such tasks/events may occur at major points of synchronization, and may be visible as such to users of the choreography model 104 and associated milestone view 300c.
Thus, such views may be referenced as scenario-based views, or in some cases, may simply be referred to as interaction-based views. Such views provide detailed interactions of the choreography model 104, in which interactions capture message exchanges between roles, as shown in the interaction 336. That is, as shown, an elementary interaction captures a message exchange between a role sending a message of a type and another role receiving a message of the type. The interaction may be considered atomic, and is modeled as a single construct (much like a task in a classical process modeling language). There are different elementary interactions that are defined in more detail in the language Let's Dance or other suitable language (with support from Business Process Modelling Notation (BPMN) or other design languages). For example, interactions may be defined as: normal, guarded, and repeated interactions (while, repeat, for each (sequential), and for each (concurrent)). Multi-cast interactions (e.g. a message sent to multiple receivers) may be modeled through repeated interactions. Such interaction patterns are defined fully in the context of the language Let's Dance, which is merely one example of a language for supporting interaction-based choreography models.
Choreography models may thus be portioned into individual, use-case focused models, e.g., scenario-based views in which each scenario contains a set of interactions. Then, as shown in
An elementary interaction within a scenario may have a name, an optional description and a type (e.g., basic, guarded, repeated, or composite). An elementary interaction generally has a sender, a receiver and a message to be exchanged. Guarded and repeated interactions have conditions attached to them, and execution depends on satisfaction of those conditions. Interactions have dependencies between them signifying allowable execution order. As discussed with milestone views, above, such dependencies may be characterized as (strong) precedence, weak precedence and inhibition.
For example, scenario-based views may be developed simultaneously as domain views. Milestone views may be developed before or after development of the scenario-based views, and, as shown in
Thus, in
One or more of a milestone view and a scenario-based view may be provided for the choreography model (504). For example, the milestone modeler 114a or the scenario-based modeler 114b may be used, respectively. As described above, such modelers may be considered examples of action-based modeler(s) 114, and may have a relatively high sequence degree characterizing a sequence of interactions of constructs (e.g., milestone constructs or scenario-based constructs) thereof.
As already described, an order of development of the various views may proceed in any desired order, or wholly or partially in parallel. Further, it should be apparent that not all of the available views are necessary for a given choreography model. For example, the milestone view may be omitted and the scenario-based view may simply include a plurality of interconnected scenarios/interactions, without intervening milestones. Similarly, the domain view may be omitted, and the role-based view may be the only example of an entity-based view that may be used in the design of a particular choreography model.
Relationships may be determined between the various views that are used in a given setting, e.g., between the milestone or scenario views and one or both of the domain view and the role-based view (506). For example, the choreography mapper 120 may be used to determine various relationships between the various views, as referenced above, and described in more detail, below.
In various examples, the domain view may be related to the role-based view (510), the domain view may be related to the milestone view (512), and the domain view may be related to the scenario-based view (514). Similarly, the milestone view may be related to the scenario-based view (516), the role-based view may be related to the scenario-based view (518). Examples of possible relationships between the various views are provided herein. For example, as referenced above, a domain construct of a domain view may have a one-to-one relationship with a milestone view, whereas a milestone or milestone view may be associated with a plurality of roles. As another example, scenarios may be related to milestones by splicing the scenarios between appropriate milestones.
In conjunction with, or after, the relating of the various views, consistency checking may be performed (520). For example, the consistency checker 122 may be configured to determine a global consistency of all views, perhaps in response to a selection of the consistency selector 134. In other examples, consistency checking may be more selective. For example, consistency checking may be performed between role-based and milestone views, or between role-based and scenario-based views, or between milestones and scenario-based views. Consistency may be checked bi-directionally (e.g., between each pair of views), or uni-directionally (e.g,. checking whether a second view is consistent with a first view, with regard for whether the first view is fully consistent with the second view). Further and more specific examples of consistency checking are provided below with respect to
The choreography model 104 may thus be provided based on the determined relationships (508). For example, the choreography aggregator 124 may be used to combine some or all of the various views, and the display generator 126 may be used to display the views in relation to one another on the display 132 of
As represented conceptually in
As shown in the example of the logistics domain 304, domains may have various sub-domains, illustrated here as one or more additional ellipses within a particular ellipse (or other domain construct). Further, as already referenced, overlapping or other contact between domain constructs (e.g., the various ellipses) may represent a connection or possible message exchange between the connected domains. For example, the domain 602 for collaborative forecasting product replenishment (from which an order may be produced) connects with the logistics domain 304 (governing shipments of goods). Similarly, the logistics domain 304 connects with payments domain 302 and exceptions domain 604.
Similarly to the example role-based view 300b of
Further in the example of
As already described, the views 600a, 600b do not imply or include an express or implied order of interactions. Rather, the views 600a, 600b provide a generally static view of the participants and how the participants may interact with one another over a lifetime of the choreography model 104. The views 600a, 600b may be presented in a visually convenient and useful form; e.g., a user may view the role-based view 600b simply by clicking on, or otherwise selecting, the delivery domain 306 from within the display 132 of
Further in
In the example of
In
In
As shown, the scenario 806 may include a plurality of interactions 808, 810, 812, 814, and 816, in which one role sends a message to another role. For example, in the interaction 808, as shown, the retailer 612 may send a message regarding a store/inventory report to a manufacturer 614 (e.g., over the channel 616 of
Although shown as blank, it may be appreciated that the scenario 802 may contain similar interactions. A designer may click on, or otherwise select, the scenario 802, in order to modify or add interactions therein.
Then, the corresponding role pair R1, R2 of the interaction may be selected, as well as the message type MT (904). In the example, the roles are retailer 612 and manufacturer 614. Although not illustrated in
Then, as an initialization, a roles-consistent flag may be set to false (908). If an interaction relationships exists in the role-based view (910), then it may be determined whether a role multiplicity (if any) between R1, R2 corresponds in the two views (912) (e.g., R1 and R2 should not have a one-to-one relationship if the interaction relationship is one-to-many). Finally, if the message type MT is supported in the channel (here, the channel 612) (914), then the roles-consistent flag may be set to true (918). Otherwise, as shown, if any of these conditions are not met, then an inconsistency may be designated (916), e.g., the roles-consistency flag may be kept at false.
It will be appreciated from the above description, and from
The flowchart 900 may be used to check whether each interaction in the interaction view or model is consistent with the role-based view. Conversely, it may also be determined that every interaction relationship (e.g., channel) of the role-based view has at least one corresponding interaction in the interaction-based view (e.g., a check may be run to determine whether there may be interaction relationships (channels) in the role-based view without a role pair from the interaction view marked with a role-consistent flag (as a result of the operations of
In summary, then, a scenario-based (or interaction-based) view may be consistent with a role-based view in so far as they both may be part of the same domain and the domain is in a synchronized state. Further, the roles of elementary interactions should have correspondence with roles which do communicate (i.e. they share the same channels). It should be noted that multiple interactions between the same role pair can pertain to one channel. Still further, the messages passed between interacting roles are type compatible and in the same direction as those allowed across those channels). Finally, as referenced above, multiplicity of interactions (repeated interactions) should correspond with role cardinality.
In
If the dependency is a precedence dependency (e.g., M1 must execute before M2 may execute), then the consistency checker 122 may check the interaction model to see whether a precedence path exists between M1 and M2 (1008). In other words, if M2 follows M1, then it may be sufficient for the sake of consistency to say that, within the interaction model, M1 and M2 have a direct or indirect precedence path (that is, between M1 and M2, either no interactions exist, or interaction which do exist are also in a precedence relationship). If so, then a consistency flag may be set to true (1012).
If there is no such precedence path between M1 and M2, e.g., if there is only a weak precedence path, then the consistency checker 122 may analyze the interactions to determine whether all interactions prior to M1 will be executed (1010). If so, then consistency may still exist, and the consistency flag may be set accordingly (1012). For example, if M1 is a predecessor to an interaction in a precedence or weak precedence relationship and there are no guarded (conditional) interactions or inhibited interactions targeting any preceding interactions of M1, then it may be deduced that there will be an interaction between M1 and M2, as predicted in the interaction-based model, so that consistency may be preserved. Otherwise, the milestones consistency flag may be set to false (1014).
If M1 and M2 are in a weak precedence relationship (1006), then the interaction model may be scanned to determine whether a precedence or weak precedence path exists therein between M1 and M2. If so, this is sufficient to establish consistency, and the flag may be set accordingly (1012); otherwise, the flag may be set to false.
Finally, for an inhibition relationship (1006), the interaction model may checked for an inhibited interaction between M1 and M2. That is, in the interaction model, two interactions should be present such that the first interaction follows M1 and the second interaction precedes M2, and the two interactions have an inhibition relationship between them, so that inhibition is consistently maintained in the interaction model as in the milestone view (1018). It should be noted in this regard that the first interaction should directly or indirectly precede M1 in a precedence relationship, or in a precedence or weak precedence relationship such that there will be no prior inhibitions of that interaction (e.g., via guarded interactions or interactions which cause inhibition). If so, then the flag mat be set to true (1012). Otherwise, as referenced above with respect to operation (1010), interactions between M1 and M2 may be checked to determine whether all interactions therebetween will be executed (1020). To maintain an inhibition relationship if not all of the interactions will be executed, then inhibition may be maintained and the flag set to true (1012). Otherwise, if all interactions will be executed between M1 and M2, then inhibition consistency is not maintained and the flag thereby set to false (1014).
Thus, the above description provides techniques by which choreography models may be developed using multi-staged and multi-viewpoint techniques. In so doing, and as referenced above, one viewpoint might inter-play with another viewpoint in the development of a choreography model. In the early stages of analysis in particular where the models being captured are fluid and subject to change, inter-play of the viewpoints may be highly advantageous.
For example, as referenced above, one-directional consistency checking may be useful. That is, consistency checking implies that the different models used need mutual consistency, so that concepts in one have correspondence with related concepts in the other, and vice-versa. However, when developing models, support for one directional consistency may be advantageous, because in an early or intermediate state of development may modelers already know that some of the models are still in flux, but nevertheless need checking against already well developed models. As an example, a milestone or role-based model may be used to check correctness of modeled interactions in a scenario, or in the whole interaction-based model. Uni-directional consistency allows consistency of modeled interactions to be checked, without requiring all interactions to correspond to the more coarse-grained models. The consistency checker 122 may then qualify the extent of consistency that has been established in the case that partial or one-directional consistency checking has been used
In the examples herein, and in other examples, the distinct views described here may nonetheless be seamlessly presented. For example, role-based views and milestone views may be presented in some implementations are being monolithic with respect to an associated domain. However, even with their coarse-grained detailed, these models will be quite large for real-scale domains. Therefore, it may be advantageous to view parts of these views in tandem with interaction-based models.
Thus, as an interaction-based model is viewed for one or more individual scenarios, then the corresponding part of the role-based or milestone based model could be viewed as well. Moreover, some views could mix different aspects together. For example, a set of scenarios could be viewed as both role-based and interaction-based viewpoints respectively, with the detailed interaction-based details expanded when a specific scenario is being analyzed. This allows coarse-grained surrounding details to be understood, while more detailed interactions are being viewed and captured. It should be noted that in this example, the milestone model is used to determine related scenarios, which in turn derives which parts of the role-based view should be displayed. Further, when viewing a role-based view, a designer may select a channel to determine which message types are associated therewith, and may also be given the option to view the scenario-based view from the role-based view. Moreover, in viewing the corresponding scenario view, e.g., in the display 132, the designer may be permitted to actually model the scenario view at that point (e.g., by constructing a particular interaction by selecting from the list of available messaging interactions detailed in the role-based view).
In further implementations, neighborhood viewing may be provided based on the target of viewing (e.g. milestones or scenarios). For example, and similar to the example just given, a role-based model may be viewed based on a scenario. By relationship to the underlying milestone dependencies, the related scenarios could be determined, and, accordingly, the role-based model view could be expanded. For example, in
In still further implementations, it may be observed that large numbers of scenarios may arise out of small or large variations of basic scenarios. For example, purchase orders may have a standard form, but may vary slightly when involving goods which are large, small, flammable, biodegradable, or otherwise associated with some small variation that may affect shipping. Consequently, the implementations described herein may be used to capture generic interaction structures, to allow later addition of more specialized parts. Sub-types of scenario models may be created by allowing generic interaction-based models to be inherited (e.g. purchase order processing), and adding further interactions. Then, by defining appropriate and well-defined boundaries, consistency checks may be applied to a generic scenario, but will be carried into the specialized scenario (e.g. small purchase order processing). In some example implementations, the following rule be preserved from the generic structure: “direct or indirect precedence or weak precedence path between milestone dependencies such that there are no interactions which will not be executed.” If any new interaction is added to the generic structure which violates this rule, it may be removed.
Implementations of the various techniques described herein may be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. Implementations may be implemented as a computer program product, i.e., a computer program tangibly embodied in an information carrier, e.g., in a machine-readable storage device or in a propagated signal, for execution by, or to control the operation of, data processing apparatus, e.g., a programmable processor, a computer, or multiple computers. A computer program, such as the computer program described above, can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program can be deployed to be executed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a communication network.
Methods may be performed by one or more programmable processors executing a computer program to perform functions by operating on input data and generating output. Methods also may be performed by, and an apparatus may be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit).
Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read-only memory or a random access memory or both. Elements of a computer may include at least one processor for executing instructions and one or more memory devices for storing instructions and data. Generally, a computer also may include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks. Information carriers suitable for embodying computer program instructions and data include all forms of non-volatile memory, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The processor and the memory may be supplemented by, or incorporated in special purpose logic circuitry.
Implementations may be implemented in a computing system that includes a back-end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front-end component, e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation, or any combination of such back-end, middleware, or front-end components. Components may be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network (LAN) and a wide area network (WAN), e.g., the Internet.
Thus, while certain features of the described implementations have been illustrated as described herein, many modifications, substitutions, changes and equivalents will now occur to those skilled in the art. It is, therefore, to be understood that the appended claims are intended to cover all such modifications and changes.