Agile Cat — in the cloud

OpenFlow のスイッチとは?

Posted in Network, OpenFlow by Agile Cat on September 1, 2011

OpenFlow: Enabling Innovation in Campus Networks
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.141.2269&rep=rep1&type=pdf
Number 2, April 2008
This article is an editorial note submitted to CCR. It has NOT been peer reviewed.
Authors take full responsibility for this article’s technical content.
Comments can be posted through CCR Online.

image

ーーーーー

OpenFlow のことを調べようとして、探しだした論文からの抜粋です。 ここでは、OpenFlow で用いる、各種のスイッチが紹介されています。 以前にも、OpenFlow のゴールとは? というコンテントをポストしていますので、始めての方は、そちらから お読みください。 ーーー __AC Stamp 2

ーーーーー

ここでの基本的なアイデアは、シンプルなものである。つまり、一般的な Ethernet のスイッチとルーターに含まれる、フローテーブル(通常は TCAM で構築される)を活用することにある。 そこには、ライン・レートにおいて、ファイアウォールおよび、NAT、QoS を実装し、また、データを収集するためのノウハウが詰まっている。 それぞれのベンダーにおけるフローテーブルが異なっていても、数多くのスイッチとルーターで実行される、各種機能の興味深い共有セットを識別できる。 OpenFlow では、この共有機能のセットを活用する。

<中略>

Dedicated OpenFlow switches.リモート・コントロール・プロセスにより定義されるように、専用の OpenFlow Switch は、ポート間でパケットを転送するだけのデータパス要素である。 Fogure 1 に、OpenFlow Switch の例を示す。この文脈において、フローは広義に定義され、また、Flow Table における特定の実装能力だけにより、制限されるものとする。 たとえば、フローは、TCP 接続のことであり、また、特定のMAC アドレスや IP アドレスから得られる全パケットであり、同一の VLAN タグを持つ全パケットや、同一のスイッチ・ポートから得られる全パケットでもある。非 IPv4 のパケットに関する実験おいては、特定のヘッダー(ただし非標準)とマッチする全パケットと、フローを定義することが可能となる。

OpenFlow-enabled switches.いくつかの商用スイッチ/ルーター/アクセス・ポイントは、Flow Table/Secure Channel/OpenFlow Protocol(我々はセクション5で若干の例をリストする)を加えることで、OpenFlow 対応へ向けて拡張される。 一般的に Flow Table は、TCAM などの既存ハードウェアを再利用するだろう。 つまり、その Secure Channel と Protocol はスイッチのオペレーティング・システム上での実行のために移植されるだろう。Figure 2 が示すのは、OpenFlow に対応する商用のスイッチとアクセスポイントによるネットワークである。この例では、すべての Flow Tables が、同一のコントローラーにより管理される。 つまり、性能と堅牢性を高めた複数のコントローラーにより、スイッチを制御することが、OpenFlow Protocol により実現される。

Additional features. あるスイッチが、上記のヘッダ・フォーマットおよび、前述の 4つの基本的なアクション(詳細に関しては OpenFlow Switch Specification を参照)をサポートする場合には、「 Type 0 」のスイッチと呼ばれる。 私たちがスイッチに対して望むのは、対象となるパケット・ヘッダーの一部を書き直し(たとえば NAT に対応するため、そして、中間のリンクでのアドレスを解析困難にするため)、パケットを優先順位クラスにマップするなどの、追加のアクションをサポートするものが多数派になることである。同じく、新しい非 IP プロトコルの実験を可能にするために、いくつかの Flow Tables は、パケット・ヘッダー内の任意のフィールドに対応する。 特定の機能セットが出現するにつれて、「 Type 1 」スイッチを定義していくことになる。

Controllers. コントローラーは、実験のための Flow Table に基づいて、フリー・エントリーの追加/削除を行う。 たとえば、静的なコントローラーは、実験の期間中においてテスト・コンピュータのセットを相互に結び付ける、フローを確立するために PC 上で実行される、シンプルなアプリケーションになるのかもしれない。 このケースにおけるフローは、現在のネットワークで用いられる VLAN に似ている。 つまり、実験的なトラフィックを、プロダクション・ネットワークから分離するための、シンプルなメカニズムを提供することになる。 この方式をとおして見ると、 OpenFlow は VLAN における一般論となる。

image

ーーーーー

<関連>

