Modern edge-cloud systems face challenges in ef-ficiently scaling resources to handle dynamic and unpredictable workloads. Traditional scaling approaches typically rely on static thresholds and predefined rules, which are often inadequate for optimizing resource utilization and maintaining performance in distributed and dynamic environments. This inefficiency hin-ders the adaptability and performance required in edge-cloud infrastructures, which can only be achieved through the newly proposed in-place scaling. To address this problem, we propose the Multi-Agent Reinforcement Learning-based In-place Scaling Engine (MARLISE) that enables seamless, dynamic, reactive control with in-place resource scaling. We develop our solution using two Deep Reinforcement Learning algorithms: Deep Q-Network (DQN), and Proximal Policy Optimization (PPO). We analyze each version of the proposed MARLISE solution using dynamic workloads, demonstrating their ability to ensure low response times of microservices and scalability. Our results show that MARLISE- based approaches outperform heuristic method in managing resource elasticity while maintaining microservice response times and achieving higher resource efficiency.

Service Oriented Architecture (SOA) is an evolution of distributed computing and it is based on the concepts of interoperable services. To enable reliable and robust service oriented information systems, it is important to establish an effective fault handling. WS-BPEL 2.0 specification does not provide sophisticated and reusable support for handling faults and challenges process designers with many obstacles in the process implementation. We introduce a novel policy driven fault handling framework for BPEL by extending the WS-BPEL 2.0 specification. We propose to separate business process and fault handling logic with the aim to decrease code duplication, process complexity and overall process size. The proposed framework consists of a fault policy which includes the definition of BPEL fault handling logic. The fault policy defines fault handlers and fault handling recovery actions that can be used to design handling BPEL process faults. As a proof-of-concept, we have developed a prototype implementation of the proposed policy driven fault handling framework for BPEL and tested it on 117 real world BPEL scenarios. We have confirmed that the proposed solution decreases the code duplication, the process complexity and overall the process size. Even more, we successfully improved the reliability and readability of BPEL processes.

This paper analyses the influence of different tool types (visual or textual) on a developer's perception of efficiency during XML Schema development. We conducted a controlled experiment that focused on discovering which XML Schema development tool type enables better efficiency and also engenders a friendlier environment for developers while developing XML Schemas. The experiment was conducted with 240 participants and divided into two practical parts (visually developing an XML Schema and manually using a mark-up language intelligent textual editor). After the experiment, the participants' opinions were gathered via a web survey. In the survey, a technology acceptance model (TAM) was used as the basis for constructing the measurement items in order to answer the following questions: (1) which tool type is preferred and perceived as better, and (2) which variables influence the user's perceptions and decisions. In this study, we searched for an optimal way of building XML Schemas. The general tendency of most participants was towards a visual tool, suggesting that visual support is perceived as more useful, and can create better results with less effort.

Complex Event Processing (CEP) has so far been implemented in technology and vendor-specific manner. Introducing CEP concepts to the Service Oriented Architecture (SOA) provides an opportunity to enhance the capabilities of SOA. We define a model that supports the CEP usage in SOA where the actual pattern recognition can be done by any external CEP Engine. We define a new service type-a Complex Event Aware (CEA) service that automatically reacts to complex events specified in its interface. The proposed model includes a CEP Manager that provides centralized management of complex events and, through its pluggable adapters, communicates with CEA Services and CEP Engines. It includes a CEP Registry and a CEP Repository enabling versioning and reuse of complex event types, and a CEP Dispatcher providing publish/subscribe communication framework. We design a generic XML schema for abstract complex event type definition and propose new extensions for Service Component Architecture (SCA) and Web Services Description Language (WSDL) specifications, which enable definitions of complex event types and complex event sinks in the CEA Service interface. As a proof-of-concept, we develop a prototype implementation for the largest national telecommunication provider and in the real-world scenario show the advantages of the proposed model.

The current state of executable business process languages allows for and demands optimization of design practices and specifications. In this paper, we present the first empirical study that analyses Web Services Business Process Execution Language (WS-BPEL or BPEL) usage and characteristics of real world executable business processes. We have analysed 1,145 BPEL processes by measuring activity usage and process complexity. In addition, we investigated the occurrence of activity usage patterns. The results revealed that the usage frequency of BPEL activities varies and that some activities have a strong co-occurrence. BPEL activities often appear in activity patterns that are repeated in multiple processes. Furthermore, the current process complexity metrics have proved to be inadequate for measuring BPEL process complexity. The empirical results provide fundamental knowledge on how BPEL specification and process design practices can be improved. We propose BPEL design guidelines and BPEL language improvements for the design of more understandable and less complex processes. The results are of interest to business process language designers, business process tool developers, business process designers and developers, and software engineering researchers, and contribute to the general understanding of BPEL and service-oriented architecture.

