scholarly journals EDSOA: An Event-Driven Service-Oriented Architecture Model For Enterprise Applications

Author(s):  
Karina Hauser ◽  
Helgi S. Sigurdsson ◽  
Katherine M. Chudoba

Enterprise Applications are difficult to implement and maintain because they require a monolith of code to incorporate required business processes. Service-oriented architecture is one solution, but challenges of dependency and software complexity remain. We propose Event-Driven Service-Oriented Architecture, which combines the benefits of component-based software development, event-driven architecture, and SOA.

Author(s):  
Olga Levina ◽  
Vladimir Stantchev

E-Business research and practice can be situated on following multiple levels: applications, technological issues, support and implementation (Ngai and Wat 2002). Here we consider technological components for realizing business processes and discuss their foundation architecture for technological enabling. The article provides an introduction to the terms, techniques and realization issues for eventdriven and service-oriented architectures. We begin with a definition of terms and propose a reference architecture for an event-driven service-oriented architecture (EDSOA). Possible applications in the area of E-Business and solution guidelines are considered in the second part of the article. Service-oriented Architectures (SOA) have gained momentum since their introduction in the last years. Seen as an approach to integrate heterogeneous applications within an enterprise architecture they are also used to design flexible and adaptable business processes. An SOA is designed as a distributed system architecture providing a good integration possibility of already existing application systems. Furthermore, SOA is mostly suitable for complex and large system landscapes.


Author(s):  
Simon Polovina ◽  
Simon Andrews

As 80-85% of all corporate information remains unstructured, outside of the processing scope of enterprise systems, many enterprises rely on Information Systems that cause them to risk transactions that are based on lack of information (errors of omission) or misleading information (errors of commission). To address this concern, the fundamental business concept of monetary transactions is extended to include qualitative business concepts. A Transaction Concept (TC) is accordingly identified that provides a structure for these unstructured but vital aspects of business transactions. Based on REA (Resources, Events, Agents) and modelled using Conceptual Graphs (CGs) and Formal Concept Analysis (FCA), the TC provides businesses with a more balanced view of the transactions they engage in and a means of discovering new transactions that they might have otherwise missed. A simple example is provided that illustrates this integration and reveals a key missing element. This example is supported by reference to a wide range of case studies and application areas that demonstrate the added value of the TC. The TC is then advanced into a Transaction-Oriented Architecture (TOA). The TOA provides the framework by which an enterprise’s business processes are orchestrated according to the TC. TOA thus brings Service-Oriented Architecture (SOA) and the productivity of enterprise applications to the height of the real, transactional world that enterprises actually operate in.


2011 ◽  
pp. 132-155 ◽  
Author(s):  
Marten van Sinderen ◽  
João Paulo Andrade Almeida ◽  
Luís Ferreira Pires ◽  
Dick Quartel

This chapter aims at characterizing the concepts that underlie a model-driven service-oriented approach to the design of enterprise applications. Enterprise applications are subject to continuous change and adaptation since they are meant to support the dynamic arrangement of the business processes of an enterprise. Service-oriented computing (SOC) promises to deliver the methods and technologies to facilitate the development and maintenance of enterprise applications. The model-driven architecture (MDA), fostered by the Object Management Group (OMG), is increasingly gaining support as an approach to manage system and software complexity in distributed-application design. Service-oriented computing and the MDA have some common goals; namely, they both strive to facilitate the development and maintenance of distributed enterprise applications, although they achieve these goals in different ways. This chapter discusses a combination of these approaches and discusses the benefits of this combination.


2013 ◽  
pp. 299-313
Author(s):  
Simon Polovina ◽  
Simon Andrews

