Agile Cat — in the cloud

モバイル BaaS って何だ? Appcelerator による Cocoafish 買収から探ってみよう

Posted in .Selected, Apple, BaaS, Google, Microsoft, Mobile, Post-PC by Agile Cat on February 17, 2012

Appcelerator buys mobile backend provider Cocoafish
http://wp.me/pwo1E-3Vx
By
Ryan Kim Feb. 9, 2012
http://gigaom.com/mobile/appcelerator-gobbles-up-mobile-backend-provider-cocoafish/

_ Gigaom

Appcelerator, which helps developers build native and HTML5 mobile apps, has been on an acquisition tear in the past year and has added mobile backend provider Cocoafish on Thursday to fill out its offering. The pickup, which follows Appcelerator’s purchase of Aptana and Particle Code last year, gives the company a robust cloud infrastructure provider and helps it appeal even more to its 1.6 million developers. Terms of the deal were not disclosed.

Appcelerator は、HTML5 対応のネイティブ・モバイル・アプリケーションを開発する、デベロッパーたちをサポートしている。そして、これまでの 1年間は企業買収のステージにあり、木曜日(2/9)にはモバイル・バックエンド・プロバイダである Cocoafish を、ラインナップに加える手続きを完了した。 この Appcelerator が進める買収は、昨年の Aptana と Particle Code に続くものであり、同社のクラウド・インフラストラクチャ・プロバイダを強化し、また、その 160万人のデベロッパーにアピールするものとなった。 ただし、その取引の内容は発表されていない。 

クリックで拡大 ⇒

Cocoafish, founded in 2010 in San Francisco by Michael Goff and Wei Kong, is part of an emerging class of mobile backend providers that includes Stackmob, Parse, Kinvey and others that are helping developers add cloud-based features to their apps. Cocoafish services such as push notifications, social integration, sharing, location and others will be integrated into the Titanium Platform by early in the second quarter. Appcelerator said it will also offer iOS, Android, JavaScript and REST SDKs so that these services can be accessed by all mobile app developers, regardless of what technologies they use, such as Objective-C, Java, PhoneGap, Sencha and HTML5.

Cocoafish は Michael Goff と Wei Kong により、2010年に San Francisco で設立された。同社は、Stackmob や、Parse、Kinvey などで構成される、新興モバイル・バックエンド・プロバイダの一角であり、アプリケーションにクラウド・ベースの機能を加えるデベロッパーたちを支援してきた。Cocoafish が提供する、プッシュ通知/ソーシャル統合/共有/ロケーションといったサービスは、今年の Q2 早々に、Titanium Platform に統合されるだろう。 Appcelerator の発言によると、iOS/Android/JavaScript/REST の SDK を提供することで、Objective-C /Java/PhoneGap/Sencha/HTML5 といったテクノロジーを用いる、すべてのモバイル・アプリケーション・デベロッパーが、それれらのサービスにアクセスできるようになる。

Why the acquisition makes sense

Appcelerator’s acquisition of Cocoafish is logical, as it looks to become the go-to resource for developers and companies building cross-platform apps. In its latest developer survey, Appcelerator found that 84 percent of its developers connected to cloud-based services. But almost all of them were manually adding these services themselves. That can double the time it takes to launch an app.

クロス・プラットフォーム・アプリケーションを構築するデベロッパーと企業のための、主力のリソースを目指す上で、Appcelerator による Cocoafish 買収は論理的なものとなる。 デベロッパーに対する最近の調査で、その 84 % がクラウド・ベースのサービスに接続していることに、Appcelerator は注目している。 そして、その大半が手作業により、それらのサービスを加えていることも分かった。 つまり、アプリケーションの立ち上げまでに費やす時間が、2倍になっていた可能性がある。

Now Appcelerator can offer a full suite of front-end and backend solutions for developers with Cocoafish integrated into Appcelerator’s Titanium Studio. And by opening iOS, Android, JavaScript and REST SDKs, it means that Appcelerator could also appeal to developers who don’t use its Titanium Platform. That can drum up even more business, though it pits Appcelerator against a number of competitors in the mobile development services market. But it looks like there is still a lot of business to be had. Kinvey did a survey of apps on iOS and Android in September and found that 73 percent didn’t connect to a backend.

