1.

INTRODUCTION
The ABC Banking Gathering is focused on furnishing its clients with monetary
administrations. The main business activity is the transaction processing system, which
controls how money moves between accounts. Additionally, the bank offers a variety of
online tools to assist customers in managing their accounts. Currently, the company utilizes a
LAN-based system that can be accessed online with outdated software. According to
Sommerville (2010, p. 245), legacy software is outdated technology that is necessary to the
business process but does not have a structure or documentation. Crotty and Horrocks (2017)
also point out that maintaining an outdated system is not financially viable. In order to
maximize return on investment, maintain competitiveness, and facilitate future expansions,
the ABC Banking Group requires a brand-new cloud service-oriented architecture that takes
into account current technological advancements.

The first section of the report will be an examination of the client's requirements. Using this
method, the problem can be better understood, ambiguity in the specification can be avoided,
and criteria for evaluating the system will be provided as the project nears completion. After
capturing the objectives, the report will focus on carefully analyzing a variety of readily
available software architectural styles to investigate the best applications and role
investigations of each style. The two architectures that are best suited to this project based on
software quality characteristics will then be compared in the report. This approach will help
with assessing the two structures utilizing the factors that are generally fitting for the given
circumstance. The comprehensive comparison will support the chosen architecture and assist
in the plan for migrating from a LAN-based system to the cloud. After evaluating the cloud
service and deployment methods, the best options will be selected. The report will suggest a
customer-friendly architecture design by utilizing UML diagrams. This report will carry on
the design process and include a number of sequence and activity diagrams, as well as an
Entity-Relationship (ER) diagram for the database. The next section of the report will look at
the technology that the financial industry might use. A suitable technology will be selected
and supported to guarantee the correct implementation of all previously identified
requirements. After that, the report will briefly discuss the phase of the technology's
implementation by displaying a few screenshots and describing the issues that were
encountered.

2. HIGH LEVEL ANALYSIS AND DESIGN

The analysis portion will concentrate on examining the requirements by employing Object-
Oriented tools, also referred to as OOA (Object-Oriented Analysis). Modeling the system
over the limitations of implementation is the focus of this strategy.
2.1 Textual Analysis The textual analysis is ideal when the problem description is known at
the beginning of the project. The input text is basically broken down into verbs and nouns by
the analysis. The objects and their characteristics are described by the nouns, while the
application's procedures are frequently referred to by the verbs. Despite OOA's clear
distinction between methods and objects, some nouns may be irrational and should be
ignored. Similar to this, the verbs may be repeated and synonyms may be used to describe the
same verb in a lengthy textual description. This suggests that, despite the analyst's perception
that the phrases are the same, they may actually mean two completely different things in the
business logic. To avoid these issues, a thorough understanding of the business logic is
required.
Table 1 shows the fundamental classes, their characteristics, strategies to convey business
targets and collaborations between the classes.

CLASSES
Menu, Account, SavingsAccount, CurrentAccount, Transaction, DirectDebit,
ExternalTransaction, Customer, Individual, Corporate, ABCBankingGroup.
ATTRIBUTES (all private)
Account – runningTotals, openDate | SavingsAccount – interestRate | CurrentAccount –
overdraftLimit | Menu – List <Transaction> transactionList, List <Account>
customerAccountList, List <Customer> customerList | Customer – accountNumber, name,
address, contactNumber, email, password | Individual – surname, gender, dateOfBirth |
Corporate – companyType |
Transaction – amount, timeStamp, sender, receiver | DirectDebit – paymentDate |
ExternalTransaction – branchName, branchAddress, branchPostCode, branchCode.
METHODS (getters and setters inclusive)
Account – showCustomerTransactions | Menu – inisitateTransaction, addCustomer,
deleteCustomer, openAccount, closeAccount, editCustomerDetails, login, logout |
Transaction – depositMoney, withdrawMoney | Customer – totalNumberOfCustomers
| Individual – workOutAge.
INHERITANCE
Transaction – DirectDebit, ExternalTransaction | Customer – Individual, Corporate |
Account – SavingsAccount, CurrentAccount.
AGGREGATION
Menu – Account, Transaction, Customer | ABCBankingGroup – Account.
ASSOCIATION
Account – Transaction | Menu – ABCBankingGroup.
2.2 Use Case Diagram
Use Case Diagram A use case diagram is frequently used to define and visually depict each
user's goals. It focuses on each system user while examining the processes involved in
interactions with the system.

It was discovered that the system will be utilized by two user groups: employees and
customers The client will primarily use the system to manage their bank account and handle
transactions. The staff will act as the system's administrator, providing users with guidance
and supervision. Both client types can do their undertakings as individuals from the client
bunch thanks to the framework's specific capacities for every sort. However, both types of
users can access a specific system service because some functionality applies to both types of
users. Meetings and client honors can be utilized to do this. The requirements must be
documented after all user objectives have been identified.
2.3 UML Class Diagram
The class diagram depicts the relationships that exist between the various classes, as well as
the static structure, methods, and properties of those classes. Using this diagram,
requirements can be translated into a data model, enabling the creation of a system that meets
the client's requirements.

