• Front-Loading: In general, for each service to be used in a process model, its functionality and the BOs of its input and output parameters need to be pre- speci ﬁ ed, and which IT system shall offer this service. Using the LPD, a business process modeler may then use this information. Different systems may store different attributes for BOs, i.e. those they need. To foster front-loading, the Logistics Mall MMP  supports describing offered apps in business view that is pre-linked to the technical descriptions needed for service execution, and service governance is de ﬁ ned. Technical descriptions like WSDLs and XSD data type speci ﬁ cations are used, but they are not comprehensible to business process designers having no or only limited IT skills and are therefore hidden from them. • Look-Ahead: Usually, service descriptions and service operations are published in a repository (SOA repository or LDAP in our case). To enable look-ahead, a service should be described in a language (or graphical notation) easily understandable to business process designers , as described above. Fur- thermore, it must be easy to search for needed services and to access and understand related descriptions. Based on this, business process designers can ﬁ nd appropriate services and use them in corresponding process steps. Existing technical service speci ﬁ cations are pre-linked with these business level speci- ﬁ cations to avoid unnecessary implementation steps. Reuse of existing services reduces efforts and costs for service implementation or service renting. As a disadvantage, adjustments of the de ﬁ ned process logic to the available service set might become necessary.
Above all, this book emphasizes problem solving through cloudcomputing. At times you might face a simple problem and need to know only a simple trick. Other times you might be on the wrong track and need some background information to get oriented. Still other times, you might face a bigger problem and need direction and a plan. You will find all of these in this book. We provide a short description of the overall structure of a cloud here, to give the reader an intuitive feel for what a cloud is. Most readers will have some experience with virtualization. Using virtualization tools, you can create a virtual machine with the operating system install soft- ware, make your own customizations to the virtual machine, use it to do some work, save a snap- shot to a CD, and then shut down the virtual machine. An Infrastructure as a Service (IaaS) cloud takes this to another level and offers additional convenience and capability.
There’s growing sentiment among many cloud experts that ultimately hybrid adoption will be most ad- vantageous for many organizations. Warrilow says “for some time Gartner has advised that hybrid is the most likely scenario for most organiza- tions.” Staten agrees with the notion for two reasons. First, “some appli- cations and data sets simply aren’t a good fit with the cloud,” he says. This might be due to application architec- ture, degree of business risk (real or perceived), and cost, he says. Second, rather than making a cloud-or-no- cloud decision, “it’s more practical and effective to leverage the cloud for what makes the most sense and other deployment options where they make the most sense,” he says. In terms of strategy, Staten recommends regularly analyzing deployment decisions. “As cloud services mature, their applica- bility increases,” he says.
A common option for reducing the operating costs of only sporadically used IT infra- structure, such as in the case of the “warm standby” , is CloudComputing. As defined by NIST , CloudComputing provides the user with a simple, direct access to a pool of configurable, elastic computing resources (e.g. networks, servers, storage, applications, and other services, with a pay-per-use pricing model). More specifically, this means that resources can be quickly (de-)provisioned by the user with minimal provider interaction and are also billed on the basis of actual consumption. This pric- ing model makes CloudComputing a well-suited platform for hosting a replication site offering high availability at a reasonable price. Such a warm standby system with infrastructure resources (virtual machines, images, etc.) being located and updated in the Cloud is herein referred to as a “Cloud-Standby-System”. The relevance and po- tential of this cloud-based option for hosting replication systems gets even more ob- vious in the light of the current situation in the market. Only fifty percent of small and medium enterprises currently practice BCM with regard to their IT-services while downtime costs sum up to $12,500-23,000 per day for them .
The Heartbeat Service periodically collects the dynamic performance information about the node and publishes this information to the membership service in the Aneka Cloud. These data are collected by the index node of the Cloud, which makes them available for services such as reserva- tions and scheduling in order to optimize the use of a heterogeneous infrastructure. As already dis- cussed, basic information about memory, disk space, CPU, and operating system is collected. Moreover, additional data are pulled into the “alive” message, such as information about the installed software in the system and any other useful information. More precisely, the infrastructure has been designed to carry over any type of data that can be expressed by means of text-valued properties. As previously noted, the information published by the Heartbeat Service is mostly con- cerned with the properties of the node. A specific component, called Node Resolver, is in charge of collecting these data and making them available to the Heartbeat Service. Aneka provides different implementations for such component in order to cover a wide variety of hosting environments. A variety of operating systems are supported with different implementations of the PAL, and differ- ent node resolvers allow Aneka to capture other types of data that do not strictly depend on the hosting operating system. For example, the retrieval of the public IP of the node is different in the case of physical machines or virtual instances hosted in the infrastructure of an IaaS provider such as EC2 or GoGrid. In virtual deployment, a different node resolver is used so that all other compo- nents of the system can work transparently.
technology enables a vendor’s cloud software to automatically move data from a piece of hardware that goes bad or is pulled offline to a section of the system or hardware that is functioning or operational. Therefore, the client gets seam- less access to the data. Separate backup systems, with cloud disaster recov- ery strategies, provide another layer of dependability and reliability. Finally, cloudcomputing also promotes a green alternative to paper-intensive office functions. It is because it needs less computing hardware on premise, and all computing-related tasks take place remotely with minimal computing hard- ware requirement with the help of technological innovations such as virtual- ization and multitenancy. Another viewpoint on the green aspect is that cloudcomputing can reduce the environmental impact of building, shipping, hous- ing, and ultimately destroying (or recycling) computer equipment as no one is going to own many such systems in their premises and managing the offices with fewer computers that consume less energy comparatively. A consolidated set of points briefing the benefits of cloudcomputing can be as follows: 1. Achieve economies of scale: We can increase the volume output or pro-
Bob Evans, senior vice president at Oracle, further wrote some revealing facts in his blog post at Forbes, clearing away all doubts people may have had in their minds. You may like to consider some interesting facts in this regard. Almost eight years ago, when cloud terms were not yet established, Oracle started developing a new generation of application suites (called Fusion Applications) designed for all modes of cloud deployment. Oracle Database 12c, which was released just recently, supports the cloud deployment framework of major data centers today and is the outcome of development efforts of the past few years. Oracle’s software as a service (SaaS) revenue has already exceeded the $1 billion mark, and it is the only company today to offer all levels of cloud services, such as SaaS, platform as a service (PaaS), and infrastructure as a service (IaaS). Oracle has helped over 10,000 customers to reap the beneﬁts of the cloud infrastructure and now supports over 25,000 users globally. One may argue that this could not have been possible if Larry Ellison hadn’t appreciated cloudcomputing. Sure, we may understand the dilemma he must have faced as an innovator when these emerging technologies were creating disruption in the business (www.forbes.com/sites/oracle/2013/01/18/oracle-cloud-10000- customers-and-25-million-users/).
Apart from the vendor-specific migration methodologies and guidelines, there are also proposals independent from a specific cloud provider. Reddy and Kumar proposed a methodology for data migration that consists of the following phases: design, extraction, cleansing, import, and verification. Moreover, they categorized data migration into storage migration, database migration, application migration, business process migration, and digital data retention (Reddy and Kumar, 2011). In our proposal, we focus on the storage and database migration as we address the database layer. Morris specifies four golden rules of data migration with the conclusion that the IT staff does not often know about the semantics of the data to be migrated, which causes a lot of overhead effort (Morris, 2012). With our proposal of a step-by-step methodology, we provide detailed guidance and recom- mendations on both data migration and required application refactoring to minimize this overhead. Tran et al. adapted the function point method to estimate the costs of cloud migration projects and classified the applications potentially migrated to the cloud (Tran et al., 2011). As our assumption is that the decision to migrate to the cloud has already been taken, we do not con- sider aspects such as costs. We abstract from the classification of applications to define the cloud data migration scenarios and reuse distinctions, such as complete or partial migration to refine a chosen migration scenario.
One of the critical questions for channel companies to answer is whether or not cloud makes sense from an ROI perspective and if so, in what capacity and in which customer scenarios. This basic “economics of the cloud” discussion has been front-‐and-‐center in the channel for the better part of the last three to five years. The conversation is complicated, due in large part to the wide variety of cloud business model options and potential revenue structures to explore as well as differing customer needs. And yet, we are seeing solution providers move more decisively. Nearly 6 in 10 said they proactively pursued multiple segments of the various cloud business models in an attempt to quickly and comprehensively enter the cloud market, with medium and larger firms more likely to have gone this route than the smallest channel player (see Section 3 of this report for a detailed discussion of business models). As a result, a segment of companies have assembled quantifiable tracking metrics on revenue and profit margin, which can serve as a guidepost for channel companies moving more slowly into cloud.
Abstract Organisations and enterprise fi rms, from banks to social Web, are consid- ering developing and deploying applications on the cloud due to the benefi ts offered by them. These benefi ts include cost effectiveness, scalability and theoretically unlimited computing resources. Many predictions by experts have indicated that centralising the computation and storage by renting them from third-party provider is the way to the future. However, before jumping into conclusions, engineers and technology offi cers must assess and weigh the advantages of cloud applications over concerns, challenges and limitations of cloud-based applications. Decisions must also involve choosing the right service model and knowing the disadvantages and limitations pertaining to that particular service model. Although cloud applica- tions have benefi ts a galore, organisations and developers have raised concerns over the security and reliability issues. The idea of handing important data over to another company certainly has security and confi dentiality worries. The implica- tion does not infer that cloud applications are insecure and fl awed but conveys that they require more attention to cloud-related issues than the conventional on-premise approaches. The objective of this chapter is to introduce the reader to the chal- lenges of cloud application development and to present ways in which these chal- lenges can be overcome. The chapter also discusses the issues with respect to different service models and extends the challenges with reference to application developer ’ s perspective.
“Clouds are about ecosystems, about large collections of interacting services including partners and third parties, about inter-cloud communication and sharing of information through such semantic frameworks as social graphs.” Transformationvsutility This, he adds, is clearly business transformational, whereas “computing services that are delivered as a utility from a remote data centre” are not. The pioneers in VANS/EDI methods – which are now migrating into modern cloud systems in offerings from software ﬁrm SAP and its partners, for example – were able to set up basic trading data exchange networks, but the cloud transformation now is integrating, in real-time, the procurement, catalogue, invoicing and other systems across possibly overlapping and much wider business communities.
Starting in 1958 the agency, then known as ARPA, was responsible for carrying out research and development on projects at the cutting edge of science and technology. While these typically dealt with national security–related matters, the agency never felt bound by military projects alone. One outcome of this view was significant work on general information technology and computer systems, starting with pioneering research on what was called time-sharing. The first computers worked on a one user–one system principle, but because individuals use computers intermittently, this wasted resources. Research on batch processing helped to make computers more efficient because it permitted jobs to queue up over time and thereby shrunk nonusage time. Time-sharing expanded this by enabling multiple users to work on the same system at the same time. DARPA kick-started time-sharing with a grant to fund an MIT-based project that, under the leadership of J. C. R. Licklider, brought together people from Bell Labs, General Electric, and MIT (Waldrop 2002). With time-sharing was born the principle of one system serving multiple users, one of the foundations of cloudcomputing. The thirty or so companies that sold access to time-sharing computers, including such big names as IBM and General Electric, thrived in the 1960s and 1970s. The primary operating system for time-sharing was Multics (for Multiplexed Information and Computing Service), which was designed to operate as a computer utility modeled after telephone and electrical utilities. Specifically, hardware and software were organized in modules so that the system could grow by adding more of each required resource, such as core memory and disk storage. This model for what we now call scalability would return in a far more sophisticated form with the birth of the cloud- computing concept in the 1990s, and then with the arrival of cloud systems in the next decade. One of the key similarities, albeit at a more primitive level, between time-sharing systems and cloudcomputing is that they both offer complete operating environments to users. Time-sharing systems typically included several programming-language processors, software packages, bulk printing, and storage for files on- and offline. Users typically rented terminals and paid fees for connect time, for CPU (central processing unit) time, and for disk storage. The growth of the microprocessor and then the personal computer led to the end of time-sharing as a profitable business because these devices increasingly substituted, far more conveniently, for the work performed by companies that sold access to mainframe computers.
When working at scale, as you are likely to do with a private cloud implementation, strongly consider standardization of your server hardware models and purchasing groups of serv- ers together. Not only does this approach guarantee you’ll have compatible CPU generations and identical hardware, it makes your deployment process simpler. You can use tools like Autodeploy and host profi les to deploy and redeploy your servers. Likewise, using DHCP rather than static IP addressing schemes for vSphere servers becomes more appealing. vSphere 5.1 with Autodeploy also allows you to deploy stateless vSphere hosts, where each node is booted from the network using a Trivial File Transfer Protocol (TFTP) server. The host downloads the vSphere hypervisor at boot-time and runs it in RAM; then it downloads its confi guration from the Autodeploy server.
In 1997, Professor Ramnath Chellappa of Emory University, defined cloudcomputing for the first time while a faculty member at the University of South California, as an important new “computing paradigm where the boundaries of computing will be determined by economic rationale rather than technical limits alone.” Even though the international IT literature and media have come forward since then with a large number of definitions, models and architectures for cloudcomputing, autonomic and utility computing were the foundations of what the community commonly referred to as “cloudcomputing”. In the early 2000s, companies started rapidly adopting this concept upon the realization that cloudcomputing could benefit both the Providers as well as the Consumers of services. Businesses started delivering computing functionality via the Internet, enterprise- level applications, web-based retail services, document-sharing capabilities and fully-hosted IT platforms, to mention only a few cloudcomputing use cases of the 2000s. The latest widespread adoption of virtualization and of service- oriented architecture (SOA) promulgated cloudcomputing as a fundamental and increasingly important part of any delivery and critical-mission strategy, enabling existing and new products and services to be offered and consumed more efficiently, conveniently and securely. Not surprisingly, cloudcomputing became one of the hottest trends in the IT armory, with a unique and complementary set of properties, such as elasticity, resiliency, rapid provisioning, and multi-tenancy.
It is foreseen that cloudcomputing could become a disruptive technology for mobile multimedia applications and services . In order to meet mul- timedia’s QoS requirements in cloudcomputing for multimedia services over the Internet and mobile wireless networks, Zhu et al.  proposed a multimedia cloudcomputing framework that leverages cloudcomputing to provide multimedia applications and services over the Internet. The prin- cipal conceptual architecture is shown in Figure 1.5. Zhu et al. addressed multimedia cloudcomputing from multimedia-aware cloud (media cloud) and cloud-aware multimedia (cloud media) perspectives. The media cloud (Figure 1.5a) focuses on how a cloud can perform distributed multimedia processing and storage and QoS provisioning for multimedia services. In a media cloud, the storage, CPU, and GPU are presented at the edge (i.e., MEC) to provide distributed parallel processing and QoS adaptation for various types of devices. The MEC stores, processes, and transmits media data at the edge, thus achieving a shorter delay. In this way, the media cloud, composed of MECs, can be managed in a centralized or peer-to-peer (P2P) manner. The cloud media (Figure 1.5b) focuses on how multimedia ser- vices and applications, such as storage and sharing, authoring and mashup, adaptation and delivery, and rendering and retrieval, can optimally utilize cloudcomputing resources to achieve better quality of experience (QoE). As depicted in Figure 1.5b, the media cloud provides raw resources, such as hard disk, CPU, and GPU, rented by the media service providers (MSPs) to serve users. MSPs use media cloud resources to develop their multime- dia applications and services, for example, storage, editing, streaming, and delivery.
In simple language, mobile commerce is the mobile version of e-commerce. Each and every utility of e-commerce is possible through mobile devices using the computa- tion and storage in the cloud. According to Wu and Wang , mobile commerce is “the delivery of electronic commerce capabilities directly into the consumer’s hand, anywhere, via wireless technology.” There are plenty of examples of mobile com- merce, such as mobile transaction and payment, mobile messaging and ticketing, mobile advertising and shopping, and so on. Wu and Wang  further report that 29% of mobile users have purchased through their mobiles 40% of Walmart products in 2013, and $67.1 billion purchases will be made from mobile device in the United States and Europe in 2015. This statistics proves the massive growth of m-commerce. In m- commerce, the user’s privacy and data integrity are vital issues. Hackers are always trying to get secure information such as credit card details, bank account details, and so on. To protect the users from these threats, public key infrastructure (PKI) can be used. In PKI, an encryption-based access control and an over-encryption are used to secure the privacy of user’s access to the outsourced data. To enhance the customer sat- isfaction level, customer intimacy, and cost competitiveness in a secure environment, an MCC-based 4PL-AVE trading platform is proposed in Dinh et al. .
Cloudcomputing can carry out large-scale data calculation and can highly integrate the logistics industry resources, which plays a strong role in promoting the level of informationalization and is conducive to the transformation and development of the logistics industry. Due to these advantages, cloudcomputing technology is widely applied in the informationalization process of cold chain logistics. But from a practical point of view, the penetration of the cloudcomputing technology is not widespread enough, so that it has not yet been fully penetrated and applied. There will be a long- term period of practice before the penetration and application is fully realized. Therefore, in order to promote the development of logistics industry (including cold chain logistics) and further improve the level of industry informatization, it is also needed to enhance the penetration and application as well as the practical study of cloudcomputing technology in the process of logistics industry informatization.
The next layer within ITaaS is Platform as a Service, or PaaS. At the PaaS level, what the service providers offer is packaged IT capability, or some logical resources, such as databases, ﬁle systems, and application operating environment. Currently, actual cases in the industry include Rational Developer Cloud of IBM, Azure of Microsoft and AppEngine of Google. At this level, two core technolo- gies are involved. The ﬁrst is software development, testing and running based on cloud. PaaS service is software developer-oriented. It used to be a huge difﬁculty for developers to write programs via network in a distributed computing environ- ment, and now due to the improvement of network bandwidth, two technologies can solve this problem: the ﬁrst is online development tools. Developers can directly complete remote development and application through browser and remote console (development tools run in the console) technologies without local installation of development tools. Another is integration technology of local development tools and cloudcomputing, which means to deploy the developed application directly into cloudcomputing environment through local development tools. The second core technology is large-scale distributed application operating environment. It refers to scalable application middleware, database and ﬁle system built with a large amount of servers. This application operating environment enables appli- cation to make full use of abundant computing and storage resource in cloudcomputing center to achieve full extension, go beyond the resource limitation of single physical hardware, and meet the access requirements of millions of Internet users.
Data transfer performance is a critical factor when considering the deployment of a data-intensive processing pipeline on a distributed topology. In fact, an important part of the DESDynI pre-mission studies consisted in using the deployed array of cloud servers to evaluate available data transfer technologies, both in terms of speed and easiness of installation and confi guration options. Several data transfer toolkits were compared: FTP (most popular, used as performance baseline), SCP (ubiquitous, built- in SSH security, potential encryption overhead), GridFTP (parallelized TCP/IP, strong security, but complex installation and confi guration), bbFTP (parallelized TCP/IP, easy installation, standalone client/server), and UDT (reliable UDP-based bursting technology). Benchmarking was accomplished by transferring NetCDF fi les (a highly compressed format commonly used in Earth sciences) of two representative sizes (1 and 10 GB) between JPL, two cloud servers in the AWS-West region, and one cloud server in the AWS-East region. The result was that UDT and GridFTP offered the overall best performance across transfer routes and fi le sizes: UDT was slightly faster and easier to confi gure than GridFTP, but it lacked the security features (authen- tication, encryption, confi dentiality, and data integrity) offered by GridFTP. It was also noticed that the measured transferred times varied considerably when repeated for the same fi le size and transfer end points, most likely because of concurrent use of network and hardware resources by other projects hosted on the same cloud. Additionally, using the Amazon internal network, when transferring data between servers on the same AWS-West region consistently, yielded much better performance than when using the publicly available network between the same servers.