OpenFlow のゴールとは?
OpenFlow と、NDDI、OS3E とは?
OpenFlow 専門家になるための近道とは?
OpenFlow により、ネットワーク業界は HOT になるのか?
スタンフォード大学の Open Networking Summit と OpenFlow

Heroku の Java サポートと、その背景について

Posted in PaaS, Salesforce by Agile Cat on September 1, 2011

Java developers, meet Heroku
By
Derrick Harris Aug. 25, 2011
http://gigaom.com/cloud/java-developers-meet-heroku/

_ Gigaom

Heroku, the popular Platform-as-a-Service offering initially for Ruby developers only, now supports Java. Actually, Heroku has added support for both the Node.js framework and the Clojure programming language over the past few months, but Java is in a whole other league. If it’s not the world’s most popular programming language, it’s certainly among the most popular — especially among enterprise developers.

Heroku は、人気の PaaS プラットフォームであり、当初は Ruby のみをサポートしていたが、いまでは Java にも対応する。 現実に、これまでの数カ月間において、Heroku は Node.js  フレームワークClojure プログラム言語を加えてきたが、まったく別のものとして Java もサポートする。 もし Java が、世界の最も人気のプログラム言語でなくても、とりわけ、エンタープライズ・デベロッパーの間では、人気の部類に入ることは否定しようがない。

imageHeroku has been gaining credibility among enterprise developers since becoming part of Salesforce.com in December, and part of courting those developers is providing the languages, tools and capabilities that they want. Certainly, though, Java is only part of the journey to woo developers who want to launch their applications in the cloud, as Heroku’s forays into Node.js and Clojure illustrate.

Heroku に関しては、昨年の 12月に Salesforce.com の一部になってから、エンタープライズ・デベロッパーからの信頼を蓄積してきた。そして、デベロッパーたちの期待に応えるために、彼らが必要とするプログラミング言語や、ツール、機能を供給している。 しかし、Heroku の斬新な試みである Node.js と Clojure が例証するように、クラウドでアプリケーションを立ち上げたいと考えるデベロッパーにとって、Java はオールマイティではない。

Likewise, PaaS providers of all stripes have been working to expand beyond their legacy developer bases. Just this week, Engine Yard bought PHP PaaS startup Orchestra to complement its Ruby on Rails prowess, and AppFog transitioned to a Cloud Foundry foundation to add support for languages beyond its PHP roots.

それと同様に、すべての PaaS プロバイダが、それぞれのレガシーな開発環境を拡張するために努力している。今週(8月下旬)のことだが、Engine Yard は Ruby on Rails の能力を補完するために、PHP PaaS スタートアップである Orchestra を買収した。 そして AppFog は、ルーツである PHP を超えた言語サポートのために、Cloud Foundry へと基盤を移行した

For more on programming with Java on the Heroku platform, which the company says eliminates many of the problems associated with J2EE, check out co-founder Adam Wiggins’ blog on the news.

J2EE と結び付けられた数多くの問題を解決するという、同社からの説明については、co-founder である Adam Wiggins のブログを参照して欲しい。

Related research and analysis from GigaOM Pro:

ーーーーー

clip_image001この Heroku と Ruby on Rails の関係のように、当初は一点突破を売りにしていたプラットフォームも、そのビジネスが拡大するにつれて、開発環境の多様化を求められるようです。それぞれの特徴が薄れてしまい、なんとなく残念な気もしますが、ビジネスを考えれば当然の選択なのかもしれません。 この領域でも、これからは垂直統合のアラシとなるのでしょうかね。 ーーー __AC Stamp 2

ーーーーー

<関連>

Facebook のようなエンタープライズ・ソフトウェアを作りたい – Salesforce は語る
Salesforce による Heroku 買収の続報
Salesforce が Heroku を $212 Million のキャッシュで買収

Twitter の Trend API は、XML から JSON-Only へと移行する

Posted in API, Twitter by Agile Cat on September 1, 2011

Twitter API Ditches XML For Trends: New Features Are JSON-Only
Adam DuVander, August 26th, 2011
http://blog.programmableweb.com/2011/08/26/twitter-api-ditches-xml-for-trends-new-features-are-json-only/

_ ProgrammableWeb

Twitter is embracing the trend where 1 in 5 new APIs do not support XML. The trend is playing out, appropriately enough, with Twitter’s endpoint for accessing global and local trending topics. It follows a move in late 2010 where Twitter Streaming went JSON-only. All signs point to no XML support for new Twitter features.