The class diagram that was created for this project following the analysis phase is depicted in
Figure. It shows generally significant classes, properties, and techniques expected to satisfy
the needs of the client. A new class was built following the textual analysis to elegantly adopt
a service-oriented strategy. The business uses the class "DataStorage" as a database to store
all relevant data.
2.4 Activity Diagram
Activity diagrams represent the activity workflow while displaying process decisions and
alternative routes. These diagrams aid in the development of the code because each action in
a function has a logical, graphical algorithm that can be easily translated into code. Activity
diagrams are also modeled with UML.

Fig - Edit Banking Details

 Fig – Transfer Money

Fig – Withdraw Money

2.5 ER Diagram
The database will be used to store all necessary data in a single place. An entity relationship
(ER) diagram is used to plan the design of the database by displaying entities and their
relationships. Optimizing queries with a productive database reduces the latency of each user
operation.
3. SOFTWARE ARCHITECTURE
Object-Situated and Administration Arranged plan designs are the two that are the most ideal
for this venture. The fact that these two styles not only satisfy the majority of clients'
requirements but are also approaches that are currently in high demand is evidence that the
implemented system will be able to withstand the rigors of the future. The majority of
software engineers will be able to easily carry out system maintenance because of its current
popularity.
The client and server were not considered for the client-server architectural style because of
coupling. Due to the tight coupling, reusability and scalability suffer. The OO and SOA are
loosely coupled to meet all user requirements because the client wanted to expand their
services in the future. Additionally, the client-server model performs poorly when dealing
with a large number of users (Vogel et al., 2011, p.196). Since it is guessed that an enormous
number of individuals will utilize the framework at the same time, this presents a huge issue
for a financial framework.
Three-tier architecture was overlooked due to its subpar performance in comparison to OO
and SOA. The N-Tier architectures were abandoned due to their complicated maintenance
requirements. Both SOA and OO architectural styles are more challenging to implement than
SOA and OO, indicating that project development would take significantly longer. The
layered architectural style was abandoned due to poor performance. When contrasted with
SOA and OO, the layered methodology takes more time to handle information, as was
recently referenced. The component-based architectural style will continue as a SOA.
The OO architectural style was chosen because it is easy to scale due to polymorphism, can
be reused due to inheritance, and can be fully tested with the majority of the available
methods. Because it is scalable, reusable, loosely coupled, and independent, SOA is an ideal
rival to OO. The projects are ideal solutions to the problem because they outweigh the
disadvantages of the two architectural styles.
Object Oriented Architecture
In order to "describe system as a collection of classes," the object-oriented (OO)
architectural style makes use of object decomposition (Oussalah, 2014, page 8). It
focuses on transforming intricate systems into interconnected objects that represent
memory data structures. Figure
 The Object-Oriented Architectural Style shows objects, their attributes, and data
management strategies as examples of the OO architectural style. The OO paradigm
relies heavily on relationships to show how objects interact with one another. Vogel and
others, (2011), pages 144-145), offer a summary of the following connections:
 The connection: An object that belongs to the current class or another class is
used by the current object.
 The current object is a subset of an aggregate of another object.
 Heritage - The adolescent class gets all of the attributes and procedures for the
parent class.
 Point of interaction and Theoretical Class: A class can use an interface to show
all of the available methods but not their implementation.
Polymorphism, which empowers the article, variable, and activity to take on various
structures, is one more pivotal part of item arranged programming (OO). The OO paradigm is
scalable and extensible because it allows for multiple implementations of the same interface
to be declared. Polymorphism can be broken down into two groups: compilation and the
runtime The call in compile-time polymorphism (static binding) is resolved by the compiler,
allowing for prompt execution. In runtime polymorphism (dynamic binding), the call is
resolved by the JVM during the runtime, which slows down execution but adds flexibility.
Modularization because of deliberations is one of the OO building style's advantages.
Additionally, encapsulation enables the creation of high-level objects and improves
information concealment (Vogel et al., 2011, p.147). Because it is easy to maintain, highly
moduliarized, and extensible, the OO paradigm is an excellent choice for the project at hand.
Additionally, the delivered code is effectively testable, ensuring that combinations and
framework modifications do not cause anomalies. A drawback of the OO architectural style is
that developing an elegant solution that meets all requirements requires a thorough
understanding of the problem. According to Vogel and others (2011), p.147, OO does not
entirely support reusability because classes are too ambiguous and less conceptual. The
object-oriented approach has a major disadvantage in that it takes longer to create systems.

Service-Oriented Architecture (SOA) deploys distributed systems through the use of

