Mobile- und Cloud-Computing unter besonderer Betrachtung der Technologien der US amerikanischen Unternehmenen Google Inc. und Amazon.com Inc. und der deutschen SAP AG

Mobile- und Cloud-Computing unter besonderer Betrachtung der Technologien der US‑amerikanischen Unternehmen Google Inc. und Amazon.com Inc. und der deutschen SAP AG
--
Mobile- and Cloud-Computing with special regard to technologies of the American companies Google Inc. and Amazon.com Inc. and the German SAP AG

Download Book (PDF)
Publisher: BookBoon, ISBN 978-87-403-0264-6, 129 Pages

In dieser Projektarbeit werden die Themen Mobile-und Cloud-Computing unter spezieller Berücksichtigung der Technologien der Unternehmen Google Inc., im folgenden Google genannt, Amazon.com Inc., im folgenden Amazon genannt, und der SAP AG, im folgenden SAP genannt, evaluiert. Diese Evaluierung soll einem Unternehmen als Blueprint dienen, um so die Unternehmensprozesse mit den genannten Technologien umsetzen zu können. Das Unternehmen erhofft sich dadurch eine Effizenzsteigerung durch Automatisierung, Flexibilisierung, Skalierung und Benutzerfreundlichkeit. Der Autor verbindet in dieser Arbeit verschiedenste Technologien und gibt subjektive Empfehlungen für die Nutzung der jeweiligen Technologie ab. Die Themen Mobile Computing und Cloud Computing werden zunächst seperat dargestellt. Im Anschluss zeigt Kapitel 4 wie beide Welten zusammenwirken und welche Rolle etablierte Technologien spielen. Zudem wird auf das aktuelle Thema In-Memory Computing eingegangen und dargestellt wie es sich in das Mobile- und Cloud-Computing Ökosystem eingliedert.

This project assignment evaluates and presents the topics Mobile- and Cloud-Computing with special regard to the technologies of the companies Google Inc. (Google), Amazon.com Inc. (Amazon) and SAP AG (SAP). The evaluation should serve as a blueprint for a company to implement business processes with the mentioned technologies. By using these technologies the company tries to increase its efficiency via automation, flexibilisation, scaling and usability. The author of this paper combines different technologies and gives subjective advices regarding the use of a particular technology. First the topics Mobile Computing and Cloud Computing will be shown separately. Afterwards chapter 4 will show how both technologies interoperate and the meaning of legacy technologies. Furthermore, In-Memory Computing will be explained and how it fits in the ecosystem of Mobile- and Cloud-Computing.

Content:
Mobile Computing, Cloud Computing, In-Memory Computing, Google, Amazon, SAP, Android, iOS, BlackBerry BBX, NFC, LBS, Adobe, Flash, Flex, Windows Phone 7, WP7, Sybase, SUP, Sybase Unwired Platform, SAP NetWeaver Gateway, SAP NetWeaver Mobile, SAP ITSmobile, Mobile-WebApp, Hybrid-NativeApp, Purely-NativeApp, HTML5, JavaScript, CSS3, Dart, Coffeescript, jQueryMobile, jQM, jqMobi, jQTouch, sencha touch, iUI, iWebKit, Dojo Mobile, Jo, iScroll, Ajax, Comet, Streaming, Long-Polling, XHR, XHR2, Polling, Piggyback-Polling, WebSocket, Socket.IO, Athmosphere, CometD, Kaazing, Kaazing WebSocket Gateway, Native Frameworks, Briding Frameworks, PhoneGap, Titanium, Rhodes, IaaS, PaaS, DaaS, SaaS, FaaS, HuaaS, MoaaS, Virtualisierung, Skalierung, Scale-out, Scale-up, SOA, SOAP, REST, Messaging, SQS, SNS, AMQP, JMS, RabbitMQ, Qpid, ActiveMQ, HornetQ, CAP, ACID, BASE, Map, Reduce, BigTable, Dynamo, Wide-Column-Store, Row-oriented, Column-oriented, Key-Value-Store, Graph-Store, Document-Store, CouchDB, MongoDB, HBase, Cassandra, SimpleDB, Redis, Riak, Neo4J, Replizierung, Big Data, Schema-free, Sharding, MVCC, Consistent-Hashing, EC2, EBS, S3, ElastiCache, RDS, Cloud Front, Elastic Beanstalk, Cloud SQL, Cloud Storage, C2DM, App Engine, GAE, Page Speed Service, Akamai, River, OpenShift, NetSuite, Salesforce.com, Cloud Foundry, CloudBees, Heroku, Oracle Cloud Service, Oracle Public Cloud, Database Cloud Service, Java, Scala, Ceylon, Kotlin, Groovy, JSON, NoSQL, Node.js, Node, Asynchron, Event-Driven, Non-Blocking, NIO, Event-Loop, Nginx, Android-Couchbase, 2-Tier, 3-Tier, Java EE 5, Java EE 6, JSF, Ruby on Rails, Wicket, GWT, SanssouciDB, SAP HANA, OLTP, OLAP, IMDB

