{'fraction_non_alphanumeric': 0.024875355170750013, 'fraction_numerical': 0.0023052592076341608, 'mean_word_length': 5.228380634390651, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
An Adopted Business Model Driven Framework Based Analysis Over SOA

: Several factors may force enterprises to modify their business processes: they are threatened by competition; they need to develop new process solutions to fulfill customer needs; they have to react to organizational change; and more. In order to efficiently change business processes, reference models as sources of to-be business processes that are to bring about economic improvements can be used. While in the past the application of reference process models would merely provide a new process model without addressing the necessary efforts of changing the technical solutions beneath it, the concept of service-oriented architecture (SOA) may significantly reduce these efforts by aligning services to business activities. The presumed ease of readily deployable business processes will then strongly promote the increased use of reference process models in business process optimization. In our approach, we apply the process mining technology to the event logs to discover the scenarios, each of which mainly consists of task originators, sub-process (ordering of service invocations) and business objects. Based on composition of these scenarios, the enterprise is able to redesign the process models and combine closely the business process with the services provided by different application systems in SOA. When new business requirements emerge, solution designers can devise a flexibly composite process that makes the best use of existing scenarios and glue the scenarios together with least augmentation or modification.


Introduction
Business process management (BPM), as the most representative information system technology to improve operational business processes, has a broader scope than workflow management (WFM) which is from process automation and process analysis to operations management and the organization of work [1]. The notion of business process model plays a significant part in business process management, which could be used to configure information systems, analyze, understand, and improve the process it describes. In fact, enterprises often are confronted with unprecedented changes in their business environment which cause the previous process models not applicable. Therefore, it is important to refine the process models through continuously monitoring processes.
According to [1], a plethora of notations exists to model operational business processes (e.g., Petri nets, BPMN, UML, and EPCs). These notations have in common that processes are described in terms of activities. However, due to the rising complexity of business as well as enterprise information systems which adopt SOA (Service-Oriented Architecture), the difficulty of comprehensively analyze and understand the business process models is ascending simultaneously, e.g., complicated process structure tends to confuse the analysts, many performers involved entangle the security control, etc.
While aforementioned modeling notations are without considering the other relevant factors, the analysts could not fully interpret the process. Moreover, the process model may also describe temporal properties, specify the creation and use of data, for example, to model decisions, and stipulate the way that resources interact with the process (e.g., roles, allocation rules, and priorities). So a mountain of researches have been conducted on the process modeling to enrich the process model, the best known approach is multi-view modeling which allows the developers describe a system from multiple points of view [2]. Nonetheless, it's opaque for most technicians to understand and analyze the business process depending on combining the different perspectives. Scenarios provide a commonly used means to communicate and characterize uncertainty in many decision support fields, says analyzing the requirements and designing a business process [3]. Reference [4] proposes a scenario-driven approach that is more intelligible to business process development which provides a simple method for business process modeling and captures the requirements as scenarios. Yet the scenario-based approach presented in [4] simply pays much attention on describing the scenarios given as UML sequence diagrams without considering process model improvement for adapting to changing circumstances.
In order to overcome the defects of those approaches above, this paper provides some points of views on the scenariobased business process model. Unlike most methods starting from the experts modeling the process on the foundation of their experiences, we choose to model the process based on the scenarios discovered from the real cases (i.e., process instances) using process mining, because during the enterprise development processes may have varied from previous models due to the business transformation. Furthermore, the scenarios from the real cases are more precise and helpful for analyzing the present processes as well as configuring the BPM systems. In this paper, we primarily consider three elements of the scenario during the business process inside the enterprises: the roles, the tasks which are executed with service invocations and the business objects. In order to build an intelligible business process model, the modelers turn their attentions towards a detailed understanding of the enterprise's business processes, not only focus on the sequence of tasks, but also take into account the originators and business objects of tasks. Without loss of generality, we may substitute the "task" with the term "activity". Process mining is an enabling technology for discovering, monitoring, and improve real process by extracting knowledge from event logs, with which we can consider those important elements may affect the business process [5]. Several attempts have been made to apply process mining to recover the process model [5], derive the interaction patterns among the task performers [6] and diagnose the differences between the observed behaviors and the modeled behaviors [7]. Nowadays some researches intend to make use of this technology to investigate more about service behaviors during business process in the enterprise [8]. However, lion's share of process mining research focuses on the single perspective, such as control flow, organization structure and data flow, etc. This paper will exploit process mining to learn abundant information about business process and service orchestration by getting those perspectives cohering. In the context of SOA and today's various information systems, it's possible to record events related to activities inside services or interactions between services. Hence, we could apply process mining to the event logs which record a specific business process. Then we can partition the business process into several scenarios to combine the services with the specific business process across organizations and systems within the enterprise.

Motivation
In this paper, we take a broader perspective on the term "service", which is often considered as web service that is associated with a series of Internet standards. The key idea of service orientation is to subcontract work to specialized services in a loosely coupled fashion [9]. Under SOA-based information system architecture, those complex and changeful business processes would be supported well.
When implementing SOA to flexibly combine the services and business process atop the present IT infrastructure, not only should we think over combination of business processes and those services, but also consider carefully people, digital data and physical entities (e.g. paper documents), control flow involved in the business process. Thus this paper adopts the concept of scenarios to cover these elements referred above. The scenarios here consist of sub-process, a role and business objects. The business objects are abstracted from the digital and physical entities that are relevant to business processes, such as orders, reports and products, etc. their states could be characterized by a set of properties [10]. The role of task performer is not limited to typical roles (e.g., customer, clerk, and manager etc.), while system should be regarded as role as well if some tasks are executed automatically [11]. The sub-process determines the order of tasks, which could be triggered or accomplished by invoking services. According to these scenarios, the business process analysts are capable of taking these three important elements involved in the business process into account so they are able to improve the business process with scenarios and glue these scenarios together with least augmentation or modification on them. This could be showed as Figure 1. In order to discover the scenarios in the business process, we employ process mining to help us utilizing the event logs in the enterprise's information systems. As indicated above, process mining starts with the existence of event logs. These event logs usually contain data about cases (i.e., process instances) that have been executed in the organization, the times when the tasks were executed, the persons or systems that performed these tasks, and other kinds of data. Each event in such a log refers to an activity (i.e., a well-defined step in some process) and is related to a particular case. Event logs may store additional information about events. In fact, whenever possible, process mining techniques use supplementary information such as the performer (i.e., person, device, or software component) executing or initiating the activity, the time stamp of the event, and other data attributes (e.g., the size of an order).
Since event logs may contain a wealth of information relating to other perspectives such as the organizational perspective and the case perspective, we are capable of mining the relatively complete scenarios from the event logs. The organizational perspective focuses on information about resources hidden in the log, i.e., which performers (e.g., people, systems, roles, or departments) are involved and how are they related. The case perspective focuses on properties of cases which can be characterized by the values of the corresponding data elements. For example, if a case represents a replenishment order, it may be helpful to access the information about the supplier or the number of products ordered.

Main idea
Through discussions in section 2, we will describe the method for mining application scenarios in detail. The overview of this approach is showed by figure  ISSN

Pre-process event logs
Currently multiple kinds of information systems may exist in the enterprise, like classical workflow management systems (e.g. Staffware), ERP systems (e.g. SAP), case handling systems (e.g. FLOWer), PDM systems (Product Data Management, e.g. Windchill), CRM systems (e.g. Microsoft Dynamics CRM), middleware (e.g. IBM's WebSphere), etc. These systems all are able to provide detailed information about the activities that have been executed [12]. The framework of information management under SOA allows for the possibility that a business process instance can make use of services offered by those application systems when it's initialized until the end. This brings a quite challenge to understand and analysis the business process cause event data is typically scattered over different data sources and often quite some efforts are needed to collect the relevant data.
In the context of SOA within the enterprise, the activities that constitute the process could be considered as service invocation events and the events could be recorded by tapping of message exchanges [13] (e.g., SOAP messages) and picking down read and write actions [14]. As serviceoriented applications are generally deployed on centralized runtime execution environments, such as Microsoft Azure Services Platform and Google App Engine, adoption of such centralized runtime execution environments facilitates monitoring the execution of a great many services-oriented applications to obtain the execution logs. These event logs can be extracted from those service providers' service invocation histories during process operation and transformed to a standard format, such as MXML which is an XML-based format for representing and storing event log data. According to definition 1, each event is recorded with the time of triggering, the name of the service which triggers the event and the id of the execution instance and a performer who executes or initiates the activity.

a) Mining control flow
In this paper we introduce the Petri nets to demonstrate the control flow among the services. For each execution instance, we pay close attention to the execution flows; afterwards we further infer the control flow structures (e.g., sequential structure, parallel structure) by availing of process mining on these execution flows. Provided that the cases are representative and a sufficiently large subset of possible behaviors is observed in the log showed in Table 1, we can choose α algorithm [15] to discover the generalized process and deduce the Petri net below. Nevertheless, the choice of mining algorithm depends on realities of situation and business analysis requirement. Actually, the event logs could be with noise, incomplete behaviors, and complex routing constructs. For instance, to deal with noise, we could adopt heuristic mining algorithms [16] which take account of frequencies of events and sequences when constructing a process model. The basic idea is that infrequent paths should not be incorporated into the model since the noise is rare.

b) Mining classification of roles
In fact role is critical to determine the scenario and to control the services composition as well as the business objects. We identify two important responsibilities of role in the scenario of business process. One is to be the base of the generation of scenario. The other is to control the execution of business process, i.e. some activities can only be executed, some services can only be invoked and some business objects can be accessed by this role.
To mine the role there exits four types of metrics that can be used to establish relationships between these performers: (1) metrics based on (possible) causality, (2) metrics based on joint cases, (3) metrics based on joint activities, and (4) metrics based on special event types [6]. In most cases, people doing something similar have stronger relations than people doing something totally different. We could learn from the event logs information about how frequent the performers conduct specific activities. This can be showed by performer by activity matrix which simply keeps a record of how frequent each performer executes specific activities. The matrix is with rows Performer and columns Activity. An example may be derived from the log in Table 2 where , represents the times that performer i executes activity j.
There are so many ways to measure the "distance" between two performers, like Minkowski distance, Hamming distance and Pearson's correlation coefficient, thus enabling many metrics that we can infer the role of each performer.