independent components. It is a collection of components that work together to provide
complex application functionality. SOA makes it possible for software to communicate using
XML-based protocols like WSDL (Web Service Definition Language) and SOAP (Simple
Object Access Protocol) (Sommerville, 2010, p. 509). SOAP makes it easier for the services
to exchange structural information. WSDL, on the other hand, is a standard for defining an
interface that describes the functionality of a service. The REST (Representational State
Transfer) architecture, which is a simplified version of SOAP and WSDL, can also be used to
implement web services.
Vogel et al. assert, A service is a distributed, loosely coupled, stand-alone, scalable, reusable,
distributed, and standardized solution that provides a specific functionality. It doesn't use any
software or hardware. 2011, p.206). A service can contain additional services in addition to
the service implementation and service interface. Figure 8 shows the start of SOA. The
service providers create a service with an interface specification and complete documentation
by employing WSDL. By publishing the service in the service registry, it becomes
searchable. On the service registry, the service requester locates the service provider and the
service specification. Once the provider has been identified, it is possible to establish
communication between the application and the service, typically via SOAP.

4. ARCHITECTURE COMPARISION
4.1 Correctness
Correctness checks to see if a user's need was met in the right way. Because the system won't
be used if the user requirements aren't met correctly, this is essential to the current system.
In both architectural styles, a variety of testing techniques can be used to validate and verify
the software. OO supports automated testing tools like unit testing, which verify that a
function has been implemented correctly. In a similar vein, SOA also supports automated
testing; However, SOA's architecture makes implementation more challenging than OO's.
Dustdar and Haslinger (2004) say that distributed systems don't have automated testing,
which would make SOA-based systems more accurate. Because of the need to test both the
assistance part and individual administrations independently, unit testing in SOA takes
significantly longer (Chatterjee, 2008). Since the framework needn't bother with to be
reproduced, reconciliation testing in OO might be easier. This is a problem in SOA because
service proxies must be established for integration testing to determine whether a use case
was met (Chatterjee, 2008).
Service in SOA is typically a black box for the customer, preventing code testing through
inspections and walkthroughs. The performance of the code might suffer as a result of this
strategy. The OO architectural style, on the other hand, is typically white-box, allowing other
employees to inspect and evaluate the code to make sure it is fully optimized. The SOA's
lack of comprehensive testing tools may cause the software to be inaccurate. When
inheritance is used in the OO style, reusing software that has already been tested may reduce
the amount of testing required. Since service reuse is one of SOA's main benefits, there are
many similarities between the two styles of architecture. However, it is essential to test both
when using third-party administrations; the customers and service providers to ensure that
the service is provided correctly and in accordance with the specifications. This takes a long
time and costs money as a result. Also, these kinds of tests usually only look for errors, not
whether the function actually gets the user where they want to go.
The development process is greatly supported by the OO architectural style to ensure that the
appropriate requirements are captured, converted into the appropriate design, and
implemented. SOA also helps with the development process, but it puts less emphasis on the
user and more on the service itself. Despite its usefulness, the service's abstract nature may
compromise the accuracy of the function.
This comparison shows that the OO architectural style uses a variety of methods to achieve
higher levels of correctness. In some cases, the developed system cannot be validated or
verified because SOA is a relatively new technology.
4.2 Maintainability
The method of keeping up with the framework is a concern for viability. A good software
system should be simple to use and well-documented, allowing outside engineers to manage
it after it is deployed. Maintainability operations can be broken down into two categories, as
stated by Zhu (2005, p. 36): modification for the purpose of corrective action and adaptation
to a shifting environment. The first type examines the difficulty of addressing system flaws.
The second type looks at how difficult it is to change the system by adding new features in a
similar way. Both types of maintainability are crucial to the current project because the ABC
Banking Group intends to expand the system's functionality in the future and the release of
bugs is inevitable.
For optimal maintainability, Sommerville (2010) states that the system must have loose
coupling and high cohesion. In engineering, coupling looks at the conditions between the
parts, while union looks at the conditions inside the parts. Cohesion is a measure of a
component's self-containedness (Sommerville, 2010, p. 123). The OO architectural style and
SOA are both modular and loosely coupled. As a result, the component that is required can
be changed right away. In object-oriented development, encapsulation allows programmers
to modify the implementation without affecting the interface. This is because they are
separated. Similar to SOA, which separates the execution from the connection point,
Developers are able to easily modify the implementation thanks to SOA's service granularity.
Both architectural styles aim to create simple, easy-to-maintain systems that are also well-
documented. Consequently, the two architectural styles' maintainability characteristics are
comparable.
4.3 Efficiency
The efficiency of the system defines its responsiveness. It looks at how long it takes to
process a three-part event sequence (Zhu, 2005, pp. 33–34). To begin, the amount of time
necessary to establish communication among the components. Second, how long it took to
process the component's execution. The time spent synchronization and mutual exclusion
during parallel execution is taken into account in this calculation. Third, the amount of time
required to implement the business logic. It looks into the algorithms and data structures that
are used to make functionality available. Each of the three components is affected by the
architectural design.
The communication between components is different in both architectural styles. SOA is
dependent on the network because the data is passed using well-defined formats. An
agreement-based service contract is how SOA services communicate, as stated by Koskela
(2007). This demonstrates the extent to which the network's speed affects component
communication. OO communicates through methods, dependency injection, or adaptors.
Sadly, there are currently no comparison tests available to determine which approach is more
effective. Whatever the case may be, productivity can be examined from a different angle.
Because services are independent of hardware and software, procedural programming can be
utilized in components that are processing greater loads. Because it follows the hardware
architecture, procedural programming is significantly faster at processing data than OO. The
efficiency of SOA is greatly improved by this significant benefit.
4.4 Scalability
Two aspects of scalability are affected by the architectural design. The first section looks at
whether the system can handle more work without affecting its overall performance. The
second section deals with adding more features to the system.
According to Shim and co. (2008), SOA was familiar with oblige brief necessity changes.
This is accomplished by creating services that are reusable, self-contained, independent, and
loosely coupled and serve a particular function for the system. This makes it simpler to foster
new framework usefulness since parts can be reused without any problem. Vogel and others
2011 (p.147) battles that the articles' unreasonable particularity makes it doubtful that OO
structures will accomplish reusability. Additionally, Voelz and Goeb (2010) contend that
SOA has a much higher level of abstraction than OO, making it simpler to reconfigure
services without modifying major system components. Because there are service providers,
scaling the system is much quicker when they are utilized. Due to its fundamental principles,
SOA is generally more scalable than OO, which is more dependent on classes.
4.5 Reliability
Reliability is the likelihood that a system will fail within a predetermined time frame or vice
versa. These failures may occur as a result of a poor architecture choice. As indicated by Zhu
(2005, p. 35), a decent engineering separates complex issues into more modest, more
testable, and less difficult parts. As a result, component failure risks are reduced.
Sommerville (2010, p. 323) recommends using the POFOD (Probability of Failure on
Demand) and ROCOF (Rate of Occurrences of Failures) metrics to assess the reliability.
POFOD is as often as possible used in frameworks where a disappointment could bring
about huge issues. ROCOF works best in systems that frequently require maintenance,
making it an excellent choice for this project. On the other hand, Zhu (2005, p. 35) suggests
that the "mean time between failures" can also be used to measure reliability. This suggests
that a problem's resolution time can be used to evaluate an architecture's value.
It stands to reason that an architectural design that receives better upkeep will be more
dependable given that the amount of time spent locating the fault is what determines
reliability. However, after comparing OO and SOA, it was determined that the maintenance
was comparable. In both architectural styles, the problems are broken down into manageable
pieces that are put into action. If reliability is looked at from a metrics perspective, it is much
easier to estimate POFOD and ROCOF in the OO paradigm. This is because, in comparison
to SOA, OO has significantly more automated tools. In OO, a number of tests can be run to
see how reliable the function is. This procedure would need to be done manually in SOA,
which would take more time. Additionally, the reliability of SOA may be affected by the
connection to the network. It's possible that the service provider will provide a service that is
highly dependable; however, if communication issues arise, the service might not be
dependable. Consequently, OO is thought to be significantly more reliable than SOA.
4.6 Reusability
The ease with which software components can be reused in other systems is referred to as
reusability. According to Zhu (2005), pages 36-37, an architectural style's description of
system decomposition and relationships is crucial to reusability. Complex systems can be
developed in a short amount of time by reusing components that have already been
developed by making each module independent.
Reusability is one of SOA's primary benefits. Administrations can be generally reused as
they are not attached to the undertaking (Koskela et al., 2007). They are more abstract than
OO paradigm classes. According to Vogel et al., OO "only partially supports reusability."
2011, p.147) due to the excessive specificity and detail of the classes. By separating objects
into classes, the encapsulation used in OO permits code reuse and makes inheritance possible
(Koskela et al., 2007). While this introduces reuse, the SOA style is more general and offers
more functionality that can be reused. Both architectural styles are thought to have loose
coupling, which allows for some reuse. Systems that adopt SOA are able to quickly adapt to
changes in the market and environment because SOA offers greater reusability than OO.
4.7 Portability
The portability of a system looks at how simple it is to move it from one platform to another.
Zhu (2015, pp. 35–36) says that a good architecture group the environment-dependent
facilities together to make it easy to move to a new platform. Instead of rewriting the system
as a whole, this strategy allows for the rewriting of specific components to adapt them to the
new platform. According to Zhu (2015, p. 36), the best portability is achieved by separating
the entire system from its environment.
According to Voelz and Goeb (2010), SOA is highly portable because it is based on widely
accepted standards. The SOA system is less likely to necessitate significant code
modifications because it complies with the standards. According to Sommerville (2010, p.
509), SOA are platform-independent, which means that systems that use SOA can function
in a variety of environments. In a similar vein, Voelz and Goeb (2010) demonstrate that
SOA's platform independence enables it to quickly and easily adapt to changes in the
environment. In contrast, OO is less portable than SOA because its portability is dependent
on the programming language. Furthermore, OO is dependent on the hardware architecture,
indicating that it is unable to quickly adapt to the environment. It is evident that SOA is
significantly more portable than OO.
Architecture Recommendation
Factor OBJECT‐ORIENTED SERVICE‐ORIENTED
Correctness 1 0
Maintainability 1 1
Efficiency 0 1
Scalability 0 1
Reliability 1 0
Reusability 0 1
Portability 0 1
TOTAL 3 5

