Service Encapsulation is often used to hide the internal representation, or state, of an object from the outside. In this way, we can present to the outside world a cleaner, simpler, and more coherent view of the internal systems. Many services which were not initially planned for a Service Oriented Architecture (SOA) may get encapsulated or become a part of a SOA in this way.

In the example of ACME Social and University of Nowhere, both the parties agreed on exchanging information in order to improve the existing geolocation service of ACME Social. In particular, ACME Social would like to receive the following information from the University of Nowhere:

• Retrieve a list of unique IDs of the students
• Retrieve the email addresse(s) of each student
• Get the class that the student is supposed to follow
• Retrieving the exact coordinates of the location of a given student according to the University of Nowhere.

Service Encapsulation: Can we design it as a stateless service?

Probably yes, even though students and their respective locations will change. From the point of view of the methods, we can expect that their behavior will not change over time. A possible UML diagram that describes the interface of the service could be as follows:

The class represents all the functionalities requested by ACME Social in 4 methods. It does not have attributes and this approach will keep the design simple. IDs, emails, as well as geocoordinates will be shared as Strings in order to use one of the basic types of a service.

In the case we will decide to implement a WS-I compliant service, we can assume that the calls of the methods can fail and may trigger exceptions on the service consumer’s side.

What about the concerns of ACME Social and the documentation of the service?

As the service represents the entry point of the systems of the university of Nowhere, we need to carefully balance the complexity of the interface that we need to design. On the one hand, it must be able to mask all the idiosyncrasies of the IT of the university in order to facilitate its consumption by ACME Social. On the other hand it must be able to deliver everything that is needed and agreed. The figure below shows how this interface sits at the intersection points of two different worlds with different needs and goals:

ACME Social, i.e. the client of the service needs a clear answer to the following questions:

• What does the service do? Answering to this question will require a proper documentation of the methods. The name may be intuitive, but some of its behavior may not. Therefore, it needs to be carefully documented.
• How can we use the service? The best way to answer this question is with an example of use. ACME social may use different languages so the example(s) need to be written in Java and Python (for example) and the code must be well documented (see these best practices).
• Where can we locate the service? The URL of the service, together with the way to get the authorization of use, should be part of the documentation. In addition, the service should be part of an UDDI registry as well.

ACME Social is not at all interested in:

• How to represent internally the request received from ACME social
• How to implement the service
• Where to host the server needed for running the service
• How to publish the service in the Internet
• How to keep it running

These aspects are of fundamental importance for the University of Nowhere. However, these concerns should not be shared with the consumers of the service.

A #service Encapsulation example using a location service. #servicedesign #programming
Share on X

The post A Service Encapsulation Example Using a Location Service appeared first on Francesco Lelli.

Value Chain

A value chain is a combination of the systems a company or organization uses to make money. In other words, a value chain is made up of all the various subsystems that are used to create products or services. This includes the company’s processes from start to finish.

Michael Porter developed a strategic management tool for analyzing a company’s value chain. In his book “Competitive Advantage” (published 1985), Porter laid out his method of analyzing value chains. He sought to define a company’s competitive advantage noting that it stems from the company’s processes, such as marketing and supporting activities.

All five primary activities are essential in adding value and creating a competitive advantage. They are:

• Inbound logistics: arranging the inbound movement of materials, parts, and/or finished inventory from suppliers to manufacturing or warehouses, assembly plants, and retail stores
• Operations: managing the process that converts inputs (raw materials, labor, and energy) into outputs (goods and/or services).
• Outbound logistics: the process related to the storage and movement of the final product and the related information flows from the end of the production line to the end user.
• Marketing and sales: selling processes and products for creating, communicating, delivering, and exchanging offerings that have value for customers, clients, partners, and/or society at large.
• Service: all the activities required to keep the product working effectively for the buyer after it is sold and delivered.

Companies can harness a competitive advantage at any one of the five activities in the value chain. For example, by creating outbound logistics that are highly efficient or by reducing a company’s shipping costs, they can either realize more profits or pass the savings to the consumer in the form of lowered prices.

The use of support activities helps make primary activities more effective. Increasing any of the four support activities helps at least one primary activity to work more efficiently.