As 80-85% of all corporate information remains unstructured, outside of the processing scope of enterprise systems, many enterprises rely on Information Systems that cause them to risk transactions that are based on lack of information (errors of omission) or misleading information (errors of commission). To address this concern, the fundamental business concept of monetary transactions is extended to include qualitative business concepts. A Transaction Concept (TC) is accordingly identified that provides a structure for these unstructured but vital aspects of business transactions. Based on REA (Resources, Events, Agents) and modelled using Conceptual Graphs (CGs) and Formal Concept Analysis (FCA), the TC provides businesses with a more balanced view of the transactions they engage in and a means of discovering new transactions that they might have otherwise missed. A simple example is provided that illustrates this integration and reveals a key missing element. This example is supported by reference to a wide range of case studies and application areas that demonstrate the added value of the TC. The TC is then advanced into a Transaction-Oriented Architecture (TOA). The TOA provides the framework by which an enterprise’s business processes are orchestrated according to the TC. TOA thus brings Service-Oriented Architecture (SOA) and the productivity of enterprise applications to the height of the real, transactional world that enterprises actually operate in.


Author(s):  
Jason Nichols ◽  
Andrew Chen

As e-commerce models and applications have been widely employed in today’s business environment, a new movement to so-called dynamic e-business has been urged to advance e-commerce applications to the next level: simplifying business interaction over the Web through effective and widely accepted messaging and data encapsulation standards (Chen, Chen, & Shao, 2003). Gisolfi (2001) defined dynamic e-business as the next generation of e-business focusing on the integration and infrastructure complexities by leveraging the benefits of Internet standards and common infrastructure to produce optimal efficiencies for intra- and inter-enterprise computing. Infrastructure for both inter- and intra-organizational computing has undergone a significant maturation process from centralized mainframe computing to early distributed client/server environments, and most recently taking on a service orientation (Roure, 2003). Service-oriented architecture (SOA) represents the framework for the latest generation of service-based computing where once proprietary and monolithic applications are broken down into components and exposed through open standards for use by both internal and external enterprise partners. The SOA paradigm is argued to include in its list of benefits a higher return on investment, increased software reuse, and the capability to support dynamic service assembly (Stevens, 2005). An increased return on investment is achieved through the componentization of application capabilities. The argument goes that the usefulness of a component (defined here as bounded by its functional capabilities to one distinct business domain) outlives the usefulness of an application (since applications are developed to support a subset of processes in a domain while a component is not constrained, by definition, to any particular process set). Within the SOA paradigm, the development of applications to support a set of business processes is replaced with the connecting of components from distinct business domains in order to address the computational needs of a particular process. It is clear, then, that SOA has a positive impact on software reuse as components are leveraged across many configurations to address the specific computational needs of many different processes. To this end, one can map the reusability of components in an SOA context to the third argued benefit—dynamic service assembly. Dynamic service assembly means that components are not developed with the complete set of application scenarios in mind. Instead, components are created to exemplify the information and computational contribution of a specific business domain. The choice of how these components are used later on is therefore not limited to assumptions of usage made at the development stage. Indeed, it is possible that the most valuable use for any given component may not exist at the time of component development. As business processes evolve dynamically over time and business needs for information and computational support change, a service orientation leveraging components that are developed in the absence of constraints for how they might be utilized allows for dynamic reconfiguration of services in order to adapt to changes in the business processes themselves. This ability to reconfigure increases reuse and extends the lifetime (from a value perspective) of the components that are developed. This, in turn, feeds back to an increased return on the investment in software development which is typically the primary motivation for buy-in to the SOA paradigm. Similar to the shift from a mainframe to a client/server architecture (Malone & Smith, 1988), however, the shift to a service-oriented architecture requires consideration of costs associated with coordinating activities in this new environment. Management of these coordination costs will be necessary in order to preserve the purported increases in return on investment. Put simply, if the return on investments in software development increases but the costs associated with leveraging the developed information technology artifacts for business value also increases, then it is possible that the value created will be diminished or even overrun by the operational expense of coordinating use. In order to ensure that this is not the case, this article leverages a coordination theory approach to first understand the impact that a shift to service-oriented architecture will have on the cost of coordinating activity both within and across the firm, and second to make recommendations for how these coordination costs can be addressed to preserve the return on investment from a shift to service-oriented architecture.