5. MIGRATION STRATEGY
5.1 Examination of Service Models

By dividing the problem into a number of services, cloud computing implements SOA
principles. It provides services as on-demand resources that can be accessed over the
network. Cloud services are accessible and highly scalable. Administrations are normally
parted into three models, displayed in Figure 10. This permits to match the requests of the
clients accurately.

5.1.1 Software as a Service (SaaS)

SaaS enables pay-per-use, on-demand use of platform-independent applications that are
available for a variety of end users. A system that is leased to the customer is basically
hosted by the vendor in the cloud. According to Zaigham (2013, p. 50), developers have
access to the APIs. However, this help is generally relevant to end‐users with no
programming abilities who wish to play out a particular errand. The fact that the service
provider is in charge of managing all of the resources suggests that the service provider has
access to all of the data. The SaaS model is accessible from all platforms and does not
require much planning. The service provider offers support for the software, ensuring its
dependability. This model is less expensive because there are no licensing fees and software
is not purchased (Zaigham, 2013, p. 50). However, the limited portability makes integration
with other software and systems nearly impossible. Besides, the presentation is impacted by
the organization, proposing that issues might emerge for clients wishing to utilize SaaS
through sluggish organization associations.
5.1.2 Platform as a Service (PaaS)
PaaS basically gives stage and devices, permitting clients to make frameworks without
introducing the product and stress over the hidden foundation (Zaigham, 2013, p.49).
Operating system, database, web server, and a variety of APIs are provided by this service.
Data and application resources are managed by the client, while all other resources are
managed by the vendor. Developers who want to use resources that are automatically scaled
by the service provider to accommodate system loads are most likely to benefit from this
model.
The primary advantage of the PaaS model is the rapid development of scalable systems
without having to consider the implications of software licensing and infrastructure. PaaS
permits clients to run their own product on the stage, which beats the limit of PaaS. Security
is one of the essential disservices of PaaS on the grounds that the client doesn't have
command over information handling and virtual machine. Hill and others Another
disadvantage of PaaS is the lack of portability, which leads to vendor lock-in. Because the
application relies on the tools provided by the service provider, it is less likely to be portable
to another provider for concurrent running because the tools used might not be provided by
another provider. The customer must remain with the current vendor as a result.
5.1.3 Infrastructure as a Service (IaaS)
IaaS provides customers with web-based access to computing architecture resources like
storage and computing power. Being virtualised, it permits various clients getting to the
assets. The vendors are in charge of managing data storage, virtualization, servers, and
networking resources in addition to providing physical hardware. The service providers own
and manage the backend. Instead of having fixed monthly or annual payments, the model
charges according to how much it is used, making it possible to scale the services to meet the
needs of the business. This makes the company spend less overall.

