ASOA in Cloud Computing

This thesis work has contributed to the Opensource community and the work includes both academic as well as Opensource research conducted within the contemporary industry as well. Almost all of the organizations do data gathering activities [46], which identifies the artifacts and the relationships of a system. It gathers data from system examination, document scanning, and experience captured. As per the contemporary Big Data and NoSQL world, it is noticed that the logic can remain the same as it was in legacy systems, however the message passing, or app to app communication, is the key to manage data for analytic reasons and needs intelligent novel designs of algorithms.

Development Process Methodologies and ASOA

ASOA [21] is a relatively newer introduction with Achievable SOA adaptation with the use of System Requirement Design (ASOA-SRD) methodology embedded within. It is an approach to design a SOA solution to represent, revise and develop software systems or services required by any organization as a stakeholder for Cloud deployments. It incorporates the elements of requirements into a finished software system in a deployable combination of applications with a single frame of reference. The fundamentals of the SRD are requirements of requesting stakeholders distributed in elements, once amalgamated in the phase of processing to produce a block of an application for deployment.

Several business processes and service design methodologies have been developed and introduced in the last decade or so. Lin et al. [48] and Korherr et al. [49] provided comparisons of these methodologies in several surveys. Several designers at different organizations used UML notations and few used some [50, 51, 52, 53] special notation approaches. Event-driven Process Chains (EPCs) [50] is another prominent approach for requirements modeling for business process designing purposes. This type of modeling represents the dynamic performance of activities associated to specific business process requirements by focusing on depicting control flow dependencies among several different process functionalities. There is a drawback using EPCs, and that is the extension of the user’s provided requirement information creates havoc, where EPCs already have stored static information, as there is no such support provided to deal with this information addendums.

Kim et al. [54] worked on conceptual modeling and Kramler et al. [55] have produced work on web service collaboration protocols for inter-organizational business processes. Due to the use of SOA and related methodologies web services and XML have gained significance alongside of JSON. The use of XML has brought to the design world of software engineering XML-based notations. This new set of notations is being utilized to implement business processes modeling designs development. As per the work done in [56, 57] Web Services (BPEL4WS) and as described in [58] Business Process Specification Schema (BPSS) are the most trendy languages in the area of business processing.

Object Management Group (OMG) [59] introduced a new approach in 2006, and called it Business Process Modeling Notation (BPMN). This approach introduced a single graphical modeling notation for all stakeholders involved in a requirement design. The research work done by Karhunen et al. [47] provides us the study of a framework for SOA, which creates a welldefined business case using UML and BPMN diagrams containing business processes and the business requirements.

Knowledge management captures the individual knowledge, organization, and understanding of past processes and provides a model to logically justify the artifacts. The information exploration part plays a pivotal role in program understanding; it uses the information structure generated by the knowledge management part and filters it according to specific required criteria. In this phase non-trivial program understanding of the system is acquired.

ASOA or Achievable SOA [17] is an approach that provides an efficient and cost effective methodology for organizations to achieve their required services fast and easy data gathering activities, and designers can design such applications using ASOA. This chapter puts light on the adaptable approaches, which can be adapted for software design of required services’ front-end applications. It is very important to know the application design methodologies, such as abstraction, modular application design, and information hiding used to understand the available software structure. This understanding can be utilized as the basis to develop wrappers for legacy systems to convert data into XML/JSON for the use of services design.

The abstraction used in creating software designed with structured programming in mind did not focus its consideration on maintainability or application reuse as a service for a long term basis. The focus was instead placed on the application at hand to resolve an issue for a certain timeframe.

ASOA introduced a new paradigm in this chapter for the SOA solutions; SRD or System Requirements Design methodology. The human mind can do chunking within seven plus or minus two things at one time. ASOA-SRD contains eight diagrammatic elements to draw a design with. Every ASOA is to begin with an “Initiation Marker” and completes with a “Service (Block)”. A service block is a simulation of a physical building block and can be reused for any other services’ combination project. A stakeholder can be a consumer, user, or member of SOAT (Service Oriented Architecture Team).

A service block is created by using different service requirement elements. It is analogous to a physical building block, which is usually prepared with a cement and water combination, where cement is made from lime, silica, alumina, iron oxide, and gypsum and it is a known fact that water is a combination of two elements Hydrogen and Oxygen. ASOA is a methodology that takes motivation from our physical environment.

An ASOA Designed Service at Work