Big thanks to all the proof readers!
Your feedback is welcome!

JSF 2.0 AJAX overview

Many AJAX JSF frameworks are on the market - but the moment you start combining them you may get random results due to incompatibilities. JSF 2.0 will help with this! Specifying the AJAX API will help assemble the different approaches under one roof. The spec (JSR-314) defines an f:ajax tag as well as a javscript API together with an AJAX enhanced JSF lifecycle.

I helped implement one of the numerous AJAX JSF approaches for years (the fry:ajax tag from J4Fry) and during the last months this approach was integrated into Apache MyFaces 2.0 while adapting it's interfaces to the new spec. The spec covers a lot of the basic features in a generic and flexible way. Btw.: MyFaces 2.0 is on its way, we're currently gluing everything together and I'm hoping for an alpha by end of august.

The most basic part of an AJAX implementation is replacing parts of the document. These are the features the JSF 2.0 API provides:

• execute - The components that will be processed on the server in a blank separated list. Only the components named within this parameter get their decode, validate and updateModel methods called during phase 2-4. There is an @all keyword you can use to process the entire component tree.
• render - The components that will be rendered and replaced within the HTML page in a blank separated list.
• onevent - A JS callback that is triggered with three different events:
  • begin - occurs immediately before the request is sent
    
  • complete - occurs after the AJAX request has completed but before DOM manipulation has taken place
    
  • success - occurs after DOM manipulation has taken place (only for successfull request, else see onerror)
• onerror - A JS callback that is triggered when the server signalizes that an error has occured.
• params - An object that may include additional parameters to include in the request.

There have been discussions on both the MyFaces and Mojarra mailing lists on the nature of the ids in the execute and render parameters. Are they HTML ids or component ids? Here's the truth: The f:ajax tag can take either component ids that resolve relative to the nearest naming container or HTML ids. There is an algorithm that tries both. The procedural interface jsf.ajax.request(source, event, {execute: ..., render: ...}) requires HTML ids. The f:ajax tag will resolve the component and generate a behaviour that is in fact a call to jsf.ajax.request.

f:ajax provides three more attributes that offer JSF specific enhancements:

• disabled - Indicates whether the AJAX behavior script should not be rendered.
• listener - A method binding to execute when the AJAX request is processed on the server.
• immediate - same as the attribute you know from the standard JSF action sources.

For Tomahawk 2.0 we are preparing a t:ajax tag that will include a bunch of extra options. Implementation will happen in J4Fry JSF 2.0 with a fry:ajax tag (targeted for end of juli) which will be repackaged for Tomahawk 2.0 when it is ready. This is the list of extra options we want to support:

• timout - How long to wait for the HTTP response before aborting the request.
• delay - How long to wait before issuing a request (helpfull with onkeyup or mouse move events to avoid tons of requests).
• queuesize - Number of requests to queue (discard the oldest when the queue is full and a new one arrives).
• partial submit - The current spec requires submission of the entire form though only the elements named in the execute parameter are being processed. Setting partial submit (or pps) to true could reduce the submit volume to the actually processed values.
• disable - HTML id's of the components to disable while the request is running (can be implemented via onevent).
• loadingbar - HTML id of an img tag to make visible while the request is running (can also be implemented via onevent).
• errorhandling for errors that occur within the javascript - can be done with the onerror parameter, but the spec doesn't mention this use.

Just in case you've made it up to here (which would only happen if you are really deep into JSF and AJAX technology) you will be keen to know whether JSF 2.0 AJAX will do an auto eval on incoming scripts. If you rerender a portion of your markup that contains a script then auto eval will execute the newly arrived scripts. The spec doesn't mention this issue, Mojarra 2.0 (in it's current beta state) doesn't do auto eval but MyFaces 2.0 will.