https://plus.google.com/app/basic/stream/z12ld3fwhlnexv5b004cjv0oapmuflzrezc0k 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約5時間前 Steve Yegge (Amazon -> Google)が、Googleのプラットフォーム戦略が遅れていることを指摘した、2年前のかなり長いエントリーですが、その中で触れているAmazon時代のエピソードが興味深かったです。 Jeff Bezosは2002年の当時からプラットフォーム戦略の重要性をよく理解していたが、とにかくマイクロマネッジメントで強制力のある経営者だったとして、サービス指向アーキテクチャ(SOA)の採用を指示したときのエピソードを取り上げてます。 そこでJeffは命令をだした。
今年のゴールデンウィークにIBM Impact2013に初参加しました。3ヶ月以上も経過しています。今ごろ報告ブログを書きます。 公式情報は下記URLからたどれます。もっとも、このURLでは来年Impact2014に置き換わってImpact2013の情報が探せなくなりそうです。 http://www.ibm.com/impact IBMのサイトは昔から「変わらないURL」に対する意識が低いので困ります。ティム・バーナーズ=リー言うところのクールURI(“Cool URIs don’t change”)のかけらもありません。意識と言うより、使っているシステムのせいかもしれませんが。と言うのも、IBMサイトで裏にNotesを使っている場合のURLの醜さは救いようがないからです。上記URLの先は裏がNotesでは無さそうなので、少しマシなようです。 IBMの反クールURIの件は10年ぐらい前から
Sustainable Security Requirements with the ASVS Josh Grossman provides a brief overview of what the ASVS is, but takes a closer look at balancing trade-offs and prioritizing different security requirements. Josh shares how to make the process repeatable and how to implement it as part of your own organization's requirements process.
This post is about Domain Driven Design (DDD) and Service Oriented Architecture (SOA) and how the former can be used to build services for the latter. But it starts of in a few observations about current state of the union. The "DDD needs a database" assumption I've come to find it being a pretty common understanding that software systems using DDD building blocks have to be backed by a database,
SOAをやる際に一番悩ましいのは、サービスの粒度である。 細かすぎると、サービス間の連携が複雑に 大きすぎると、再利用性できない とうところで、ベンダーの方々は、こういう説明をする。 業務上の処理 = サービス この説明を聞いた瞬間、担当者としては、自分の会社の業務を思い浮かべて、 『あぁ、じゃぁ、大体こういう単位なのかなぁ』 と、一瞬納得した気分になる。 が、そうやって、思い浮かべるサービスの粒度は、同じ社内の担当者でも異なる(経験談) ましてや、業務の担当者が考える粒度はもっと細かいに違いない。 なので、私としては、 業務上の処理 = サービス は、こう言い換えられると思う。 サービスの粒度に法則なんて無い → お前の会社のサービスの単位なんてわかんねーから、そっちで考えてね 最近は、Oracle のAIA みたいにテンプレートを用意するなど、過去のノウハウから、ある程度の法則、テンプ
近年、ビジネス環境の変化が著しい。企業合併や事業部門の再編、統合などが相次ぎ、システムの適用範囲が拡大、縮小されると同時に、ビジネスプロセスも見直されるケースが多くなっている。また、こうしたドラスティックな変化を伴わないケースでも、事業の合理化、効率化の追求により、ビジネスプロセス自体が変化、拡張されるケースも少なくない。こうした時代にあって、システムが硬直的なもので変化に対応できないものであれば、システムが足枷となって、事業そのものの競争力が失われることになってしまう。ひいては、たちまち企業そのものの存亡に関わることとなる。 このため、今日のITシステムは、「変化に柔軟かつ迅速に対応できる」ことが求められ、かつ、それにかかるコストも、それまで使ってきたアプリケーションの再利用などにより軽減されることが望ましい。 システムアーキテクチャーが、大型汎用コンピュータに代表されるモノリシックな(
SOAの普及でアジアの中でも最下位とされる日本。なぜ、SOAが進まないのか? SOAによって効果的なシステム構築・運用を実現するにはどうすべきなのか? 「SOAアーキテクト塾」のパネルディスカッションをレポートする。 2008年12月、@IT情報マネジメント主催のセミナー「SOAアーキテクト塾」が都内で開催され、盛況のうちに幕を閉じた。本レポートは、セミナー後半のプログラム・パネルディスカッション「SOA導入の道とは?」を中心に、(1)SOAにおけるサービス粒度の設計方法、(2)プロジェクトを成功に導く体制作り、(3)SOAの効果の3点について、株式会社豆蔵 ビジネスソリューション事業部 シニアコンサルタントの岩崎浩文氏、日本オラクル SOAアーキテクト本部の岡嵜禎氏(モデレーターはブレインハーツ株式会社 谷川耕一氏)の考えをまとめていく。 サービス粒度の解は1つではない 谷川氏 サービス
SDNには非常に大勢のブロガーが活躍しており、日々記事が増えていきます。英語ばかりなので読むのも面倒なのですが、時々「あ、これは日本語で紹介したいな」と思うものに出合います。ただ、翻訳するのは更に面倒なので、記事一件あたりの文章量が少なく、有用で面白いものに絞って、紹介していきたいと思います。 原題 : 8 SOA mistakes architects should avoid 著者 : Bernhard Escherich, SAP Deutschland AG & Co.KG (顔写真は右上) 初出 : Posted on Feb. 22, 2009 02:13 AM 原文はこちら。 SOAの検討において、間違った方向の悲観的なアプローチがなされていることが、いくつかのブログから読み取れる。しかし、そういった意見は私にとっては非常な驚きである。私が仕事をさせてもらっている業界 - 公
以前、Microsoft、Apache Software Foundationのプラチナスポンサーにという出来事がありましたが、このたびMicrosoftがApacheプロジェクトにコードの寄贈を行ったそうです(本家/.、SDTimes)。 コードの寄贈を受けたのはApache Stonehengeと呼ばれるプロジェクトで、「W3CやOASISの標準プロトコルとして規定されている技術を用いて複数のプラットフォームの連携を行うサンプルアプリケーション群を開発する」のが目的。Microsoftの「Port 25」ブログにもこの件についてのMicrosoftからのコメントが述べられています。 個人的には特に衝撃を受けるほどのことではないと思ったのですが、海外サイトでは「MSがオープンソース!」ということで衝撃を受けている模様?
先週、海外のSOAコミュニティの話題を独占していたのは、リサーチ会社 Burton GroupのAnne Thomas Manesによるブログ エントリ「SOA is Dead; Long Live Services」(SOAは死んだ。サービス万歳) でした。 Burton Group Application Platform Blog > SOA is Dead; Long Live Services (by Anne Thomas Manes) (2009/01/05) (大元のブログ エントリ) http://apsblog.burtongroup.com/2009/01/soa-is-dead-long-live-services.html Burton Group Application Platform Blog > SOA Obituary: Misinterpretatio
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く