Business process execution language (BPEL) does not provide a native support for defining data and metrics, required to perform business activity monitoring (BAM). Existing industry solutions are vendor-specific while platform-independent scientific approaches separate tightly coupled monitoring definitions from the core BPEL processes into external descriptors, thus increasing the complexity of the development, packaging and deployment processes. Furthermore, existing monitoring solutions reuse platform-specific audit trail events. This requires monitor model developers to be familiar with the details of the process implementation and the custom BPEL engine meta-model. To overcome these issues, this paper presents bpelx4bam — a new approach to defining monitoring data and metrics within BPEL processes, based on BPEL extensions. The bpelx4bam promotes these definitions into the first class citizens of the BPEL specification in order to unify and fully integrate BAM into the BPM lifecycle. It enables a cross-platform migration of BAM-enabled business processes, removes the need for separate models and specifications, eases development, packaging and deployment processes, aligns the separation of concerns with actual process roles and introduces BAM-specific and optimized events. Therefore, it presents a solid ground for a future specification or a standard in this area.

Version management of WS-BPEL (Business Process Execution Language, BPEL) processes in SOA is not supported in a consistent way. Therefore, in this paper we propose specific extensions for BPEL to support versioning of processes and partner links. We introduce new activities and extends existing activities, including partner links, invoke, receive, import, and on-message activities. We propose version-related extensions to variables and introduces version handlers. The proposed extensions represent a complete solution for process-level and scope-level versioning at development, deployment, and run-time.

Version management is an important aspect of SOA development, which has not been adequately addressed so far. In this article, we address version management of services and process in SOA. We propose extensions to WSDL. We address service-level and operation-level versioning, service endpoint mapping, and version sequencing. The proposed extensions represent a complete solution for service and process level versioning at development, deployment, and run-time.

Due to increasingly demanding requirements for business flexibility and agility, automation of end-to-end industrial processes has become an important topic. Business process execution needs to support automated tasks execution as well as human tasks. In this paper we show that for certain types of human tasks it is relevant to consider their further automation. We propose a service-oriented architectural framework for human task execution, which improves their execution by automating and semi-automating decision making based on ontologies and agent technology. The approach is generic and can be used for any type of industrial or industrial support business process. As a proof-of-concept we have developed a system providing the above-described support for human task intensive business processes in an electric power transmission company, which has shown considerable improvements in the efficiency of human tasks.

Abstract In this article we have undertaken a qualitative and quantitative comparison of common approaches used to develop distributed solutions in Java: RMI and Web services for regular unsecured communication, RMI‐SSL and WS‐Security for secure communication and authentication, and HTTP‐to‐port and HTTP‐to‐CGI/servlet tunnelling for RMI communication through firewalls and proxies. We have performed a functional comparison that helps with the selection of the most appropriate approach. We have also carried out a detailed performance analysis with the identification of major bottlenecks, identification of design and implementation guidelines for distributed applications, and specification of optimizations for distributed middleware. This article contributes to the understanding of different approaches for developing Java distributed applications, provides detailed performance analysis, presents design and implementation guidelines, and identifies the major performance overheads. Copyright © 2006 John Wiley & Sons, Ltd.

In this paper, we present some important aspects of software testing. We explain why software reliability is important, especially for medical software products. The automation of testing procedures is important in order to achieve the desired reliability level. For this purpose, intelligent systems can be used to identify potentially dangerous software modules. We present an evolutionary decision-tree approach to the identification of dangerous software modules in a real-world medical application.

The paper focuses on the performance analysis, comparison and optimization of the most important distributed object models for Java: RMI (Remote Method Invocation) and RMI-IIOP (Remote Method Invocation over Internet Inter-ORB Protocol). The paper presents the following contributions to the research on distributed object performance. First, a detailed performance analysis of both models is provided with the in-depth comparison. These results help to understand how the models perform. Second an overhead analysis and bottleneck identification is presented with an explanation of why there are differences in performance. Third optimization and the results for performance improved post-beta RMI-IIOP versions are presented. These show considerably better performance in all areas compared to the original beta release, with RMI-IIOP having equivalent or better performance to RMI in almost all cases.