Gleyzer両氏によって共同開発されました。2019で、同言語の発表を行いました。InfoQはPurdy氏に言語と、氏らが解決を目指した問題について聞きました。設計/アーキテクチャアジャイルマニュフェスト:ソフトウェアアーキテクトの視点ソフトウェアアーキテクトの役割と責任はアジャイルソフトウェア開発のためのマニフェストの価値と矛盾していると見えますが、優れたアーキテクトはアジャイル開発チームをサポートするテクニックを見つけています。Streamingは、ストリーミングデータのためのSQLライクなインターフェースを提供します。Streamsによって、Redisがストリーミングデータを複数のプロデューサとコンシューマの間で消費、保持、配信することができるようになります。ソフトウェア開発のマニフェストたゆまず息もつかずに市場に突進することで、会社を静かに消滅の崖っぷちへと追い込みます。それは設計してコードを書く方法を再考する時です。簡単さへの投資は、速さへの投資です。簡単さは知的財産の主鉱脈でもあります。競争上の優位性は、一度失ったら、もう一度手に入れることはほとんど不可能です。Buytaerts氏が過去10年間にわたって、企業がDevOps採用のハイプサイクルをくぐり抜け、変革に対する誤解を解消する過程を支援してきた経験について語ります。Fireを見つけてから、冒険ジャンルに魅了され続けています。私にとって、冒険の特質は、捉えどころのないゴールを追求して、長くて危険な旅行に乗り出して、最終的には、いつもどおりに初めに発見したものより価値があって重要で、すごいものを見つける多彩な人物の一団に関する物語です。素晴らしいオズの魔法使いからロードオブザリングまで、私はそれらの話に夢中にならざるをえませんでした。私は、冒険をSOAに関する私の考えの進化に対する完全なメタファとして用い、ガバナンスに関する私の考えと業界で浸透しているそれとが何故違っているのかについて、若干の光を投じようと思います。2004年の秋、私はEAIとSOAプラットフォームの主要ベンダーで働いていました。当時、SOAは熱く、マーケティングでも製品はSOAでした。言うまでもなく、競合相手もそれらの販売についてはまったく同じことを言っていました。私たちが自身の領域をエンタープライズでの実現に広げれば広げるにつれ、マーケティングメッセージのすべてが正確というわけではないということが明らかになってきました。あなたが弊社製品を得て、私たちの方法論を採用し、ガイドラインやベストプラクティスに従ってそれらを実行した場合(私たちのプロフェッショナルサービスを利用したとしても)、最終結果はSOAではないでしょう。少なくとも、SOAではない方法となるでしょう。それが作られることで、特定の目的に機能し、役に立つでしょう。それは数年早く想定されたので、SOAの当初の目的を果たすことはほとんどないでしょう。SOAの考えになっていて、すべてのCIOの戦略プラン、RFI/RFP、製品機能リストについて、必要なものを順々につくりました。これは、私たちの製品の批評ではありません。私たちは、当時、他の人と同じようにそれをSOAと呼ぶ権利がありました。問題は、SOAの定義自身にあります。その考えが一般的になると、それを「完了した」と宣言しようと急ぐことがありました。するために、ベンダーとIT組織は、一様に、彼らのソリューションがサポートしているものをベースとした定義を微妙に変えました。結果として、すべての人がSOAを得たものの、ほとんどの人がそこからメリットを得られませんでした。した背景に対して、私のチームでは経験に基づいた質問を求めました。SOAが持つべきすべての不足点に関して誰も言うことができないであろうプラットフォームを構築するために何をしますか?私たちの答えは、40ページのホワイトペーパーにまとめられました。それには、企業クラスのSOAサービスの核となる特性とインフラをサポートしていると思われる内容を記述することによって私たちの考えを明示しています。アクセシビリティ、整合性、セキュリティ、などを含んだ、公開され、検証可能で、実施可能なサービスの品質(QOS)関連スポンサーコンテンツこの一覧は、私たちにSOA製品と実装に関する成熟度と完全性を評価するためのきちんとした基準も与えています。私たちの主要製品に適用してみると、どういった人がコードを所有したいかによって、それは40±5%となりました。して、再考することなく、私たちは「残りの60%」を構築しようとしました。2005年の秋にリリース1.0までの間、そう呼ばれていました。いったものを作り始めるにつれ、私たちはいくつかの指標を見逃していたことに気づきました。19の核となるSOAの指標は、17のものと同じくらいの素晴らしい響きを持っていなかったので、私たちはそれらを外見ベースのSOA基盤の考えの上に最初に遭遇するものとして、「17+」と呼ぶことにしました。その前提には、何故私たちが、エンタープライズのためのコンピュータプラットフォームとして適切なものにするであろうSOAサービスの特徴のすべてをあげることができなかったかという根本的な理由がありました。その理由は、これらの指標が実際のビジネスをベースとして規定され、時とともに業界、場所、クライアントからクライアントへ、そして最も重要なのは、時間がたつにつれ変化する運命にある別の要求をベースにしているところにありました。市場が必要としていたことは、自由裁量に近いサービス指標のセットを実現・支援するためのプラットフォームであり、ユーザーが思いつきでサービスの追加・変更・削除をすることができることでした。適切に言えば、現在のビジネスにとって重要なことをベースとしていたことです。この非常に基本的な考えは、私たちのまさに最初のクライアントとの出会いで有効となりました。そのクライアントは国防軍で、まさに軍部基準の非常にこだわりのあるもので、セキュリティ要件の長いリストが出来上がりましたが、そのほとんどが私たちが直接サポート可能なものか、彼ら独自のセキュリティ基盤に任せることのできるものでした。私を驚かせる一つの要求がありました。それは、クライアントが、合法的で、きちんと認証され、正当に許可を得ているが十分な確認をしていないのユーザーによって、知らないところで、不十分に書かれたサービスを機密情報が明らかになる可能性を防ぎたいというものでした。私の最初の反応は、有能な開発者を雇い、完璧なQAをし、そして、なんとかなります!でした。そのとき私が実感したのは、クライアントの視点では、予見できない漏えいの脅威に対処するのは、業界の他の人たちも注意を払う責任があると考えるであろうすべての他のサービスの指標と同じくらい重要なことなのです。次に、私たちは、クライアントへ行く途中でサービスのレスポンスをチェックする検閲の観点について設計しました。メッセージや個々の断片の分類レベルを決定し、認証の間利用可能となっているプロフィールからクリアランスレベルでそれを比較し、必要な修正措置をとり、部分的な難読化から完全な傍受にわたりました。リリース1.0の一方で、マーケティングは名前を必要としました。奇妙な理由のために、彼らは「残りの60%」のまわりでキャンペーンを始めるのに熱心でありませんでした。表しています)をいじった後で、おそらく当時のキャッチフレーズであったことから、ある人がガバナンスを持ち出しました。私は、当時、その言葉をよく知らなかったので、ちょっとググってみましたが、私が開発した技術と関係があることとはどうしても理解できませんでした。私の主たる関心事には、明確な定義と不明確なそれがなかったということです。その分野の大部分のベンダーは、SOAガバナンスを単純に「私たちができること」として定義しました。Systinetは、WSDLのための記録システムであるという考えを押していて、分類法、公開ワークフロー、サブクリプション/ノーティフィケーションのメカニズムに関連したものをサポートしていました。AmberPointは、それをautodiscoveryに依存した「良くないサービス」、軽量なセキュリティや監視、エンドツーエンドの故障解析であると見ていました。アプライアンスベンダーは、ガバナンスをWebサービスセキュリティが彼らが持っているすべてのメディエーション機能を加えるものとして見ていました。専門家は、下記のOASISのSOA参照モデルのように、謎めいてはっきりしない定義となっていました。それは、Pythia(ピュティア)を誇り高くするでしょう。SOAガバナンス:構造化された関係、手順、方針を通じた、予測可能な前提条件と期待されるものと一致した管理結果の方法や規律が、組織や異なる所有者ドメインの統制下であるかもしれない分散された機能の利用に適用されることそれにいくらかの検討を加えた後に、私はこれらすべての背後に基礎をなす象が必要である(※1)(リンク)と実感し、それを定義しようと試みました。本稿の残りで、結果として起こるSOAの特徴を定義するものとしてSOAガバナンスの考えについて説明しようと思います。寓話の象を引き合いにしています)SOA全体の問題領域が、あいまいな専門用語に苦しめられているので、私たちはいくつかの重要な定義を明らかにすることから始めることにします。はじめに、私たちは統制するとは何かから始める必要があります。その答えは一目瞭然のように思われます。この用語は、非常に多くの異なることを表現するのに使用されていて、そのほとんどがSOAとは関係のないものです。私は、あることを明らかにするのに、通常、資格があるかによってそれをおこないます。エンタープライズサービスは、機能でない、ポリシー駆動な特性(セキュリティ、業界/顧客が定義したサービスポリシー、管理、モニタリング、ライフサイクル管理)の拡張可能なセットと結合し、自己の閉じ込められたコンポーネントを配布するビジネス機能です。それは、明確に、標準化され、公開されたインターフェースによるリクエストに対処します。エンタープライズサービスを説明するもう一つのものは、次の通りです。名称がCEOやビジネスオーナーの人たちに知られているサービス。後者はそれが何をしたかに関心があります。saveLogRecord(ログレコードの保存)は、明らかにその資格がありません。この定義に照らして、SOA自身は、次のように説明することができます。エンタープライズサービスのエコシステムに向かって、エンタープライズITの進化を与えて手助けをするためのアーキテクチャスタイルそして、最終的にはSOAガバナンスは、単純に次のようになります。するための手段を提供するプロセス、慣習、ツールの組合せ。これらの定義によると、SOAガバナンスは、SOA参加者の制御の分野を超えた信頼できる再利用を許可することによって、エンタープライズサービスをデジタルなアーティファクトから真のビジネス資産に変えることです。この要約をよりやさしいものとするために、仮定に基づいた例を説明させてください。Incを想像してください。その会社は2つのビジネス単位(部門)を持っています(ロールパン調査部門とソーセージ開発部門)。それらには、別々の管理、P&L責任、IT部門と予算がありますが、同じ企業体の中で機能します。あるとき、ロールパン研究のリーダーは、自身のコアビジネス機能を実行する想定の新しいアプリケーションを実装することを決定します。彼らがそうすることで、100万ドルの費用がかかりますが、善良な企業市民となり、彼らは新しく開発した機能を再利用可能な形式としてパッケージ化するために、さらに$50kを費やします。企業全体の利益のためにそれを公開します。次の年、ソーセージ開発の管理者は、自身のコアビジネスを実行するための新しいアプリケーションを構築する必要があるということを実感します。このアプリケーションには、開発、パッケージ化、デプロイされ、6か月早くロールパン調査部門の好意により彼らが利用できるようになった機能がまさに必要でした。ソーセージ開発のITは、今、それらのサービスを再利用するか、新たに100万ドルを投じてスクラッチから機能を(再)開発するかのいずれかを選択します。私は、基礎をなす技術がCORBAや統制されていない(上記の定義を参照)SOAであるならば、ソーセージ開発の管理に対する責任を伴う唯一の行動方針は、彼らのドメイン制御の範囲内で要求された機能を実装するために、あえて資金を投じることです。理由は、次のとおりです。元のサービスは実装され、ロールパン調査部門によってホストされているので、機能的な観点で100%一致しているとしても、ソーセージ開発部門には以下の要素を知る術がありません。それらのすべてが、ソーセージ開発部門のビジネスコンテキストの中でサービスの使いやすさを決定するのに不可欠なものなのです。異なるのか?サービス利用はどのように計測されて計上されるのか?仮にソーセージ開発部門の管理者が、ロールパン調査部門内の中の対をなすものからこの情報のすべてを調査したとしても、重要な問題が一つ残ります。それは、私たちがこれらすべてが来週(来月、来年)に変更の予定がないということをどうやって知りますか?思考プロセスが完了し、上記のSOAガバナンスの考えが具体化したとき、いくつかの事項が明らかになります(少なくとも私たちに)。アインシュタインの相対性理論が、ニュートンの古典力学を後の人が適用できなかった領域に拡張した手法と同様に、SOAガバナンスに関する統合された考えを否定するものではないですが、そのかわりに、上記で述べた断片化した定義やアプローチを構築します。考え方」に詳細を記載しています(リンク)。適切に実行されたこの考えは、先に記述したエンタープライズSOAの17+の核となる指標の全てに適合可能なソリューションを生み出すでしょう。そのようなソリューションは、不完全なSOAプラットホームと今日の実行例をとって、それらを独自の考えを実現した真のサービス指向アーキテクチャに変える可能性があり、期待されたメリットのすべてを生み出す可能性があります。結局、このガバナンスプラットフォームの構築は、私たちが考えたより簡単なことがわかりました。ここまで冒険形式で説明したように、私たちは多くの予測できない有益な発見をしました。委任されたガバナンス、時間分析のガバナンス、使われなくなったものにやさしいガバナンス、統一されたガバナンス情報モデル、それらすべてが今後の記事の素晴らしいトピックとなるでしょう。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見るあなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。登録するとさまざまなことができます。アカウント登録をしてInfoQをお楽しみください。あなたの意見をお聞かせください。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見る様々なイノベーターとアーリーアダプターがお送りするテクノロジーの概要を見る。自分がまだ知らないことに気づいていないと知るあなたが興味のあるトピックスをいつでも最新な情報に。あなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。よい世界へ私たちが暮らす世界を大切に思い、よりよいものにしたいと考えています。人のためのソフトウェア開発を加速し私たちのミッションを実現することで、この思いを成し遂げようとしています。私たちは利益の1%をさまざまな慈善団体に寄付しています。会社として、また従業員として、そうしたことの価値を強く信じているからです。with.プライバシーBTあなたのプロファイルは最新ですか?プロフィールを確認してアップデートしてください。アドレス*Eメールを変更すると確認のメールが配信されます。会社名:現在の会社名をご入力ください。Other組織規模:現在の組織規模をご入力ください。2,501+国:現在の国を設定してください。Zimbabwe都道府県:現在の都道府県に設定してください。次の都道府県にアップデートする:ニュースレターを購読しますか?インダストリーメールを購読しますか?本Eメールに登録すると、以前より関心のあったトピックの関連情報をお送りする場合がございます。詳細はこちらのプライバシーポリシーをご覧ください。newsletter?新しいメールアドレスに確認用のメールを送信します。このポップアップ画面は自動的に閉じられます。