しかし、いまでは、 Cocoafish を Appcelerator の Titanium Studio に統合することで、デベロッパーに対してフロントエンドとバックエンドの、完全なソリューション・スイートを提供できる。 そして、iOS/Android/JavaScript/REST の SDK をオープンにすることで、Titanium Platform を使っていなかったデベロッパーに対しても、Appcelerator はアピールできるようになった。それにより、さらに多くのビジネス機会が生じるが、モバイル・サービス市場における数多くのコンペティタと、Appcelerator は戦っていくことになる。 ただし、そこには、まだまだ沢山のビジネス・チャンスがあるようだ。 昨年の 9月に Kinvey が行った、iOS と Android のアプリケーションに関する調査では、73% がバックエンドに接続していない状況が明らかになっている。

クリックで拡大 ⇒

Connecting apps to cloud services can still be tough, but it usually provides more engaging features. That is increasingly important for app developers, who need to create more-dynamic apps that keep users involved. User engagement and attention is the name of the game in the mobile app world, in which users are quick to try then discard apps. The purchase of Cocoafish also raises the question of whether we will see more consolidation in this nascent market as potentially other Platform-as-a-Service offerings or other companies look to add mobile support. For Appcelerator, which raised $15 million in November, it is another sign of momentum as it capitalizes on the boom in mobile apps.

アプリケーションとクラウド・サービスとの接続は、依然として困難を伴うこともあるが、通常では、その引き替えとして、さらに魅力的な機能を提供できるようになる。 ダイナミックなアプリケーションを開発し、ユーザーを惹きつけるべきアプリケーション・デベロッパーにとって、それらの魅力的な機能に対する重要度が増している。 アプリケーションの試用と削除が簡単なモバイル・アプリケーションの世界では、ユーザーの注目を引き留めておくことが、きわめて重要なポイントとなる。 そして、Cocoafish の買収により、さらなる垂直統合が発生するかもしれない。 つまり、この黎明期のマーケットにおいて、これまでとは別種の PaaS が提供される可能性や、新規参入の可能性が生じるとも考えられる。 そこに、11月に $15 million の資金を集めた Appcelerator が、勢いに乗ってモバイル・アプリ・ブームをフル活用する、もう 1つの理由がある。

Curious about how the backend-as-a-service market fits into the larger mobile market? Take a look at this helpful chart worked up by Kinvey.

この BaaS(Bbackend-as-a-Service)マーケットが、どのようにして大規模モバイル・マーケットにフィットするのか、知りたいだろう? Kinvey が段階的に仕上げてきた、このチャートを確認して欲しい。 とても有用だと思う。

Related research and analysis from GigaOM Pro:

ーーーーー

TAG index最初は、このインフォグラフが気になって、注目し始めたポストですが、記事の内容もとても興味深いものでした。iOS や Android や Win Phone などにおいて、それぞれのアプリケーションが、プッシュ通知/ソーシャル統合/共有/ロケーションといったサービスを必要とするはずです。 それなら Mobile BaaS(Bbackend-as-a-Service)で、まとめて面倒みましょうというのが、この Appcelerator や Cocoafish のコンセプトなんですね。 そして、このインフォグラフですが、パックマンまで友情出演していて、ほんとうに面白いです。 どれくらう面白いかというと、1920 x 1200 まで引っ張って、壁紙にしてしまったくらいです :) ーーー ac-stamp-25

ーーーーー

<関連>

ついに Apple は iPhone 単独で、Microsoft の全てを追い抜いてしまった!
Android アプリが 40万 タイトルに到達した!
Ray Ozzie が帰ってきた! iOS と Android を引き連れて
10億台の HTML5 フォンが、モバイル・アプリ・ビジネスを変えていく
最適な MDM(Mobile Device Management)ポリシーを構成するためには?
Carbyn の HTML5 OS は、未来を見せてくれるのか?
コンシューマ と エンタープライズ の、IT 交差点 は存在し得るのか?

Azure での Java サポートは、どうなっている?

Posted in Interoperability, Microsoft by Agile Cat on April 17, 2009

What is Microsoft doing to add Java support to Azure?
All about Microsoft より
April 13th, 2009
Posted by Mary Jo Foley @ 1:57 pm

From <http://blogs.zdnet.com/microsoft/>