• Infrastructure: consists of activities such as accounting, legal, finance, control, public relations, quality assurance, and general (strategic) management.
• Technological development: pertains to the equipment, hardware, software, procedures, and technical knowledge brought to bear in how the company transforms inputs into outputs.
• Human resources management: consists of all activities involved in recruiting, hiring, training, developing, compensating, and (if necessary) dismissing or laying off personnel.
• Procurement: the acquisition of goods, services, or works from an outside external source. In this field, the company also makes decisions concerning purchases.

The video below introduces the value chain and discuss the benefits of this model as well as its limitations:

System Dynamics

System dynamics is a methodology and a mathematical modeling technique to frame, understand, and discuss complex issues and problems. Originally developed in the 1950’s to help corporate managers improve their understanding of industrial processes, System Dynamics is currently being used throughout the public and private sector for policy analysis and design.

System dynamics tries to understand the nonlinear behavior of complex systems over time using the following key concepts:

• Stock: an accumulation of people or things in a specific location or with a specific condition in a system. An element of a system that accumulates or drains over time. Stocks are the memory of a system and are only affected by flows.
• Flow: the movement of people or things between stocks within a system boundary or across the model boundary and thereby into or out of the system (through sinks and sources); changes in stocks over time. Flows represent activity, in contrast to stocks that represent the state of the system.
• Feedback: when the effect of a causal impact comes back to influence the original cause of that effect. A feedback loop is an alternating sequence of variables and causal links that creates a closed ring of causal influences.
• Table function: a numeric table version of a graphical function.
• Time delay: a delay in the flow of conserved material or people.

The video below provides an introduction to the concept:

The lecture below gives a set of examples as well as familiarizes you with the concept of System Dynamics:

I hope that these videos will serve as an introduction for understanding the dynamics that drive a company.

The post On Understanding the Dynamics that Drive a Company: Value Chain and System Dynamics appeared first on Francesco Lelli.

Current cloud service description languages envision the ability to automatically combine cloud service offerings across multiple abstraction layers, i.e. software, platform, and infrastructure service offerings, to achieve a common shared business goal. However, only little effort has
been spent in this direction. This paper formalizes the issue of automatic combination of cloud services showing its computationally intensive nature. In order to overcome this issue we propose a Resource Description Framework (RDF)- based prototype implementation that leverages a batch process for automatically constructing possible combinations of cloud services. Using this approach we are able to analyze possible combinations of cloud services that may fit particular customer needs in a timely fashion

Some relevant Key words: Cloud, Cloud Services, Service, Composition, RDF for Cloud

Cloud resources offered as services can be described using a common schema model and hence can be composed in order to achieve a common business goal. We present in this paper the issue of composing cross-layered cloud services to build a Service-based Cloud Application (SBCA), and formalize it as a tree navigation algorithm involving external approaches for matching cloud service descriptions.
Given the fact that there could be a huge number of cloud service offerings in a real marketplace, this algorithm may grow exponentially and become a computationally intensive task. For our prototype implementation, RDF is used to create a sample model containing sample cloud service offerings, a batch process is implemented to continuously scan the model and discover possible compositions of cloud services, and SPARQL is used to retrieve cloud services and their possible compositions in a timely fashion. In the future, we intend to continue investigating the issue of cross-layered cloud service composition in order to discover and quantify the benefits and the limits of this approach by providing experimental results.

Full article available at the following link:

Issue in Automatic Combination of Cloud Services:
https://doi.org/10.1109/ISPA.2012.71

Your help in sharing the idea is very welcome!

Cite this paper as:

D. K. Nguyen and F. Lelli, Issue in Automatic Combination of SaaS, PaaS and IaaS, 10th International Symposium on Parallel and Distributed Processing with Application ISPA 2012 track Clouds for Business and Business for Clouds, Spain, Madrid, July 2012

Related Article:

• The Many Faces of the Integration of Instruments and the Grid

#issues in #automatic Combination of #Cloud #services for #CloudComputing #RDF and understanding meta-information
Share on X

• Full list of Articles
• Full list of Journal Publications
• Full list of Conference Publications

The post Issue in Automatic Combination of Cloud Services appeared first on Francesco Lelli.