5.2 Review of Deployment Models

The cloud arrangement models are utilized to address the various conditions of the cloud.
The models are profoundly dependent on the client prerequisites. The deployment model
comes in a variety of flavors, each offering distinct services and management and security
options.
5.2.1 Private Cloud
A private cloud is one that is hosted and managed by a private company or a third party (Hill
et al.,, 2013, p.11). The infrastructure is designed to meet a particular company's business
needs. Due to being private, just allowed individuals are permitted to get to the information
and applications (Zaigham, 2013, p.51). Private clouds are as a result highly secure and
permit full system control. As a result, private cloud maintenance costs are quite high.
Confidential cloud offers adaptability and more prominent control as the framework can be
adjusted to match the framework prerequisites.
5.2.2 Public Cloud
A public cloud is a shared infrastructure that vendors offer to customers. It provides
resources for computing and networking that can be provisioned as needed. The provider
owns and manages the back end (Hill et al., 2013, p.11). According to Zaigham (2013), p.51,
this model enables users to develop and deploy systems with minimal financial investment.
Public model is generally modest to utilize, supporting all help models. In most cases, the
vendor offers trustworthy, location-independent services. The security of this model suffers
as a result of publicity. Additionally, the model lacks complete flexibility, indicating that it is
unable to fulfill particular QoS requirements. According to Goyal (2014), public clouds lack
privacy because users are unaware of how and where their data is stored. This implies that
individuals can get unapproved admittance to the information.
Steps in the Migration Process Moving a system is a difficult and lengthy process. As a
result, it needs to be a well-organized and planned procedure to avoid as many
inconsistencies as possible. Chihi and co. 2016) point out that an effective migration
necessitates the formation of a project management and monitoring team that will provide all
documentation. Since the same people will carry out the migration process from beginning to
end, this helps to deploy a system that is more consistent. While there are numerous
businesses that provide cloud migration services, this report will demonstrate a more general
strategy.
In order to successfully migrate to the cloud, Zaigham (2013) recommends the following
steps:
1. Analyze the business case and determine the requirements to evaluate.
2. Select: select a deployment and service model that fits the architecture.
3. Perform the migration by running tests to prevent the emergence of new errors.
4. Optimize the system by fine-tuning it so that it can meet demand when it arises.
5. Operate: Monitor the system's performance with a variety of tools.