Author(s):  
Ade Hodijah

The Service Engineering (SE) is understood as a framework to create innovative services in application development of information technology approach to Service Oriented Architecture (SOA). Implementing SOA is required methodology to identify services that can be used again in the application and organization of a company. in this research, software development model used is object-oriented methodologies, SOA itself is a collection consisting of tools, technologies, frameworks, and best practices that facilitate the implementation of a service quickly. in a study this uses the tools of Business Process Management System (BPMS) to support the implementation of service-oriented software. the purpose of this study is to produce a model of activities and artifacts of the application software development models of the SE with a case study Rate Loans. Validation to the design of the model is done through testing of the software produced. The results showed that the application of the SE in the development of service-oriented software can use the object-oriented methodology by providing additional value-added analysis and redesign of business processes to be implemented on a BPMS. BPMS usage of the application of the SE on the SOA has the advantage of visualization in the management of business processes.


Author(s):  
Raghav Goel and Dr. Bhoomi Gupta

Are you a software engineer/developer/coder or maybe even a tech enthusiast who is thinking of agility, parallel development and reducing cost. In the early twentieth century, we witnessed the rise of Service Oriented Architecture (SOA), which is a software architecture pattern that allows us to construct large-scale enterprise applications that require us to integrate multiple services, each of which is made over different platforms and languages through a common communication mechanism, where we write code and multiple services talk to each other’s for a business use case, but sometimes we end up with one big monolithic code base whose maintenance becomes difficult. Nowadays clients are using cloud and paying for on-demand services without effectively utilizing resources. These problems invite micro-services. In this paper, I am going to discuss how one should use scale application in a production environment and local machine


Author(s):  
Vinay Raj ◽  
Ravichandra Sadam

Service oriented architecture (SOA) has been widely used in the design of enterprise applications over the last two decades. Though SOA has become popular in the integration of multiple applications using the enterprise service bus, there are few challenges related to delivery, deployment, governance, and interoperability of services. To overcome the design and maintenance challenges in SOA, a new architecture of microservices has emerged with loose coupling, independent deployment, and scalability as its key features. With the advent of microservices, software architects have started to migrate legacy systems to microservice architecture. However, many challenges arise during the migration of SOA to microservices, including the decomposition of SOA to microservice, the testing of microservices designed using different programming languages, and the monitoring the microservices. In this paper, we aim to provide patterns for the most recurring problems highlighted in the literature i.e, the decomposition of SOA services, the size of each microservice, and the detection of anomalies in microservices. The suggested patterns are combined with our experience in the migration of SOA-based applications to the microservices architecture, and we have also used these patterns in the migration of other SOA applications. We evaluated these patterns with the help of a standard web-based application.


Author(s):  
Tony Clark ◽  
Balbir S. Barn ◽  
Vinay Kulkarni

Component-based approaches generalize basic object-oriented implementations by allowing large collections of objects to be grouped together and externalized in terms of public interfaces. A typical component-based system will include a large number of interacting components. Service-Oriented Architecture (SOA) organizes a system in terms of components that communicate via services. Components publish services that they implement as business processes. Consequently, a change to a single component can have a ripple effect on the service-driven system. Component reconfiguration is motivated by the need to evolve the component architecture and can take a number of forms. The authors define a dynamic architecture as one that supports changing the behavior and topology of existing components without stopping, updating, and redeploying the system. This chapter addresses the problem of dynamic reconfiguration of component-based architectures. It proposes a reification approach that represents key features of a language in data, so that a system can reason and dynamically modify aspects of it. The approach is described in terms of a new language called µLEAP and validated by implementing a simple case study.


Sign in / Sign up

Export Citation Format

Share Document