c) Mining data flow
Data flow reveals what data are transmitted between activities. During the business process the data flow impacts the process structure of activities no less than the control flow and the role. Data flow which is generated from the interactions between the business objects would govern the choices in the process to explain why particular cases take a special path [7]. For example, an application form is rejected for its mistaken data item; if the form is accepted then the requester should get a notification message that sent automatically or manual work. How these decisions made can be considered as classification problem that a particular execution path is selected on the basis of the values assigned to the business objects' attributes. Therefore we can analyze the event logs to identify the possible data constraints, which usually take the form of the conditional branching. The Daikon system proposed in [17] is able to detect the relation between the variables and the values assigned and deduce the data constraints.
1) Inside the scenario: A scenario contains several activities that may be executed with service invocations. So the scenario's internal data flow is responsible for determining the particular execution path of activities, how the services be called, and so on. 2) Outside the scenario: in this paper we suggest that the business process is composed of several scenarios. Whilst creating or reengineering a business process, the developers are able to utilize these scenarios to simplify the work. The data flow among those scenarios influences the switching from one scenario to another so that the business analyst will understand the complex business process at a coarser level of granularity.

Conclusion and Future Work
In paper, we introduce an integrated method for scenario discovery using three perspectives of process mining to analyze and refine the business process models based on the scenarios mined. This approach starts from discovering the roles, the ordering of tasks (services) and the business objects employed to forming the scenarios, which should be more applicative in business process reengineering. The relations between those factors in the process are well defined. Then we cite an exemplary case to illustrate the procedure of scenario discovery. In the end we discuss the usability of scenario based improvement on the business process, including the scenario reconstruction and modification. The scenario-based process modeling for analysis and improvement of business process is highlighted by its flexible composition and overall comprehensibility for technical or non-technical people. Besides, this method takes advantage of process mining to discover scenarios which ensure the reliability of process models.
The approach in its current form leaves a few points for future development. First, how to capture fully the requirements according to the scenarios is worth pursuing further, as the research results from requirements engineering have shown that scenario-based analysis approach is an effective method to model users' behavior and capture system profile [19]. Second, the mining technology can be improved to obtain more accurate results, e.g., dealing with noise in logs, more appropriate classification of roles, etc. Third, the structure of scenarios forming a complete process could be so complex as well as the relations among them that needs in depth study.