The non-functional requirements will dictate the system's quality attributes, while the
functional requirements will be used to develop all necessary system functionality. The non‐
functional prerequisites will be utilized to evaluate QoS to choose the most appropriate
sending and administration model for this task.
SOA was chosen as the best candidate after weighing the advantages of various architectural
styles in relation to the non-functional requirements. In addition, IaaS service and hybrid
deployment models were selected for this project after evaluating the quality of service.
Cloud and SOA work well together, making it easy to map and work together efficiently.
Because the hardware can reflect the architecture in order to provide services, this makes it
possible to map SOA directly onto the cloud.
A migration can begin after the evaluation and selection phases have been completed.
According to Zaigham (2013, p. 258), application profiling must be carried out prior to
migration. For a period of two weeks, it is used to evaluate the current system in terms of
usage patterns and data flow. These statistics will make it easier to measure how well the
new system works and make tests to make sure it works right. To obtain usage statistics, this
step must be completed on the current LAN-based system. The migration process to the IaaS
hybrid deployment model can begin after the application profiling phase is completed. Hill
and others 2013: p. 105) point out that the IaaS model makes it simple to move deployed
systems onto cloud hardware, reducing the amount of system changes needed after
migration. After the migration, a number of tests are run to ensure that the system was
migrated correctly and that no errors were introduced.

As part of this project, a brand-new SOA-based solution will be developed, so there is no

need to wrap the existing legacy system. However, Zhang et al. (if necessary) 2010) offer
three alterations-friendly strategies. The first is a black box approach that maps legacy
interfaces to SOA and checks them. The second is the business logic approach, which
focuses on essential functions to transform the system. The grey-box approach, which
combines the interfaces with the business logic, is the final approach. The last method is
frequently used to wrap legacy systems because it is more scalable.
The optimization phase will guarantee that SOA functions effectively in the cloud. It will
guarantee that the system can "grow and shrink automatically" to accommodate the load on
it (Zaigham, 2013, p. 258). During the operation phase, a variety of tools will be used to
monitor the deployed system to ensure that it works as intended and provides dependable
service.
▪ Because of intricacy of the movement, Zaigham (2013, pp.259‐260) proposes the
accompanying strategies to guarantee that the cycle is done accurately:
▪ The order of the migration and the procedure for connecting the systems are outlined
in the planning policy.
▪ Candidate qualification policy – Qualitative and quantitative criteria for determining
whether the server meets the cloud environment requirements.
▪ Sizing policy: mapping current workloads to cloud resources in order to maintain the
same level of performance
▪ The component deployment is defined by the placement policy.
▪ Exception policy: What must be done with components that aren't suitable for the
cloud?
Because they lower the likelihood of costly migration errors, these policies would be
extremely beneficial to this project. In conclusion, a migration guide with each step was
created for this project. This report covers the first two phases to make sure the problem is
thoroughly examined and the right requirements are captured.

