Stanley Ramalho Lima

Stanley Ramalho Lima

Biography

Stanley Ramalho Lima obtained a Bachelor of Mechatronics Engineering at ISEP (Institute of Engineering of Porto, Portugal), an MSc in Software Engineering at UNIEURO (Euro-American University Center, Brazil), and is a Master's student in Electrical Engineering at UNB (University of Brasilia, Brazil). Has experience in the science area of computing, with emphasis on information systems, acting on the following topics: cloud computing, architectures based on SOA models and descriptions of services and distributed systems in general.

Contributions

rss  subscribe to this author

Ruben Cruz Huacarpuma

Ruben Cruz Huacarpuma

Biography

Ruben Cruz Huacarpuma is PhD student in the department of Electrical Engineering at the University of Brasilia, Brazil. He received his MSc in Informatics (specializing in Database for Bioinformatics) from University of Brasilia. His expertise is in traditional and non-traditional databases. The traditional database expertise includes relational database manage systems (RDBMSs), storage protocols, content management, and replication data. Besides that, his expertise is related to new technologies such as NoSQL databases for storage, and managing Big Data for a huge amount of data. He is currently a PhD research student at the Laboratory of Decision Making Technologies (LATITUDE) and works as a researcher in the database at the Ministry of Planning. His main interests are in databases, content management, information retrieval, metadata management, and the underlying technologies that support work in these areas.

Contributions

rss  subscribe to this author

Bookmarks

A Methodology for Identifying Candidate Services and Compositions Published: April 3, 2015 • Service Technology Magazine Issue LXXXIX PDF

Introduction

The use of a methodological development can bring several benefits to an organization, such as continuous improvement, easiness of system maintenance, and reduction of dependence on key persons. For a system based on SOA to obtain the expected benefits, the principles known from traditional software engineering need to be adapted to service-oriented development. Systematic approaches to the design, development and maintenance of service-oriented systems are necessary.

The application of SOA means using services to express business processes where the size of the service granularity directly affects the quality of service that includes many aspects, such as coupling, autonomy, cohesion, modularity, etc. [REF1]

It is proposed in this work, a methodology for service identification, candidate to compose an SOA application. The proposal consists of two stages: the first is the identification of services through multiple activities, where the designer must list the candidate services based on two methods: component-based and database-service. Within this list of potential services, an SOA analyst applies the method of consolidation of services where the main objective is to help the SOA expert in decision making about the services to be implemented, ensuring that services reach characteristics such as flexibility, reusability and proper granularity project needs. As a result of this process, we have a service catalog, with potentially more services aligned with the principles of service-oriented architecture.

Proposed Methodology

The service development process starts from a demand a development or even a set of requirements to be developed. From these requirements, the modeling of business processes and service repositories that are related to the application are analyzed in order to identify candidate services that meet the demand. In addition, the requirements already in place in applications or as services, correspondents, are analyzed in order to identify potential applications to be providers of existing services and also services that can be reused to meet the demand. To assist the SOA architect in identifying service granularity and reusability needed to meet project needs and business, these two identification service methods will be presented: component-based and database-service, and subsequently, the service consolidation mop-up method.

Methods of Service Identification: Component-Based

The development with components based on the construction of interconnected systems where the creation of new components happens due to the implementation specification of business requirements. A simple example is of two components expressed in UML 2.0. The checkout component, responsible for facilitating the client's request, requires the card processing component to charge the credit card/debit customer.

img

Figure 1 – Component-Based

Methods of Service Identification: Database-Service

After having developed the data model, specified data types and how they are encapsulated, we can reuse them for different applications. For example, instead of having a single financial investment, an organization can deploy one or more services that expose the business activities, which can be called independent processes. Thus, other systems (such as services or applications of Human Resources) can easily leverage financial computing resources for current or future needs.

This database-service method allows users to create, store, modify, and retrieve data from anywhere in the world as long as they have Internet access. Thus, the analysis of these services must be made from the entities they operate. These entities can be identified directly from the business process model, for example, listing the entities associated with the data models for clustering.

img

Figure 2 – Database-Service

Method of Service Consolidation: Mop-up

Agility is one of the main reasons for using SOA. Thus, quantifying and qualifying in different measures the services that compose the application makes possible a comparison between different candidate services to compose SOA application. With that, we use this methodology, metrics Chidamber & Kemerer, to consolidate the list of candidates for services already identified by the methods: component-based and database-service.

The combination of the methods of identification with the service consolidation method will allow an equilibrium between the needs of the project and the grain required by the business. The metrics Chidamber & Kemerer (C & K) are used to measure the main factors affecting the quality of a software object oriented encapsulation, abstraction, and inheritance [REF 2], [REF 3].

The C & K metrics consist of six measures that are identified below:

  • WMC - represents the number of methods implemented in a class
  • DIT - indicates the greatest distance from one class to the superclass further up the inheritance hierarchy
  • NOC - is the number of sub-classes of the class immediately below
  • CBO - represents the number of classes where a class uses an element
  • RFC - represents the number of methods that can potentially be executed in response to a message received for an object of that class
  • LCOM1 - measures the lack of cohesion between the methods of a class