Google App Engine クラウド・プラットフォームに取り組むデベロッパーに、Java の開発環境が提供されるという。この Google の発表に対する、Microsoft の反応に興味があった。しかし、その答えは結局のところ、同じことの繰り返しだった。

Google は Java をサポートするという計画の発表から、実際に約束を果たすまでに 1年を要した。 しかし Microsoft は、現時点において Java for Cloud を提供していないし、出荷に関する約束もしていない。 (Amazon の EC2 クラウド・インフラストラクチャにおいても、Java でアプリケーションをホスティングする開発者に対して、新しいツールが提供されている)

2008年10月に Azure クラウド・プラットフォームを始動したときから、Microsoft が言い続けてきている最終的なプランとは、各種言語による Azure の記述を、デベロッパーに対して提供することである。 たとえば、FastCGI のサポートに関するコミットメントなどを介して、その点が繰り返して強調されている。

しかし、今のところ、Java ベースのクラウド・サービスと、Azure サービスの相互運用という範囲において、Microsoft は Azure 上の Java をサポートしているだけである。 同社のスポークスマンは、以下のように述べている:

「Azure Services Platform はオープンであり、スタンダード・ベースであり、インターオペラブルである。他のプラットフォームやサービスとの相互運用のために、 Azure サービスは REST や SOAP といった Web スタンダードを使用している。 Java で記述されたアプリケーションとサービスは、クラウド・コンピューティングのための、このうようなオープンでスタンダードなアプローチをベースにして、Azure サービスとの相互作用を実現する。現時点において、Windows Azure の FastCGI 機能は、そのコンピューティング・インフラストラクチャ上での、PHP やサードパーティプログラミング言語の利用を実現している。 Windows Azure のビジョンは、Java も含めて、 Windows 上で実行される、すべての言葉をサポートすることである」

MIX 09 において、Java Software Development Kit (SDK)に関するプランが注目されたが、そこで説明されたものは Microsoft と Schakra による共同開発であった。 Microsoft が提供するのは資金および、アーキテクチャとテクニカルのガイダンス、そしてプロジェクト調整である。つまり、開発とEnd-to- End のテストは、Schakra が行うことになる。

4月10日に、Java SDK for .Net Services は Milestone 2 に到達したが、この新しいテスト・ビルドは、March 2009 .Net Services Community Technology Preview (CTP) テスト・ビルドとの互換性を維持している。JDotNetServices.com サイトによれば、このプロジェクトにおける Summer 2009 Community Technology Preview for the Java SDK が、次に仕上がってくる。 この SDK テスト・ビルドは、BSD ライセンスの下で利用でき、SourceForge サイトからダウンロードできる。

Java インターオペラビリティに関する、Microsoft の約束は、これで充分なのだろうか? そして、Microsoft Azure クラウドでダイレクトにホストされた Java で、アプリケーションを記述する Azure アーリー・アダプターは出てくるのだろうか?

Tagged with: , , , ,

SOAP と REST、補完か競合か?

Posted in David Chappell by Agile Cat on April 10, 2009

SOAP .vs REST : Complements or Competitors?
David Chappell’s Blog より
Tuesday, April 07, 2009
http://www.davidchappell.com/blog/2009/04/soap-vs-rest-complements-or-competitors.html

David 09_03_16

これは、ESRI という Geographic Information Systems (GIS) ベンダーのためのセッション・コンテンツですが、どのように SOAP と REST を使い分けるべきかという、共通の問題に答えてくれます。 資料として提供されるスライドから、一部を抜粋して載せますが、ぜひ、全体を参照してください。 とても、お勧めです。

まずは、機能を比較してみましょう、というページです(↓)

SOAP-REST-1

YAGNI(You Aren’t Going to Need It)とは、「今必要のあることだけをやれ」という意味。eXtreme Programming のシンプルな設計における原則とのこと(↓)

SOAP-REST-2 

それだけに、信頼性についても、これだけの違いがあります。しかし、信頼性と複雑さのトレードオフも考えなければなりません(↓)

SOAP-REST-3

つまり、Data のための REST、Logic のための SOAP/WS-* というのが、Chappell さんの結論のようです(↓)

SOAP-REST-4

適切な視点から、丁寧に説明してくれますので、ぜひ ご覧くださいな。

スライド:http://proceedings.esri.com/library/userconf/devsummit09/papers/keynote_chappell.pdf

ビデオ:http://www.esri.com/events/devsummit/sessions/keynote.html