6. REVIEW OF TECHNOLOGIES
After selecting SOA, the appropriate technologies for putting the system into action must be
chosen. The OO programming language was chosen as the technology of choice because it
must facilitate future scaling and maintenance. There are currently a lot of languages with
these features, but this report will focus on the top three.
C# is an OO language that is type-safe and can be used with the ASP.NET framework to
create client-server applications, web services, and distributed components. Visual Studio is
the IDE that is used the most. It supports 36 different programming languages and a plethora
of plugins, making it possible to create multiple enterprise-level systems from a single
location. The framework can code and reuse components developed in other programming
languages by adopting CLR (Common Runtime Language) (Microsoft, 2018). However,
ASP.NET-developed code is managed and therefore slower than native code. The creation of
SOAP and RESTful web services is made possible by ASP.NET.
ASP.NET's extensive set of built-in tools make it simple to create distributed, complex
backends for processing business logic and native windows or web-based frontends for
various platforms. In addition, Rapid Application Development (RAD) can be used to
rapidly develop the product by reusing existing components, and automatic monitoring
prevents a variety of issues like; memory leaks and infinite loops (Hasan, 2017). ASP.NET
system additionally unequivocally upholds security by giving confirmation, approval,
classification and honesty viewpoints. However, the fact that it is primarily focused on the
Windows operating system suggests that vendor lock-in exists because applications cannot
be developed and maintained on other operating systems.
Java is a widely‐used cross‐platform OO language permitting to foster secure frameworks,
web administrations and client interfaces. Eclipse, NetBeans, and IntelliJ IDEA are three
IDEs that support Java and are widely used. By converting the Java code into bytecode, the
JVM (Java Virtual Machine) makes it possible for it to run on any platform. JAX WS and
JAX RS can be used to write web services and components because Java was made to
support secure distributed systems. According to Oracle (2010), JAX WS is a Java API for
XML-based protocols like SOAP that enables the creation of message-oriented and RPS-
oriented web services. The ability to access web services that are not running on the Java
platform and the independence of the platform are the primary benefits of JAX-WS. JAX-
RS, on the other hand, provides an annotation-based Java API for RESTful services (Oracle,
2013). The front-end developed in Java Swing or JavaFX, on the other hand, has a negative
impact on UX and looks different from native applications due to the absence of GUI
support in Java.
Ruby is a multi-paradigm, general-purpose language that supports OO. By providing a
predefined structure for web services, the Ruby on Rails framework facilitates the creation of
MVC applications. It gives you the tools to quickly create user interfaces and makes use of
web standards to make data transfer between components easier. After downloading a plug-
in, Ruby on Rails can be developed in either NetBeans or Visual Studio; however, the
RubyMine IDE is more integrated into the framework. According to MacDonald (2015), a
variety of publicly available libraries and tools are included in Ruby on Rails, making it
possible to quickly develop applications. However, it is well-known for its slow runtime
speed (MacDonald, 2015), which is a significant drawback for a banking application that
handles transactions. Besides, the documentation is missing for specific libraries and pearls,
implying that the designer may not know how to program a specific component.
Performance issues arise because some libraries do not support multithreading, despite the
fact that Ruby on Rails does.
A database will be used because the system requires centralized data storage. Sequential
Query Language (SQL) can be used to write database queries in any of the three languages.
The most significant threat posed by SQL is injections, which give hackers the ability to
harm the database. Parameterized queries can be used to avoid this by querying the database.
Additionally, Java provides JPQL (Java Persistence Query Language), an SQL-like platform-
independent object-oriented query language. It suggests that an entity object is used to define
a query rather than a database table because it enables developers to define queries based on
the entity model.
Justification for the Selected Technology
After looking at the various technologies that are available, it became clear that Visual
Studio's C# ASP.NET will be used to implement this project. Ruby on Rails was overlooked
due to its lack of documentation—sometimes even for the rarer libraries—which is a major
problem for developers who have never worked with this technology before. In a similar
vein, performance issues caused Ruby on Rails to be overlooked. On the other hand,
ASP.NET and Java APIs provide comprehensive documentation that developers can look
over to help them write components. Additionally, both frameworks provide numerous
reusable libraries and tools. The absence of GUI components that would enable the creation
of interfaces with superior user experience (UX) was the primary reason Java was passed
over. While Visual Basic offers all of these features within the same IDE, Java could be used
to develop the backend and another technology could be used to develop a graphical user
interface by adopting SOA.
The developer also chose C# ASP.NET because they wanted to learn the framework and
language. The syntax of C# appeared familiar to Java developers, but the framework
provided additional options. Additionally, this technology is regarded as easy to learn and
makes it simple to write self-contained components that can be made available as services.
Unlike Java, which divides SOAP and RESTful web services into separate modules,
ASP.NET makes it simple to develop them using a single framework. By providing all
necessary classes for services and components, the ASP.NET framework saves the developer
time spent setting up the project and resolving calls. Additionally, it has a number of useful
features, such as; offering Windows native forms that can be used as a graphical user
interface, automatically generating the necessary classes, and automatically generating
WSDL for web services. To avoid SQL injections during the interaction, parameterized SQL
queries will be used to access the database.

7. CONCLUSION
A comprehensive analysis was carried out as a result of this report to fully comprehend the
issue and offer an appropriate solution. The brief was investigated using a textual
description, and the system classes, attributes, methods, and relationships were first outlined.
The goal of the use case diagram was to capture the user's objectives, which were then used
to prioritize the functional requirements. Moreover, the framework characteristics were
recorded as non‐functional prerequisites, alongside an itemized estimating measures.
Two suitable paradigms were chosen for a more in-depth comparison after a thorough
examination of several contemporary architectural styles. In terms of the non-functional
requirements that make up the quality of the finished system, this evaluation determined
whether or not either approach was suitable. The SOA was then selected for this project.
From a LAN-based system to a cloud-based one, a clear migration plan was established. An
architecture design was created to demonstrate the system's SOA deployment after the
analysis was finished. The report then looked at the possible technologies that could be used
to put the system into action using SOA. After looking at the three main approaches, the best
technology was chosen to put the system into action. By moduliarizing the system with
loosely coupled services and components, the developed system perfectly matches the
diagrams created in the design phase. The code adheres to OO principles and includes
system maintenance-friendly comments. The framework can be utilized by three different
client types through two clients which offer different usefulness, permitting the clients to
deal with their ledgers and perform exchanges. To assist users, each client provided a native
Windows form GUI with meaningful error messages. The system that the clients can use has
all of the functionality that was requested in the brief.
The developer was able to overcome a number of obstacles that arose during the project's
implementation and had a negative effect on the system. It would be beneficial to include
security features like encryption, a more user-friendly interface with more input validations,
and new transactions like; direct charge, standing requests and present a web‐based client
which can be open through a program. While the current iteration of the system meets all of
the requirements outlined in the brief to demonstrate SOA, it lacks a custom user interface
(UI) and security features that would allow actual clients to use the system. As a whole, this
project was a fruitful learning experience that introduced the developer to new technologies.