For example, one class consists of methods and attributes. These methods tend to make changes in the values of attributes of the classes (a class is responsible for maintaining and changing their status). Knowing this, the metric discovers how many attributes are modified by those methods independently.

LCOM1 = P - Q

A class X with three methods with the following attributes:

M1 = { a2, a4}
M2 = { a1, a3, a4}
M3 = { a5, a6}

img

Figure 3 – Class X

So to calculate the intersections of LCOM1 between pairs (Ij, Ik):

M1 ∩ M2 = {a4}

M1 ∩ M3 = ∅

M2 ∩ M3 = ∅

P = {(Ij, Ik) | Ij ∩ Ik = ∅} = { (M1, M3), (M2, M3)}

Q = {(Ij, Ik) | Ij ∩ Ik ≠ ∅} = { (M1, M2)}

LCOM1 = |P| - |Q| se |P| > |Q| = 1

  1. The WMC metric, DIT, and NOC will be used to compare the degree of complexity between classes that make up the services.
  2. CBO and RFC will be used to compare the level of coupling between classes that make up each service identified.
  3. LCOM1 metric is used to compare the cohesion of classes where the intersections of comparison will be made between the different services.

These are not just good metrics to reduce complexity and increase performance in their services. The use of these metrics is possible to quantify the coupling and the lack of cohesion between the services. Thus, the SOA expert can compare a service candidate with another candidate and see which has the best potential to meet the needs raised in the beginning of the project and the specific SOA principles [REF 4], such as low coupling, high cohesion and appropriate level of granularity.

Method Name Description State

The method by which the service was identified.

* Component-Based

* Service A A description of the capacity and functionality of each service.

The state in which the service will be published.

* Provider

* Service B * Consumer
* Database-Service * Service C * Stateless

Table 1 – Catalog of Services Resulting

This service catalog and a result of the proposed methodology will serve as input to the phase of the development cycle and analysis and service design, which will help analysts and developers to make decisions about the services that will be implemented.

Description of the Service Catalog

Name of service:

Priority service names should use vocabulary and terminology to make their meaning intuitive for developers and consumers.

Description of Services:

The service description information is required to use a service. In most cases, there is no one "right" description. The purpose of description is to facilitate interaction and visibility. The technology used to provide the service, such as a programming language, cannot be part of the service definition.

State of Service:

  • Stateless – Does not depend on any pre-existing condition. Services should not depend on conditions of other services. They receive all the necessary information to provide a consistent response [REF 1].
  • Provider – The resource that performs the service in response to a request from a consumer [REF 1].
  • Consumer – The consumer is who consumes or asks the result of a service supplied by a provider [REF 1].

Services should not depend on the state of other functions or processes.

Conclusion

SOA is an architecture that contains loosely coupled services and is platform independent. You should be able to change, modify, and replace a component and cause minimal or no impact to the system or service [REF 5].

To overcome these problems, this work focused on a qualitative analysis with methods: component-based and database-service, and a quantitative consolidation with the mop-up method. As a result, we achieved an adequate methodology and development project that considers the SOA principles and brings effectiveness and efficiency in application development.

One of the main contributions of this work is a strategic approach to building and consolidating services with sound principles of a service-oriented architecture. The combination of the methods of identification with the service consolidation method allows equilibrium between the needs of the project and the grain required by the business.

On the other hand, the methodology presented in this work depends significantly on the knowledge and SOA specialist capacity to identify services with principles of service-oriented architecture, but brings with fundamental principles of SOA services.

In the future, more work can be done to decrease the dependence of understanding and skills of SOA experts involved. We note that such skills significantly influence the service identifier. For example, concepts such as reusability, cohesion and service coupling are directly affected by the understanding of the SOA expert (which is normally subject to change with increasing experience).

References

[REF 1] Erl, T.: 'Principle of Service Design' (Prentice Hall, 1st 2007)

[REF 2] Chidamber,.S.,Kemerer,.C.,etal.:'A MetricsSuiteforObjectOrientedDesign',IEEETransactions on Software Engineering, 1994, 20, (6), pp. 476-493

[REF 3] Edison, P.F., Marco, A.W., Elias, T.S., Fabiano, C.C., Carlos, E.P., Flávio, R.W.: 'DERAF: A High- Level Aspects Framework for Distributed Embedded Real-Time Systems Design', 10th International Workshop, Vancouver, Canada, March 2007, pp. 55-74

[REF 4] Papazoglou, M.P., willem, J.V.D.H., et al.: 'Service-oriented design and development methodology', International Journal of Web Engineering and Technology, 2006, 2, (4), pp 412-442

[REF 5] Erradi, A., Sydney, N.S.W., Anand, S., Kulkarni, N.: 'SOAF: An Architectural Framework for Service Definition and Realization'. EEE International Conference on Services Computing (SCC'06), chicago, United States, September 2006, pp 151-158