Let us see a functional service as an example designed using ASOA methodology with an SRD diagram in the given figures. The design of an application is of an ABC-CPP consumer products merchant offering general merchandize such as tissue papers, soaps, shampoos etc., to sales partners. As the main products provider ABC-CPP has to manage sufficient inventory available for fast delivery to its sales partners. As the stock level of a certain merchandize falls below a certain quantity, our central provider has to ask the manufacturing partner to ship the required product for restocking purposes. This transaction among all stakeholders can be understood as B2B2C.

The solutions designed using SOA are disseminated and can be highly scalable. The ASOA approach is a novel methodology to design, develop, and deploy the service designed using available resources. These available resources can be legacy systems or distributed systems in use. ASOA has enormous potential to get pervasive recognition to achieve efficient and cost-effective services. ASOA provides added methodology to all core components of SOA and a desired service can be designed, developed, and deployed for either one organization or by several businesses altogether to join forces to expand the services provided to the consumers.

Another core component of SOA is the ESB or enterprise service bus. ESB is a fundamental base communications infrastructure that serves the messaging among services; these services can be both front-end and back-end. ASOA tends not to use ESB. The messages are processed in the processing phase and are communicated among services using pervasive communication links.

ASOA Solution’s Progress Monitoring

There are several contributing factors attached to a successful ASOA [75] [76] service solution. The most crucial factor is to establish an efficient ASOA service solution’s “Progress Monitoring System,” or PMS, at the time of service design. The Progress Monitoring System needs to be designed to document the service development achieved progress milestones. This system will not only enhance the probability of achieving the desired service but will also advance a qualitative collaborative environment for all stakeholders involved in as SOAT (SOA Team) with an intense concentration to get the service deployed in the estimated time efficiently. This Progress Monitoring System is getting predominantly significant, due to the advancement of both hardware and software technologies.

The objectives of an effective “Progress Monitoring System” (PMS) are to get the service requirements’ specifications prioritized (sequential outlining) with the scope of deliverables as desired service to enhance the benefits of users by being cost effective. PMS should have defined milestones using an enforced design methodology. The specified elements of requirement specifications should be considered as identified jobs to be completed within some estimated time frames. PMS should also have an acceptance criterion agreed upon by all stakeholders as a milestone to achieve for testing the Beta version of the service.

Table des matières

1 Introduction 
1.1 Motivation
1.2 Problem Statement
1.3 Existing Approaches
1.4 Limitations of Existing Approaches
1.5 Goals
1.6 Proposition
1.7 Contributions
1.8 Organization
2 State of the Art Work 
2.1 Background
2.2 Related work on SOA
2.3 Challenges of SOA
2.4 Cloud Computing
2.4.1 Cloud Computing Providers
2.4.2 Software as a Service in Cloud
2.4.3 Related Work to SaaS
2.5 Related work on Security Access Controls
2.6 Openaource Security
2.7 Business Process Reengineering (BPR)
2.8 Background of BPR
2.9 Factors of BPR
2.9.1 Success Factors
2.9.2 Failure Factors
2.9.3 Benefits of BPR
2.10 Business System Reengineering
2.10.1 The Goals of System Reengineering
2.10.2 System Reengineering Approaches
2.11 Using Data Flow to Explain System Reengineering: A Case Study
2.12 Summary
3 ASOA in Cloud Computing 
3.1 Development Process Methodologies and ASOA
3.2 An ASOA Designed Service at Work
3.3 ASOA Solution’s Progress Monitoring
3.4 ASOA and Critical Factors
3.5 ASOA for Cloud Computing
3.6 Summary
4 Cloud Computing Secured Gateway 
4.1 Cloud Server Side Gateway Algorithm
4.1.1. Database Notation (SQL comparison)
4.1.2. Notations
4.2 Mathematical Description: Cloud Server
4.3 Client Service Linear Analysis
4.4 Mathematical Description with Linear Analysis: Cloud Client
4.5 Cloud Secured Gateway
4.6 Summary
5 Cloud Security Gateway – Use of ASOA 
5.1 ASOA proposed Service Framework
5.1.1 Use of Map-Reduce in ASOA
5.1.2 Use of Parallelism
5.2 Use of Service in the Cloud
5.3 ASOA Use Cases
5.4 Summary
6 Master Observer Service (MOS) 
6.1 Master Observer Service
6.2 Challenges associated with Services’ Performance
6.2.1 Availability of proper bandwidth
6.2.2 SLA issues among involved service providers
6.2.3 Surge in Cloud access
6.3 Service Governance
6.4 Service Security
6.5 SOA 3.0 MSS Model
6.6 Analysis and Results
6.6.1 Services Failure Prediction
6.6.2 Success of Services Utilization
6.7 Closing Remarks
7 Conclusion

Télécharger le rapport complet