Service Oriented Architecture Plan: Layers, Modeling, and Hardware

This report outlines an architecture plan for implementing Service-Oriented Architecture (SOA). The plan divides the infrastructure into three layers: Operational, Enterprise, and Services, emphasizing the importance of careful review at each stage. The report details a three-step approach to SOA design, including service identification (using top-down, bottom-up, and middle-out techniques), service specification (defining data, rules, services, and profiles), and service realization (selecting or building software to implement services, ensuring security and monitoring). The hardware requirements for Oracle Enterprise software are also provided. The document also includes a comprehensive list of references supporting the concepts discussed.

Running head: ARCHITECTURE PLAN TO USE SERVICE ORIENTED ARCHITECTURE
ARCHITECTURE PLAN TO USE SERVICE ORIENTED ARCHITECTURE
Name of the student:
Name of the university:
Author note:

1
ARCHITECTURE PLAN TO USE SERVICE ORIENTED ARCHITECTURE
Architecture plan to use service oriented architecture:
In order to have a clear view about the service-oriented architecture and plan accordingly, it
is effective to divide the infrastructure in terms of layers that helps to analyze the architectural
process more intuitively and accurately (Erl, Marson & Stoffers, 2017). The layers can be
divided broadly into three categories:
 Operational layer
 Enterprise layer
 Services layer
According to the authors, it is important to review each layer wisely as certain decision
regarding design and architectural plan has to be made at every layer the design goes through.
Operational layer:
This layer usually deals with application that is custom built. These applications are also
known by legacy system existing in practice (Serrano, Hernantes & Gallardo, 2014).
Applications, built with CRM and ERP package are also managed in this layer. The layer also
includes implementation techniques of object-oriented system and applications that provide
business intelligence. According to the authors, this particular layer plays crucial role in the
architectural planning as it helps to integrate the existing systems with service-oriented
techniques.
Enterprise layer:

2
ARCHITECTURE PLAN TO USE SERVICE ORIENTED ARCHITECTURE
This layer consists of tools that can be used to realize the functionality and maintain the
quality of the deployed service. These tools are managed using well-tailored governance policies
that are specially designed for custom needs. This layer is responsible for better management of
the System Level Architecture, which in turn ensures the better adoptability of the service
oriented architecture for the organization (Erl, 2015).
The typical technologies that are used at this layer are container-based which includes
application servers, which helps to manage the components specially designed for service-
oriented architecture as suggested by the author.
Services layer:
The layer consists of services that are chosen by the organization and funding related to
those services is included in this layer. The services may be static waiting for invocation or they
can be identified with proper techniques (Hurber et al., 2014).
As the authors suggested, this layer is effective to ensure the quality of services for the
overall system. The mechanism through which enterprise level components are managed belongs
to this layer.
Detailed approach for architecture modeling:
The design of service-oriented architecture can be classified into three key aspects called
identification, specification and realization of services (Biehl et al., 2014).
Identification of services:
To implement the architecture that is service based, identification of the services is of
prime importance The process is executed by combining the top-down, bottom-up, and middle-

3
ARCHITECTURE PLAN TO USE SERVICE ORIENTED ARCHITECTURE
out techniques. The effective combination of these technique helps to decompose the domain by
analyzing the existing asset and following a service model that is typically goal oriented. Due to
this, the technique is also referred to as domain decomposition (Ameller et al., 2014).
According to the authors, another important aspect of the design procedure is to analyze
the existing system so that it can be integrated with the new architecture. This analysis is also
very important to reduce the overall cost of the system architecture. The bottom up approach is
an excellent approach in this context.
The middle-out techniques is effective to identify services that are not identified in the
top-down, bottom-up approaches.
Specification of services:
Once the service requirement is identified, the next step is followed by the
specification of the components needed to implement the services (Alwadain et al., 2016). These
components are:
 Data
 Rules
 Services
 Configurable profile
 Variations

4
ARCHITECTURE PLAN TO USE SERVICE ORIENTED ARCHITECTURE
This process deals with message and event specifications related to the architectural
plan.
Service realizations:
This step is targeted at recognizing the software that is used to identify a service. The
software that is capable of recognizing the service is selected or the software is custom-built to
meet the requirements. Service realization also ensures system security, security management
and service monitoring (Girbera et al., 2014).
According to the article, proper execution of these three processes is essential for the
successful implementation of the service-oriented architecture.
Hardware requirements for service oriented architecture:
Following are the hardware requirements for the implementation of the oracle
enterprise software that is used to build the service-oriented architecture (Oracle.com, 2018):
 AMD Opteron, Intel Pentium® at 500 MHz or faster, or Intel EM64T
 Minimum 500 MB free disk space for installation, 10 GB recommended
 Minimum 1 GB physical memory, 4 GB recommended
 Solaris compatible SPARC processor at 440 MHz, or faster
 Minimum 1000 MB free disk space for installation
 Minimum 1 GB physical memory, 4 GB recommended
References:

5
ARCHITECTURE PLAN TO USE SERVICE ORIENTED ARCHITECTURE
Alwadain, A., Fielt, E., Korthaus, A., & Rosemann, M. (2016). Empirical insights into the
development of a service-oriented enterprise architecture. Data & Knowledge
Engineering, 105, 39-52.
Ameller, D., Burgués, X., Collell, O., Costal, D., Franch, X., & Papazoglou, M. P. (2015).
Development of service-oriented architectures using model-driven development: A
mapping study. Information and Software Technology, 62, 42-66.
Biehl, M., El-Khoury, J., Loiret, F., & Törngren, M. (2014). On the modeling and generation of
service-oriented tool chains. Software & Systems Modeling, 13(2), 461-480.
Erl, T. (2015). Service-Oriented Architecture: Concepts, Technology, andDesign”, Pearson
Education, 2005.
Erl, T., Merson, P., & Stoffers, R. (2017). Service-Oriented Architecture: Analysis and Design
for Services and Microservices. Prentice Hall.
Huber, N., van Hoorn, A., Koziolek, A., Brosig, F., & Kounev, S. (2014). Modeling run-time
adaptation at the system architecture level in dynamic service-oriented
environments. Service Oriented Computing and Applications, 8(1), 73-89.
Khoshafian, S. (2016). Service oriented enterprises. CRC Press.
Oracle.com. (2018). Service Oriented Architecture - What's New | Oracle Technology Network |
Oracle. Technology Network | Oracle. [online] Available
at: http://www.oracle.com/technetwork/topics/soa/whatsnew/index.html [Accessed 12
Mar. 2018].

6
ARCHITECTURE PLAN TO USE SERVICE ORIENTED ARCHITECTURE
Serrano, N., Hernantes, J., & Gallardo, G. (2014). Service-oriented architecture and legacy
systems. IEEE software, 31(5), 15-19.