References
1. Antonopoulos, N., Gillam, L. (2010) Cloud Computing. Springer‐Verlag London
Limited.
2. Chatterjee, A. (2008) ‘Testing Service‐Oriented Architectures’, Dr Dobbs Journal,
33(11), pp. 46‐48.
3. Chihi, H., Chainbi, W., Ghdira, K. (2016) ‘Cloud computing architecture and
migration strategy for universities and higher education’, Proceedings of IEEE/ACS
International Conference on Computer Systems and Applications, vol.2016‐. DOI:
10.1109/AICCSA.2015.7507140.
4. Crotty, J., Horrocks, I. (2017) ‘Managing legacy system costs: A case study of a
meta‐assessment model to identify solutions in a large financial services company’,
Applied Computing and Informatics, 13(2), pp.175‐183. DOI:
10.1016/j.aci.2016.12.001.
5. Dustdar, S., Haslinger, S. (2004) ‘Testing of service‐oriented architectures: A
practical approach’, Lecture Notes in Computer Science, vol.3263, pp.97‐109.
6. Goyal, S. (2014) ‘Public vs Private vs Hybrid vs Community – Cloud Computing: A
Critical Review’, I. J.
7. Computer Network and Information Security, vol.3, pp.20‐29. DOI:
10.5815/ijcnis.2014.03.03.
8. Hasan, A. (2017) ‘Top 12 Main Advantages of ASP.NET Framework’, Arpatech, 24
March 2017. Available at: http://www.arpatech.com/blog/top‐advantages‐of‐asp‐net‐
framework/. (Accessed: 24 January 2018).
9. Hill, R., Hirsch, L., Lake, P., Moshiri, S. (2013) Guide to Cloud Computing
Principles and Practice. London: Springer London: Imprint: Springer.
10. Jyotsna, S. (2014) ‘Component‐Based Development Technologies and Limitations’,
International Journal of Engineering and Computer Science, 3(10), pp.8835‐8838.
11. Khaddaj, S. (2012) ‘Cloud Computing: Service Provisioning and User
Requirements’, 11th International Symposium on Distributed Computing and
Application to Business, Engineering & Science, Oct.2012, pp.191‐195, fig.3. DOI:
10.1109/DCABES.2012.76.
12. Khaddaj, S. (2017) ‘CI7250 Software Architecture and Programming Models
Assessment Compendium’, CI7250: Software Architecture and Programming
Models. Kingston University. Unpublished.
13. Koskela, M., Rahikainen, M., Wan, T. (2007) ‘Software development methods: SOA
vs. CBD, OO and AOP’, Proceedings of the seminar on Enterprise Information
Systems: Service‐Oriented Architecture and Software Engineering, Helsinki
University of Technology, 2007.
14. MacDonald, R. (2015) ‘Pros and Cons of Ruby on Rails’, Made Tech, 8 September
2015. Available at: https://www.madetech.com/blog/pros‐and‐cons‐of‐ruby‐on‐rails.
(Accessed: 24 January 2018).
15. Microsoft (2018) ASP.NET Overview. Available at:
https://msdn.microsoft.com/enus/library/4w3ex9c2.aspx. (Accessed: 24 January
2018).
16. Oracle (2010) Building Web Services with JAX‐WS. Available at:
https://docs.oracle.com/javaee/5/tutorial/doc/bnayl.html. (Accessed: 24 January
2018). Oracle (2013) Developing RESTful Web Services
with JAX‐RS. Available at:
17. https://docs.oracle.com/javaee/6/tutorial/doc/gilik.html. (Accessed: 24 January
2018).
18. Oussalah, M. (2014) Software Architecture 1. John Wiley & Sons, Incorporated.
19. Schulmeyer, G.G. (2007) Handbook of Software Quality Assurance. 4th edn.
Norwood: Artech House.
20. Shim, B., Choue, S., Kim, S., Park, S. (2008) ‘A Design Quality Model for Service‐
Oriented Architecture’,
21. 15th Asia‐Pacific Software Engineering Conference, Dec.
 2008, pp.403‐410. DOI: 10.1109/APSEC.2008.32.
22. Siau, K., Chiang, R., Hardgrave, B. (2011) Systems Analysis and Design: People,
Processed, and Projects. Taylor and Francis.
23. Sommerville, I. (2010) Software Engineering. 9th edn. Harlow: Addison‐Wesley.