Twitter は、新しい 5つの API のうち、1 つが XML をサポートしないという流れを容認しようとしている。 こうした傾向においても、グローバルおよびローカルで流行っている、トピックにアクセスするための Twitter エンドポイントを、充分に機能させることが可能である。 そして、こうした方向性は、Twitter Streaming が JSON だけに対応するようになった、2010年後半から継承されている。 Twitter の新しい機能では、XML をサポートしないという方向へ、すべてが向かっているようだ。

imageThe move to JSON is brought on by Twitter’s consolidation of the three separate endpoints for accessing trends into a single endpoint. The one solution is built off of Yahoo’s WOEIDs (Where on Earth IDs). WOEIDs have been the basis of location-related Twitter calls since Twitter originally released location trends nearly two years ago. The identifiers were also central to the Mixer Labs’ GeoAPI acquired by Twitter in late 2009. Global trends will still be available using a WOEID of 1.

こうした JSON への移行は、シングル・エンドポイント内のトレンドにアクセスするために、3つのエンドポイントをコンソリデートさせるという、Twitter の考え方に応じたものとなる。 1つのソリューションは、Yahoo の WOEID (Where on Earth ID)から構築される。 約 2年前に Twitter が独自のロケーション・トレンドをリリースした時から、それに関連する基本として WOEID が利用されている。 この識別子は、2009年後半に Twitter が買収した Mixer Labs の、GeoAPI の中心にもなっている。 グローバル・トレントに関しては、依然として WOEID の 1 と用いることが可能である。

注記:http://developer.yahoo.com/geo/geoplanet/guide/concepts.html
http://4rapiddev.com/php/get-woeid-of-a-city-name-from-ip-address-with-php/

Twitter’s Jason Costa explained why Twitter is removing XML:

As well as standardizing the trends URL we are also planning to switch the trends API to JSON only. The reason for this is because the use of XML on the trends API is significantly low and removing support would allow us to free up resources for other developments.

Twitter の Jason Costa は、XML を排除していく理由につ体、以下のように説明している:

トレンド URL を標準化することに加えて、それらの API を JSON only に替えることを計画している。 その理由は、トレンド API 上での XML の利用が、きわめて低レベルのものであること、そして、サポートの負荷を減らして、他の開発にリソースを振り向けることにある。

Running down the data formats supported by Twitter’s various APIs, there is still plenty of XML support (as well as RSS and Atom), but some of the newer features are JSON-only.

Twitter における各種 API がサポートするデータ・フォーマットを調べると、依然として XML(RSS と Amtom も)が数多くサポートされているが、いくつかの新しい機能は JSON only になっている。

Twitter API Data Formats

image

As we wrote then the JSON-only Streaming API was announced, it seems clear that XML does not have much future at Twitter, at least with new features. Since so many applications count upon some of the oldest Twitter functionality, such as the core timeline, we’d expect XML to be supported for awhile, if not indefinitely. That said, Twitter hasn’t shied away from forcing developers to make updates before. After several delays, Twitter shut off basic authentication one year ago. Most recently the company implemented changes for applications accessing direct messages.

JSON only の Streaming API が発表されたと、私たちの記事に書いたときから、少なくとも Twitter の新しい機能においては、XML が 将来に渡って利用されることは無いと思われる。 しかし、Twitter のコアである TimeLine など、従来からの Twitter 機能を、数多くのアプリケーションが利用している。したがって、無期限ではないにしてもに、しばらくの間は、XML がサポートされることを期待するだろう。 しかし Twitter は、アップデートに先行して、デベロッパーたちに更新を強いるようなことはしない。1年前にも、数日の猶予の後に、基本的な認証を止めてしまった。また、最近においても、ダイレクト・メッセージにアクセスするアプリケーションを、Twitter は変更している。

ーーーーー

TAG indexこと、API に関しては、XML も徐々に役割を減じていくのでしょうかね。 ともあれ Twitter の API が最新の技術により更新されていくは、様々なデベロッパー・コミュニティに影響を与え、また、そこでのスキルも蓄えていきます。 いろいろな意味で、Twitter と API には、がんばって欲しいですね。 ーーー __AC Stamp 2

ーーーーー

<関連>

Twitter の 圧倒的な API 消費量は、Facebook や Google の 3倍に達する
5 つのエクセレントな、クラウド開発コミュニティ
最新のミュージック・マッシュアップ API とは?
USA Today が提供する、アメリカ国勢調査の分析 AP

%d bloggers like this: