Principles, Methodology and Tools for Engineering Cloud Computing Systems - Advanced Design Approaches to Emerging Software Systems - page 258

message passing among components. Depending
on the support of protocols for queue/message
architectures (JMS, AMQP) and for integration
with external entities (SOAP, REST) the same
APIs could be used to communicate with other
elements outside the platform. Beside message
bus systems, the platform could also bring the
possibility to use other protocols such as HTTP,
SMTP, etc. In some cases, the platform could
even allow components to use telephonic network
services to send SMS, establish communication
sessions with (or among) users through SIP, etc.

Component Management . Some technologies,
such as Java Management Extensions, allow
developers to expose methods for the remote
management of components. The functionality
exposed and the parameters exposed will be service
dependent, and so programmed by components
developers. However, they should be made avail-
able only through the Cloud platform utilities.
The interfaces to use these utilities can differ,
for example they could be accessed only through a
web interface or they could be called also through
protocols such as CORBA, Web Services, etc.

2.1.3 Lifecycle Control Utilities 2.1.4 Developer Utilities

These are quite standard utilities for developers to
control their components remotely. The specific
set of utilities will depend on the functionalities
to be provided to developers. However, we can
envision a minimum set of tools that platforms
should be made available:
Component State Control . The platform must
make available mechanisms so developers can
not only deploy and remove components from
the platform, but also to control transition about
states (depending on the components lifecycle
supported by the platform). For example, if the
platform implemented an OSGi-like lifecycle,
developers should be able to perform actions such
as stopping components or to update its software.
Component Monitoring . The service developer
or provider will need to be aware about the state
and events of the components that form the service.
Thus, the Cloud should made available differ-
ent monitoring functionalities: 1) reports about
platform-controlled metrics such as number of
requests, resources consumed, etc. 2) notification
and alarms, configured by the component adminis-
trator; 3) accounting (and possibly billing) info; 4)
mechanisms to notify application specific metric
values (subtasks processing times, for example)
from components through the Container and the
Monitoring system to the service provider.

Finally, the Cloud provider can make available for
developers different tools that enable the remote
management of components through the Lifecycle
Control Utilities. These tools can be Development
Utils , oriented for developers to deploy/update
service components, or Remote Control Utils for
service administrators to monitor and manage
those components. It is a requisite for these tools
to implement secure communication mechanisms
(SSH, PKI) to access the Cloud platform. Also,
these tools could be integrated with IDE tools
through the plugin mechanisms they usually
implement.
Testing Development Utils . Depending on the
Cloud platform capacities and characteristics, it
could be possible to offer a testing environment
that emulates the Cloud container and provides
“toy” implementations of the Cloud Services
(storage, etc.). Such environment is provided for
example by GAE, and it is undoubtedly a very
useful tool for developers. However it cannot
provide information about its performance under
high load situations, scalability, etc. Cloud plat-
forms should allow developers to define and run
high load tests on the platform itself with new
experimental versions of the software without
interfering with the actual service.
Versioning . Another functionality that should
be available for the Cloud platform to be a mature