ブロガーであるGrey Lens Man氏が、エンタープライズを悩ませているレガシー問題について興味深い記事を投稿し、実行可能なソリューションとして新たなソフトウェアスタック(JOSH、JSON OSGi Scala HTTP)(リンク)を提案している。
Grey Lens Man氏は、エンタープライズITの非常に良く知られたことについて以下のように話している。
ちょっとした問題を抱えています。厳密には安くないAS400上にRPGおよびCOBOLの300万のライン、5,500の論理および物理ファイルがあり ます。数年間を経て、システムは複製、分岐し、互換性のないいくつものバージョンが世界中にひろまります。
また、以下のようなことが発生し、さらに痛みを伴う。
詳細まで説明しませんが、データの2.5 Tには、カスタマーファイルに特別なフラッグがあり、どのようにカスタマーがシステムと対話するのかという基本的な性質を決定します。左から3バイト目の Filler3にあります。1つのファイルには、Account IDコラムは場合によっては、実際にAccount番号があります。必ずあるわけではありません。別の何かであるときもあります。ZipLoc3 column_really_に何が含まれているのか、決して推測することはできません(ヒント：ジップコードのようなものではない)。
その問題に対するソリューションについて語るとき、Grey Lens Man氏はかなり率直である。
誰もレガシーシステムを一生のサポートにさせたくはないので、エントロピーを転換するために、ヘッド数を二倍にしたり、このpigにある種のSOA lipstickを配置することは、避けたいことです。問題は、基本的なうえに体系的です。
Grey Lens Man氏が提案しているソリューションはJOSH、JSON OSGi Scala HTTPである。
Jsonは、XMLが約束したものを提供します。人およびコンピュータによっても同様に、分かりやすく、アクセスおよび使用できるデータマークアップで す。直列化/非直列化はXML、ThriftおよびProtocol Buffersと同等か、それよりも高速です。もちろん、XSD Schemaタイプのチェック、SOAPおよびWS-*の標準化はなくなっています。そういう取引をしています。
OSGiは、バージョン管理されたコンポーネントおよびサービス向けの標準化された動的モジュールのフレームワークです。ロガーコンポーネント、HTTP サーバコンポーネント、???コンポーネントを選択し、自分の内部コンポーネントを追加すれば、専用のアプリケーションソリューションができます。真の代 替品でのマイクロ開発です。何をあきらめているのでしょうか?25のフレームワークを搭載したモノリシックJ2EEアプリケーションサーブレットは、 SCAおよびXML構成の地獄です。取引をします。
HTTPは単純で、効果的で十分高速で、広くサポートされています。単純なデータをAからBに移行するのに、不必要に複雑で終わりのないプロプライエタリプロトコルにうんざりです。HTTPは完璧ではありません。けれど、この取引をしています。
すべてのインターフェイスは、HTTPおよびJSONに基づいてRESTが着想した単純なAPIです。これはJOSHスタックの結果です。
Scalaは、群を抜いてすばらしいですが、JOSHスタックにおいてはもっとも簡単な選択です。JSONまたはXMLまたはThriftまたはProtocol Buffersの決定と格闘しました。
Ted Neward氏はその提案されたソリューションを評価したが、懸念も示した(リンク)。
状況の表面上、スタックがかなり良いように思えます。OSGiは実行中のJavaシステムで、バージョン管理やモジュール性の管理をするためには、かなり 確かなスペックであり、さらに重要なことは、よく知られており、比較的信頼でき、昔ながらの問題にも対処することが十分実証されています。
しかし、問題点がいくつかあります。JSONは単純なワイヤプロトコルですが、それはメリットとデメリットの両方があります(1つにはオブジェクト中心 で、オブジェクトが特定の関係の場合に陥る問題と同様の問題にぶつかります)。そして、XMLが提供するユビキタス性がないことです。XMLが明らかに過 剰の導入を被ったことは認めますが、さまざまなシステムと対話するものに対するベースラインを構築している場合、ユビキタス性が本当に必要です。
HTTPは、長距離やクライアント始動の通信にはもってこいですが、決定的な制限があります(これについては公然と認めている)。少なくとも内部に直面しているコンシューマーにとってはそうです。
そして、スタックからなくなっている別の重要なレイヤーがある。それはパーシスタントレイヤーであり、Grey Lens Man氏が、ソリューションを求めている。Ray Krueger氏はJOSCHを提案している。CはCouchDBを表す。Grey Lens Man氏は提案されたソリューションを評価したが、Cassandra(リンク)またはVoldemort(リンク)へより傾いている。Neward氏は可能なソリューション としてCouchDBを気にいっているが、db4o(リンク)も提案している。氏はさらに、.NET向けの対応するソリューションがJSON + Assemblies + F# + HTTP = JAFHになることを熟考する。