【IT】AWS、言語やプロトコルに依存しないインターフェイス定義言語(IDL)「Smithy」をオープンソースで公開
■ このスレッドは過去ログ倉庫に格納されています
クラウド時代のアプリケーションは、複数のソフトウェアがAPIを通じて連携するアーキテクチャが主流になると考えられています。そのため、さまざまなソフトウェアにおいて正確かつ確実にAPIを実装することの重要性が高まっています。
AWSは、このAPIを定義する言語、およびその定義からAPIを実装するコードを生成するツールからなる「Smithy」ベータ版をオープンソースとして公開しました。
SmithyのWebサイトから、その説明を引用しましょう。
Smithy is a protocol-agnostic interface definition language and set of tools for building clients, servers, and documentation for any programming language.
Smithyはプロトコルに依存しないインターフェイス定義言語(IDL:Interface Definition Langugae)と、どんなプログラミング言語にも対応したクライアントやサーバ、ドキュメントなどを生成する一連のツールです。
つまりSmithyを用いてAPIを定義すると、そこからさまざまなプログラミング言語に対応したAPIのソースコードとドキュメントが生成されるわけです。それによって正確で確実に相互連携を可能にするソフトウェアの開発が容易になると期待されます。
SmithyはAWSの内部でIDLとして10年ほど使われてきたものをベースとしていると、次のように説明されています。
Smithy is based on an interface definition language that has been widely used within Amazon and AWS for over a decade.
SmithyはAmazonとAWSの内部で10年ほど広く使われてきたインターフェイス定義言語をベースとしています。
プロトコルとプログラミングに依存しないことが大きな特徴
Smithyの大きな特徴は、プロトコルやプログラミング言語に依存しない点でしょう。
例えばIDLとして知名度が高く、実際に多く使われてもいるOpen APIは、RESTful APIのためのIDLとされています。
参考:RESTful APIの記述標準化を目指す「Open API Initiative」をマイクロソフト、Google、IBMらが立ち上げ。Swaggerをベースに
アプリケーション間で使われるプロトコルにはそのほかにもgRPCやGraphQL、MQTT、古くはXMLをベースにしたSOAPなど、さまざまなものがあります。
大型のアプリケーションであれば、こうした複数のプロトコルをそれぞれ適切な場所において適切な形で使い分けることになるでしょう。また、アプリケーションを開発するチームごとに得意なプログラミング言語や適切なフレームワークを用いることになるでしょう。
Smithyが単体でこうしたさまざまなプロトコル、プログラミング言語でAPIを実装することをカバーするとすれば、非常に有効なIDLとツールになるはずです。特に大規模な組織で開発を行っている企業などでは、定義とツールを一元化できる意義は大きいでしょう。
AmazonとAWSが自社のためにSmithyを開発したのも、自身による大規模開発におけるこうしたツールのニーズが高かったためであることは間違いないと思います。
ただし、現状の公開されているSmithyはまだベータ版のためか、どのプログラミング言語に対応しているのか具体的な説明は見つからず、またGitHubのリポジトリ内のコードをざっと見たかぎりでは、ツールのコードもまだすべてが揃っているわけではなさそうです。
今後のSmithyの成熟によって実際にどこまでカバーされるのか、注目されます。
https://www.publickey1.jp/blog/19/awsidlsmithy.html あくまでインターフェース定義言語。
オニオンアーキテクチャへの移行なんかが少しお手軽になる感じだろうな。
つまり、もっとAWS使ってくれって話w まーこれだけAWSがマイクロサービスのバリエーション普及させちまったから、やつらの定義するIDLが覇権を握る理屈はわかる…
だが、オープンにしてもAmazonに全部牛耳られるWebサービスの世界でええんかのぉ >>8 >>1 >>2 >>3 >>4
客を技術的にロックインさせて独占・寡占状態を目指しているということだ
ロックインとは - IT用語辞典 e-Words
e-words.jp › ロ
May 23, 2014 - ロックイン【lock-in】とは、現在利用している製品やサービス、技術などから別の同種の
ものへの乗り換えや入れ替えが困難な状態のこと。今あるものを捨て同じ種類の別のものに切り替える
のに必要なお金や時間、手間などのことを OpenAPIじゃ駄目な理由がわからん
ただの囲い込みなのか? 言語に依存しない言語って、ちょっと何言ってるかわからない。 Smithは欧米でもっとも多い姓名だ。
だからもっと多くの人に合致するという意味なんだろうか?日本だと、鈴木仕様とか佐藤言語という感じか。
うーん、AWSのセンスが気持ち悪い。 >>2
CORBAの発展系がRESTful API
新しい技術についてこれないオッサンと自白してるようなもんですよ >>10
ぶっちゃけ何でもいいとこだから(単なるスケルトンジェネレータ兼ドキュメント生成ツール)
権利関係が複雑になるのを避けてるんだと思うな。 >>12
言語やプロトコルに依存しない
インターフェイス定義言語(IDL)「山田」をオープンソースで公開
うえっ…吐き気がする。 >>10
後発で出す以上当然より優れた点があると思いたいな >>12
>>16
smith はもともと「鍛冶屋」「製造者」って意味なんだが。 アラン・スミシー(Alan Smithee)は、アメリカ映画で使われていた架空の映画「監督」の名前である。 >>10
swaggerだとREST以外のAPIが書けないじゃん
mqttとかzmqとかも使ってるんで、こんなの欲しかった 個人的にはXML Schemaをそういう目的に使う事が多いな。
後はProtocol Buffers?
まぁAPI全体の表現はできないけど。
そこそこ便利だろうけどどうだろうな。
ツール群の整備度合いによる。
ともかく自然言語ドキュメントとかでAPIを定義するのは勘弁してくれ。
多少説明やコメントに残るのは当然仕方ないとはいえ。 IDLって言葉聞いたのATLでOLE開発してたとき以来だな 日本のITゼネコンがこういうのを使うと、
仕様書からこの言語に落とすだけの仕事ができて
オーバーヘッドと誤解を生む原因になるだけだと思う swaggerがそれなりに流行ってきた所なのに
微妙に分裂しそうだな >>24
ご心配ありがとう。
ええ、わたしは元気です。 また増えるのか
どうせデバックには既存言語の知識が必要な予感 これとかXMLとか、ただのシンタックスシュガーを有難がる馬鹿って多いよな SOAPのライブラリ使ってる。変更するの面倒くさい
AWS化の話しあるけどのせかえるだけでええわ つまり
メタ言語ってことだろ。プロトコルも それぞれの使用言語ごとに、それ使ったプログラムごとに 適切に選び出される。
プログラムを数珠つなぎして、ユーザーの構築したい機能を簡略化して提供する。 インターフェイス定義言語とXMLは別物だろ。
インターフェイス定義言語がXMLで記述されることはあるとしても。その場合、XMLのほうが下位。
日本語、英語、作文とかのルールみたいなこと。 言語が時代によって変遷するのはやむなしとはいえ、乱立は勘弁してほしいな…
汎用性を目指した肥大化した新言語同士の相互変換に泣くって皮肉にも程がある >>14
> CORBAの発展系がRESTful API
全然別物に見えるけど… >>42
ネット越しにメソッド呼び出すRMIというくくりでは合ってるんじゃない? アマゾン・プレミアが証明するように、
アマゾンとはこちらの許可も得ずに勝手に
値段をあげてくる連中であることに留意せよ。 帯に短し襷に長し
どうせメインはRESTfulだろうし、ならSwaggerでよくね?ってなる
他のプロトコルはサポートが薄くて、ネイティブじゃなきゃ使えねーよ!ってなる >>29
swaggerも最初はシンプルだったのに、版が上がるに連れて、構造化が複雑になってきて、もはやウザいだけになってきた
APIの定義とか、Pythonのソース見てくれと、突き放したい >>14
COBRAが駆逐されたようにしか見えない… >>1
Windows Communication Foundation的なやつのAWS版ってことかな? ■ このスレッドは過去ログ倉庫に格納されています