API開発のためのプログラミング言語"Ballerina"の直感的な構文について解説します。認証や承認、OpenAPIツール、可観測性、SQL/NoSQLクライアントライブラリなど、重要な言語機能についても論じます。記事を読み終えれば、Ballerinaが次のバックエンドAPI開発の有力な候補である理由がよく理解できるでしょう。2022年4月InfoQ編集チームが2022年に進化するソフトウェアアーキテクチャと設計のトピックをどのように見ているかの概要です。アーキテクトが今、何を設計しているかに焦点を当てています。Pan氏が、分散データベースシステムにおけるシャーディングアーキテクチャのパターンについて論じます。ShardingSphereプロジェクトがデータシャーディングの課題にいかに対処しているかを説明した上で、DistSQLを使って分散データベースと暗号化テーブルを生成する方法の実例2つを論じています。カルチャー&手法カオステストで、見えない課題からアプリケーションのレジリエンスを改善するこの記事では、Netflixが提唱するカオステストの原則を列挙した。読者は、カオステストが提供するメリットとデメリットを理解できるはずだ。することで、カオステストを行うかどうかの判断材料となる。リスクに対するすべてのメリットを考慮して、カオステストを行うために経営陣を説得すべき理由も説明した。次のことを考えてください。あなたは、6つの異なる言語で実装され、複数の異なるプラットフォーム上で稼働する完全に独立したWebサイトを持つ会社で働いています。独立したWebサイトのそれぞれが、個々のデータベースとスキーマを持っていて、様々なスキルセットのチームで管理され、アメリカ合衆国とヨーロッパをわたる8つの場所に位置しています。その会社は成長しているのです。これらのばらばらなシステムで、その中にある重要なデータを適切に素早く共有することができるようにすることです。あなたの設計基準は、以下のとおりです。ColdFusion)で実装されたクライアントに対し、システムは参入の障壁を低くする必要があります。システムは、多くの異なるデータタイプをサポートする必要があり、要求に応じて、新しいデータタイプを追加するために拡張可能でなければなりません私たちは、Homeaway.com(リンク)で約1年前にまさにこの問題に直面していて、そこで私たちは双方の仕事をしていました。2つの設計の考えを認めるのにそう時間はかかりませんでした。第一に、分散されたパブリッシュ/サブスクライブサービスが、サブシステムの弾力性と疎結合に対処するために良い方法であるということです。容易さを必要としているシステムにとって、自然なソリューションであるということです。パブリッシングプロトコルであるAtomと、Atomストアと呼ばれる新しい種類のデータサービスに、私たちを直接導いてくれました。私たちは、HomeawayのためにAtomストアを実装するために、去年1年を費やしました。名づけられたオープンソースのAtomストアフレームワークを切り出しました。本稿では、それについて説明します。AtomAtomは、2つの仕様で成り立っています。それは、Webフィードを記述するためのXMLベースの言語を定義するAtomシンジケーションフォーマット(リンク)と、そのフィードを取り出して操作するためのRESTfulなHTTPプロトコルを記述するAtomパブリッシングプロトコル(リンク)です。Summary)の代わりとして考えられ、一般に、ブログエントリといった人間が書いたテキストを含んでいます。(XMLエレメントとアトリビュート)の内部構造は、著者、言語、タイトルなどのようなパブリッシングの意味を伝達します。あなたをからかっているのではありません。Atomエントリは、それらのペイロードとしてさまざまなデータを運ぶのにとても適しています。Atomエントリはデータの個々のレコードで、Atomフィードはエントリのリストです。AtomはRESTfulなプロトコルなので、リソースを(この場合、エントリとフィード)特定するURIのHTTPメソッドを実行することによって、リソースにアクセスします。ようなURIでGETをすることで実現されるでしょう。そのレスポンスは、以下のようになります。rel="edit"href="http://your-blogserver/MyBlog/1235"/><updated>2007-05-01T17:00:00Z</updated><id>1235</id></entry></feed>Atomは、エントリに適用することのできるカテゴリの概念もサポートしています。カテゴリは、任意の文字列タグで、あるグループの一部としてマークする目的でエントリに適用することができるものです。フィードURIは、フィルタリングを組み込むために修正されます。それらに適合した特定のカテゴリを持つフィードからエントリのみを返します。Atomの世界で特別な意味を持つ用語の組があります。エントリーは、ワークスペースとコレクションの固定された2つのレベルの階層でグループ分けされます。ワークスペースはいくつかのコレクションを含み、コレクションはいくつかのエントリを含みます。フィードのURIは、フィードのワークスペースとコレクションから成ります。http://your-atom-server/workspace/collectionそして、エントリのURIは、ワークスペース、コレクション、エントリIDから成ります。エントリのための識別子は、所有しているコレクションの範囲内でユニークでなければなりません。ようなAtomは、Webシンジケーションフレームワークの基盤を提供します。ブラウザーやニュースリーダーを含むAtomを解釈する既存のクライアントや、実際に一般的な言語で書かれたクライアントなどが数多く存在しています。加えて、Atomは、実際のところはHTTPとXMLの上にあるちょっとした慣習のセットなので、Webが利用できるプログラミング環境であれば何でも、簡単にアクセス可能です。拡張とレイヤープロトコル核となるAtomプロトコルは、フィードとエントリを操作するための基本的なオペレーションと、エラーのレポートとハンドリングのための方法を記述します。拡張の概念を提供します。XMLドキュメントの中で表現することができる追加的なXML要素と属性で、Atomをサポートするサーバーの振る舞いを変更するためにURIに適用することができる追加的なHTTPのリクエストパラメータです。以下の2つの重要な拡張があります。どのような種類の検索がサポートされているかを決定するための、サーバーを内省する方法を含んだ検索のためのプロトコルを定義します。OpenSearchに対応したサービスは、エントリとして表現された個々の結果とともに、Atomフィードとして検索結果を返します。Atomフィードのための次へと前へのリンクタイプを定義することで、時系列データのページネーションに対処します。そのAtomフィードは、複数ページのfeedを通して前方や後方へのページをつけるためにクライアントが利用することができます。GDataは、核となるAtomの仕様とOpenSearchだけでなく、Atomの仕様で解決されていない追加的な機能をカバーするための多くの独自拡張を取り入れています。あなたがAtomエントリをブログまたはニュースフィードのようなWebコンテンツに制限せず、Atomを一般的なデータの管理まで広げるとき、あなたにはAtomストアが必要です。OpenSearchを使用して検索することができます。Atomサーバーは、自身のデータへの分散アクセスのための戦略を導入したいという思いから生じたものです。データアクセスの分散制御Atomプロトコルを利用するメリットの一つは、本質的に分散されたシステムの機能です。Atomサーバーでは、私たちはページネーションの概念を組み合わせ、feedの更新のためにサーバーをポーリングするメカニズムで、それぞれのリクエストで返るエントリの数を制限しています。クライアントは、feedの開始から始めて、ページのデータが無くなるまでリクエストを続けます。クライアントは、定期的に新しいデータをチェックする必要があります。自体は、あらゆる変化についてそれぞれのエントリにカウンターをインクリメントすることで、単純に印をつけます。feedごとに処理されたカウンタの最終値を保持する必要があります。feedに対する次のポーリングは、データの次のページの開始インデックスが、前のページの終了インデックスに設定されます。この方法で、Atomサーバーが高容量のデータの変更を素早く処理するケースに効果的に対処します。複数のエントリは、1秒のうちに変わることができました。開始インデックスなしでfeedを得るとき、デフォルトで0から始まります。いう名の拡張タグを返します。これは、取得したページでの最後のインデックスとなります。<as:endIndex>23</as:endIndex>その数は、次のポーリングでの開始インデックスのクエリパラメータとして利用されます。レスポンスを返します。これは、次のページデータを求める前に設定されたポーリング間隔を待つことが望ましいという意味です。それぞれのエントリが、所有するワークスペースとコレクション内でユニークなIDを持つということは重要なことです。これら3つのコンポーネントは、エントリのURIをそれに対する一意の識別子とし、サービスの中で他のエントリとの識別が可能です。Atomサーバーは、POSTとPUTの2つの異なるHTTPメソッドを利用して新しいエントリの作成をサポートします。あるエントリがPOSTで作成されるとき、使用されるURIは新しいエントリが挿入されるコレクションへのURIです。この場合、AtomサーバーはエントリIDを新しいエントリに割り当て、そのIDをレスポンス部に入れてPOSTを呼び出し元へと返す役割を果たします。http://your-atom-server/widgets/acmeそうではなく、エントリがPUTでつくられるとき、エントリIDを割り当てることに対する責任はPUTをおこなうクライアントにあります。PUTで作られるURIは、作られるであろうエントリへのURIです。http://your-atom-server/widgets/acme/1000.xml既存のエントリを更新することは、エントリのURIに対してPUTをおこなうことによってなされます。その意味で、PUTでエントリをつくることは、「レイジー」な更新に似ています。対象のエントリがないならば作成され、そうでなければ既存のエントリは更新されます。Atomサーバーへの書き手が、自身が編集しているリソースに関する現在のリビジョン番号を知っている必要があります。書き込み操作が完了できるであろうと仮定して、リソースへの書き込みをしなければなりませんが、誰かがその間にそのリソースを書き込んだケースでも、優雅に対処することができます。Widgetsを変更したいと仮定します。123を問い合わせます。http://your-atom-server/widgets/acme/123.xmlそして、そのfeedのレスポンスで以下の「editのリンク」が返されます。rel=”edit”/>Aは、123.xmlの表現の編集をおこないます。Aがその操作をおこなっている間、Bは現在のバージョンの123.xmlを問い合わせ、同様のレスポンスを得ます。Bの編集はAのそれより時間がかからないので、Bはeditのリンクに対して、すぐにその変更を書き込みます。Bの編集が成功したということをAtomサーバーに知らせます。そこで、Aがその編集を終え、同じeditリンクに書き込みをしようとしますが、Bの編集によってリビジョン番号が既に更新されています。HTTPエラーを受信します。それは、サーバーからリソースの一覧を最後に参照してから、更新しようとしていたデータに対し、誰かがそのリソースを更新したということを示しています。この場合、AはGETでリソースを再取得し、新しいeditリンクを得て、処理を繰り返します。コピーを変更することができるので、AがBの変更をむやみに上書きしないようなシステムにすることです。多くのシステムでは、与えられたデータセットに対し、単一の、信頼できるライターがあるだけです。そのケースでは、楽観的並行性を管理するオーバーヘッドを減らすために、リビジョン番号としてアスタリスク(*)を与えることによって、楽観的並行性を無効にすることを可能にしています。http://your-atom-server/widgets/acme/123.xml/*しかし、与えられたリソースへの書き込みがただ一人であるということが確実に分かっているときだけ利用するということが重要です。カテゴリクエリAtomでは、カテゴリは値の組(SchemeとTerm)としてエントリを特定します。Schemeは、基本的にカテゴリの「名前空間」で、Termは、名前空間の特定の値です。GDataの拡張をAtomから取り入れ、Atomサーバーでは、クライアントがエントリに適応したカテゴリによるfeedのフィルタリングをおこなうための、特定のfeedシンタックスを許可します。Widgetsだけのfeedを得るためには、リクエストは以下のようになります。http://your-atom-server/widgets/acme/-/(urn:colors)red複数のカテゴリーが指定される場合、所定のカテゴリ(BooleanのAND)全てもつエントリだけが受信されます。Widgetsの全てを返します。ANDとORを使うには、接頭辞の表記で指定することもできます。Widgetsの全てを返します。これらのfeedは、正確に他のどのfeedとも同じクライアントで処理されなければなりません。それらは、カテゴリなしのfeedと同様にポーリングとページネーションをおこなうことができます。サーバーは、すぐに利用できるAtomストアの実装です。それは、JavaのWebアプリケーションとして実装されていて、J2EEのサーブレットコンテナへのデプロイを必要とします。それに基づき、RESTfulな操作とAtomのXMLボキャブラリを処理するために、AtomサーバーではAbdera(リンク)と呼ばれるApacheプロジェクトのAtomプロトコルのオープンソース実装を利用しています。既存のアプリケーションにAtomフロントエンドを加えるための優れたライブラリです。対照的に、Atomサーバーは成熟したAtomストアです。難しい設定をすることなく、格納する必要のあるコンポーネント全てを提供し、Atomエントリ自身の内容だけでなくAtomのメタデータと相互作用します。Atomサーバーのプロトコルは、GDataのプロトコルから適切なものを全て取り入れています。一部の場合において、私たちはURLの読みやすさや、単純なクエリー構造や、GDataの仕様によってカバーされていない機能を実装するために、すこし違った決定をしました。サーバーは、リレーショナルデーターベースのエントリに関連するAtomのメタデータ全てを管理します。リレーショナルデーターベース、ファイルシステム、特定のニーズに依存したもののいずれかで、実際のエントリの内容を格納します。feed変更の間隔でポーリングをする必要があるだけです。Atomサーバーは使いやすいです。それは、単一のWARファイルや組み込みのJettyサーバーの中で動作するスタンドアロンサーバーとしてもデプロイできます。Bean)を単純におこなうことで、Atomサーバーを利用することができるでしょう。結論Atomサーバーには、私たちがまだ取り上げていない、重要で高度な機能がいくつかあります。今回はそれらの機能を説明するスペースがありませんが、それについては次回に説明する予定です。登録か更新の際の、「自動タグ」エントリのための簡単な構成メカニズム。組み込まれ、コンテンツへのXPathを可能とし、条件付きでそれとAtomカテゴリを関連付けることができます。登録、更新、削除リクエストが混じった「バッチ」操作をフルサポートしています。feeds-異なるコレクションやワークスペースから、さまざまなエントリをAtomカテゴリを使用してaggregateエントリに結合するための強力な機能。これらのaggregateに関するfeedリクエストの機能を含みます。feedをリスンすることができます。それは、すべての部分の変更を反映します。それは、私たちの会社で使用する生きた製品で、1日に100万以上のリクエストを処理し、数百万エントリを格納します。RESTfulな仕様で構築することは、GDataのような既存のサービスの設計を活用することで、構築のための確かな基盤を保証することができます。私たちは、あなたがコピーを手に入れ、あなたが何を考えているかを私たちに教えてくれることを望んでいます。取得でき、数分で実行することができます。毎週火曜日に前週のまとめコンテンツをお送りいたします。(日本語版は不定期リリース)25万人のシニアな開発者コミュニティーにぜひご参加ください。サンプルを見るあなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。登録するとさまざまなことができます。アカウント登録をしてInfoQをお楽しみください。あなたの意見をお聞かせください。毎週火曜日に前週のまとめコンテンツをお送りいたします。(日本語版は不定期リリース)25万人のシニアな開発者コミュニティーにぜひご参加ください。サンプルを見る様々なイノベーターとアーリーアダプターがお送りするテクノロジーの概要を見る。自分がまだ知らないことに気づいていないと知るあなたが興味のあるトピックスをいつでも最新な情報に。あなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。Inc.プライバシーBT。