Adaptive SOA Stack-based Business Process Monitoring Platform

Executable business processes that formally describe company activities are well placed in the SOA environment as they allow for declarative organization of high-level system logic.However, for both technical and non-technical users, to fully benet from that element of abstractionappropriate business process monitoring systems are required and existing solutions remain unsatisfactory.The paper discusses the problem of business process monitoring in the context of the service orientation paradigm in order to propose an architectural solution and provide implementation of a system for business process monitoring that alleviates the shortcomings of the existing solutions.Various platforms are investigated to obtain a broader view of the monitoring problem and to gather functional and non-functional requirements. These requirements constitute input forthe further analysis and the system design. The monitoring software is then implemented and evaluated according to the specied criteria.An extensible business process monitoring system was designed and built on top of OSGiMM - a dynamic, event-driven, congurable communications layer that provides real-time monitoring capabilities for various types of resources. The system was tested against the stated functional requirements and its implementation provides a starting point for the further work.It is concluded that providing a uniform business process monitoring solution that satises a wide range of users and business process platform vendors is a dicult endeavor. It is furthermore reasoned that only an extensible, open-source, monitoring platform built on top of a scalablecommunication core has a chance to address all the stated and future requirements

The Value Proposition of Service-Oriented Architecture

The author of this thesis evaluates Service-Oriented Architecture (SOA) design and implementation strategies. The purpose is to provide the reader with the definition of Service-Oriented Architecture. This report discusses: (1) The definition of Service-Oriented Architecture, (2) The problems solved by Service-Oriented Architecture, (3) Application of design principles to achieve Service-Oriented Architecture. As a result of this investigation, Service-Oriented Architecture is a design style that is fundamentally about sharing and reuse of functionality across diverse applications, so that organizations can quickly adapt to changing business requirements while increasing IT asset reuse and minimizing integration and development costs

Service-Oriented Process Models in Telecommunication Business

The thesis concentrates on to evaluate challenges in the business process management and the need for Service-oriented process models in telecommunication business to alleviate the integration work efforts and to reduce total costs of ownership. The business aspect concentrates on operations and business support systems which are tailored for communication service providers. Business processes should be designed in conformance with TeleManagement Forum's integrated business architecture framework. The thesis rationalizes the need to transform organizations and their way of working from vertical silos to horizontal layers and to understand transformational efforts which are needed to adopt a new strategy. Furthermore, the thesis introduces service characterizations and goes deeper into technical requirements that a service compliant middleware system needs to support. At the end of the thesis Nokia Siemens Networks proprietary approach – Process Automation Enabling Suite is introduced, and finally the thesis performs two case studies. The first one is Nokia Siemens Networks proprietary survey which highlights the importance of customer experience management and the second one is an overall research study whose results have been derived from other public surveys covering application integration efforts

When Is an Enterprise Service Bus (Esb) the Right Choice for an Integrated Technology Solution?

The Enterprise Service Bus (ESB) is an important systems integration technology often closely associated with Service Oriented Architecture (SOA). Some maintain that an ESB should not be used apart from SOA. Others see the ESB simply as the next generation of middleware, incorporating the best of its predecessors, Enterprise Application Integration (EAI) and Message Oriented Middleware (MOM), and a candidate for any integration requirement. Is the ESB a one-size-fits-all solution to be trusted for any integration requirement, or must its use be carefully considered with proper due diligence based on application complexity and/or the presence or absence of a defined SOA? This thesis probes these questions in an analysis of a world-wide survey of 230 industry SOA and middleware professionals conducted via the LinkedIn Professional Network during a six week period in November and December of 2010. In addition, the thesis applies a review of the survey results and current SOA and ESB literature to an architectural decision being made within the Systems Engineering and Application Development (SEAD) Practicum in the Master of Science program in Computer Information Systems at Regis University in Denver, which provides support for the University\u27s Academic Research Network (ARN). An ESB has been proposed as a new architectural component for the ARN infrastructure and this paper reviews the merit of this proposal. This thesis employs an interpretivist epistemology, understanding that there may be more than one acceptable answer to the question, When is an Enterprise Service Bus an appropriate component of an integrated technology solution

Requirements of the SALTY project

This document is the first external deliverable of the SALTY project (Self-Adaptive very Large disTributed sYstems), funded by the ANR under contract ANR-09-SEGI-012. It is the result of task 1.1 of the Work Package (WP) 1 : Requirements and Architecture. Its objective is to identify and collect requirements from use cases that are going to be developed in WP 4 (Use cases and Validation). Based on the study and classification of the use cases, requirements against the envisaged framework are then determined and organized in features. These features will aim at guide and control the advances in all work packages of the project. As a start, features are classified, briefly described and related scenarios in the defined use cases are pinpointed. In the following tasks and deliverables, these features will facilitate design by assigning priorities to them and defining success criteria at a finer grain as the project progresses. This report, as the first external document, has no dependency to any other external documents and serves as a reference to future external documents. As it has been built from the use cases studies that have been synthesized in two internal documents of the project, extracts from the two documents are made available as appendices (cf. appen- dices B and C)