スライド:http://www.esri.com/events/devsummit/pdfs/keynote_chappell.pdf

Tagged with: ,

New Relational SDS に REST でアクセス

Posted in Microsoft by Agile Cat on March 22, 2009

The latest news and insight from the SDS team
Accessing the New Relational SDS with REST
Published Friday, March 20, 2009 9:16 AM by
davidrob
–Lev
From <http://blogs.msdn.com/ssds/archive/2009/03/20/9492744.aspx>

Hi Everyone!  私は Lev Novik。SQL Data Services Team のアーキテクトです。REST による SDS アクセスについて、止めてしまうのか、あるいは、優先順位を下げるのかといった多くの質問を受けています。そんなことは、まったくありませんので、ご安心ください。REST については、止めてしまうことなどなく、多くの開発者が望むと思われる方式で、それを適切にサポートしていくつもりです。 チョッと、説明してみますね。

今日における一般的な(Web)アプリケーションは、以下のような構造を持つのが大半だと思います:

  • Client(ほとんどは、Web ブラウザ内で実行)
  • Mid-tier Business Logic(ほとんどは、Web サーバー内で実行)
  • Back-end Storage(ほとんどは、リレーショナル・データベース )

REST SDS 09_03_23a

どんなプロトコルが使われていますか? Client と Mid-tier の間では、大半が HTTP で、REST も多いですよね。そして、Mid-tier と Back-end の間では、データベース側のネイティブ・プロトコルが一般的ですよね。

そうなんです。SQL Data Services の場合も、状況はまったく同じです。シナリオは、こんな感じです:

  • SDS は、Back-end Batabase の位置に入ります
  • Mid-tier Business Logic は Windows Azure もしくは、その外側で実行されます
  • Client は、まったく変わりません

REST SDS 09_03_23b

この世界においても、Mid-tier と SDS を接続するために、最もパワフルなメカニズムとツールが利用されると考えています。そして、最もシンプルで、エレガントで、Web フレンドリーな方式で、クライアントへ向けて Web アプリケーションを公開できる、簡単な方式が望まれているでしょう。そのため、私たちは、以下の方式に集中しています:

  • TDS (SQL Server native protocol) の公開:SDS とのフル接続を実現
  • SDS ベースのアプリケーションにアクセスするために、簡単な REST の公開を実現

後者を実現するために、ADO.NET Data Services (aka “Astoria”) を活用します。それは、データ駆動型の REST サービスを、可能な限り簡単に実現するという目的を持っています。ADO.NET Data Services を利用するためには、コーヒーでも飲みながら introductory movie を見て、あたなたのデータベースをイメージしします。そして、コーヒーのおかわりでも飲みながら、漠然としていても構いませんので、REST Web サービスを作るための方式を確認するというコースがお勧めです。

しかし、あなたのアプリケーションが、そう簡単にデータベースと、one-to-one でマッピングされるとも思えません。独自のビジネス・ロジックや、セキュリティ・ポリシー、そしてビューなどを構築したいと考えているでしょう? ADO.NET Data Services が それ を実現します。 しかも、とても具体的なサービスとして。この辺りで、三杯目のコーヒーが欲しくなるかもしれませんね。だって、SQL Server は、あなたの Dev Box にいるかもしれませんが、どうやって、SDS や Windwos Azure と組み合わせるのかという方法が分かりませんものね。その点について、私たちは、これまでのような方式を提供したいと考えていますよ:

  1. Windows Azure services を構築するための set-up を行う
  2. クラウドの SDS Database を構築し、あなたのスキーマによりアップロードする
  3. Visual Studio で Windows Azure Web Cloud Service Project を 作成 する
  4. ADO.NET Data Service プロジェクト・アイテムを加え、SDS Database を指定する(同じスキーマを持つローカル・データベースでもOK です)
  5. あなたの ADO.NET Data Service (security, biz logic, templates, etc) を作成する
  6. 接続文字列を、クラウドの SDS Database に切り替える (開発でローカル・データベースを使っている場合ですが)
  7. Windows Azure へ向けて、あたなのサービスを Publish する

このようにすれば、SDS-based REST Service が得られるでしょう。 お役に立てば幸いです。

From <http://blogs.msdn.com/ssds/archive/2009/03/20/9492744.aspx>

%d bloggers like this: