| Moriya 的个人资料hmoriya .net style 森屋...日志列表 |  工具  帮助 |
|
|
2007/10/17 Web Service Software Factory Final CTPWeb Service Software Factory Final CTPがリリースされています。
Tom Hollanderのブログにあるように次のEntlibのVNextも始まりそうです。
2007/4/6 Enlib 3.0 April20072007/2/28 アーキテクトセミナー終了昨日、無事にアーキテクト向けセミナーを終了しました。
午後一の2時間という長い時間と、アーキテクチャというやや難しい内容にも関わらず参加下さった皆様ありがとうございます。
マイクロソフトのアーキテクトの方も多数来場いただき、ありがとうございます。
アーキテクト向けと内容を承ったのでアーキテクチャの基礎、ソフトウェアファクトリまでを網羅して話しました。
年に一回くらい、アーキテクチャをまじめに勉強する機会があってもいいのでは、という気持でコンテンツを作りました。
まだ確定ではありませんが、MSDNにビデオ公開されるようなのでご期待ください。
2007/1/25 GAT & Enlib3.0マイクソフトのオンラインセミナーに行ってきました。
次回の講演でしゃべるので、打ち合わせを兼ねてお伺いしたのですが、大変有意義な時間となりました。
内容として、TechEdのリピートセッションと聞いていたのでが、GAX,Enlib3.0のABSFなどもスクラッチでデモし紹介されていました。
触っていない方には、すこし厳しいと感じましたが、個人的には素晴らしい内容で、重要性をもっと多くの皆さんに理解していただきたいと感じました。
西崎さん、市川さんのデモは素晴らしかったですよ。ビデオを撮っていたので公開されるかもしれません。
GATは、これからのVSのメインになるもので、重要と思うのですが、まだリリースされていたのが不思議。
一般の方が使うには、DSLより敷居が低いですが、まだ理解しづらいとはいえ需要。
これからは、フレームワーク職人よりアーキテクチャ＆GATでしょうね。
自動生成されるからといって難しいアーキテクチャを採用していけないです、これはVSでの自動生成も同じ。
１００万行のコピペは修正が不可能。ウィザード、テンプレートは重複の温床であることも、一方で忘れてはいけません。
平日の昼間なので、あまり人が集まらないかもしれませんが、次回は私の番です。
自分にプレッシャーをかける意味で下見にいきましたが、終わったあと講演された３人のアバナードの方といろいろ話できました。
課題、方向、意味を考える いい時間となりました。
大事なことは、もっと勉強して実践しなくてはいけないと改めて思いました。
テクノロジーを楽しめないとこの業界はつまらない。
2007/1/23 アーキテクトセミナーでお話します。https://www.event-registration.jp/event-profile/mses/courseoutline.aspx?courseid=CNET-001901 ご依頼を受けまして、アーキテクトセミナーで講演します、ご興味がある方はぜひご登録ください。 概要 80% のコードはアーキテクチャに依存していると言ってもいいくらい、開発はアーキテクチャに依存しています。また、最近ではアーキテクチャがトラブルの原因となることも確かです。「成功の鍵」は「アーキテクチャ」です。今回は、エンタープライズ・アプリケーション・アーキテクチャを設計される方を対象に、.NET アーキテクチャの最新動向、考え方を説明します。特に .NET 固有の特性、部品としての .NET 3.0、ソリューションパターン、ソフトウェアファクトリへの対応を中心に解説します。
日時：2007年2月27日(火) 13:30 ～ 15:30 (受付 13:00 ～) 会場 東京 新宿マインズタワー 15F （U.S.エデュケーションネットワーク 新宿本校 Room 4） 定員：80 名 対象： 2006/5/22 アーキテクトジャーナル 日本語中西さんのブログから
SAFで配られていたものと同じかもしれませんが、アーキテクトジャーナルがダウンロード可能になっています。
どの記事も興味深いのですが、このConnected Systemの記事(p33)移行は、ケーパビリティ、Motionについて書かれており、これからのマイクロソフトシステムを考える上では重要な概念になります。
なぜなら、これまでサービスをたくさん語る方がいましたが、サービスをモデリングすることは、いままでグレーゾーンでした。
7号だけなのか、7号から毎回なのかは不明です。
MSDNマガジンもかなり、がんばっていただいているのですが、同様にもっと充実していただけるとありがたいと思います。
2006/4/17 UIコンポーネント時代Nuke,ガジェット、ウィジェットと小さなUI組み合わせを表現可能な、プラットフォームが増えてきました。
UIの開発の高速化は、アプリケーション開発の高速化と一般化を促進すると思います。
Webサービスとの相性もよさそうなので、以前にブログで書いたサービスコンシューマのレイヤと捉えています。
コンポーネント、サービスの組み合わせが有効なのは、このパターンだと思います。
つまり、ＵＩコンポーネントとWebサービスという関係です。
これまで、エンタープライズ開発では、UIの再利用は、ほとんど議論されず、設計されず、実装者が再利用を自作で作っているケースが多かっただけに、しっかりと見つめる必要があります。
一方で、WF(Windows Workflow Foundation)でこれから始まるのは、アクティビティの再利用です。
ミドル層では、サービス、アクティビティ（イベント）ベースのデザイン、再利用が必要であることは、言うまでもありません。 2006/4/5 アーキテクチャスコープ最近、また新しいSOAのアーキテクチャの絵を、ある雑誌で見ました。
”一枚のアーキテクチャ図”ですべてを表現できないと以前ブログでも触れましたが、
アーキテクチャは、その対象としているスコープ（コンテキスト）が重要で、その説明もなしにアーキテクチャの絵に当てはめようとする傾向にあるようです。
もっと言うと、アーキテクチャには必ず戦略、あるいは目的とスコープがあります。
たとえば、データベースをオラクル、MSSQLと切り替えたいという場合に、PetShopのサンプルのようにファクトリで切り替えられるようになっています。PetShopは、なぜか、ビジネス層にこの仕掛けがありません。
そう、想定の範囲外なのです。ビジネス層も切り替えたいなら、この層もデータアクセス層と同じにしたでしょう。
マイクロソフトが提示しているアーキテクチャ図も同様で、すべてのパターンを飲み込んだ絵に過ぎず、当たり前ですが、自分たちが作ろうとしているとしているプロダクトは、どのような構成で作るべきかの”意図を伝えるデザイン”でなくてはなりません。この際、とりうるデザインの中で”削げるもの”は最大限削ぐようにしてほしいです。たとえそれが、虎の子のフレームワークだとしてもです。
最近よく見るアーキテクチャ図は、2つ存在するように思います。
1つ目は、これまでのアプリケーションアーキテクチャと
2つ目は、サービスを考慮したアーキテクチャです。
この二つは、混同しやすいですが、まるでスコープが違います。
アプリケーションのスコープとサービススコープがあるのです。
少なくとも、サービス指向で考えられたアーキテクチャとアプリケーションの特性を考慮したアーキテクチャが存在することを認識することが重要です。
アーキテクチャの意図とスコープの話でした。
ついでに、ソフトウェアファクトリでのアーキテクチャについても、少しだけ触れておきます。
上記と一緒に話すとさらに混同してしまいそうですが、ソフトウェアファクトリでのアーキテクチャは、複数のプロダクトファミリ（プロダクトラインから生成されるもの）の可変性を考慮したアーキテクチャを意味します。この、”複数の”という部分がポイントで、単体のアーキテクチャを設計するのとまったく違います。複数のプロダクトを生成する際の可変性を考慮して、デザインしていきます。
同じような製品だが、この部分に集中して要件が違うとか、この部分が何パターンか存在するなどです。意図は、可変性をどう捉えているかで、スコープは、プロダクトファミリになるのです。
また、スコープは、ドメイン特化したものとして再利用を目的としています。
アーキテクチャの3つ目は、ドメインに特化したアーキテクチャ図。
4つ目は、ドメインに特化したプロダクトラインのアーキテクチャ図となるのかもしれません。
2005/4/25 Enterprise Architecure Pattern から引用整理する意味を兼ねてエッセンスを著書：エンタープライズアプリケーションパターン はじめに から "私たちは、成功と失敗の両方を学ぶことでしか向上することはできない。" いわゆるフィードバック、経験の重要性です、アプリケーションの世界ではこの経験とフィードバックの積み重ねのキャリアの差は非常に大きく、また年収の差よりも離れていることが多いです。私が見てきたいわゆるエースエンジニアの方は、横串でトラブル案件をシュートしているケースが多く失敗の中からの脱出方法を知ってる方が多いです。そう、失敗してるプロジェクトに成功しやすい人がたくさんいるのです。ただ彼が口々言うことは、序盤の設計の問題点、まちっがた合意形成です。そして、システムとして一番怖いのは、運用では必要だったが、だれも気づかなかった機能です。後からどんどん機能が増えてきます。後から加わったエース方が最初に行うことは、動かない箇所のデバッグです。説明を聞いてもよく理解できずにコードデバッグに入ります。３，４日後、典型的な問題を抽出し問題解決にあたります。 もうひとつのエースの方は、いわゆるスワットチームのメンバーです。特殊チームを組み問題解決にあたります。火消しチームが、時間に追われ勉強できないのに対して、一時的なスポットを除いて比較的勉強の時間を持つことができ、新しい技術に対して積極的です。時として新しい技術、教科書通りの技術が問題を起こすこともあります。しかし、何回かの失敗をもとに修正をし、カレントの技術で一番いいものを取得していきます。重要なのは、学習と実践のスパイラルから得られる経験です。そういう意味でも、アジャイルは、最短で経験をつむことができる体系だと思っています。 他にもたくさんあると思いますが、私がお会いした典型的な２種類の例です。プロジェクトを成功させている異なるタイプの成功と失敗です。 改めて古典的でもっとも愛されいるレイヤー化のパターンについてここまで体系だてて整理しているファウラーを尊敬します。 System Definition Model (SDM) SDK分散システムデザイナーのキーモデルSDMのSDKがダウンロード可能になっています。VSも含めてDSIを主軸に置いた戦略をとっているマイクロソフトにとってSDMの重要性は言うまでもありません。ただ、SDMスキーマを確認する方はそんなに数はいないと思います、なぜならスキーマを必要とする人が少ないからです。利用する側は、モデル図のみでSDMの存在のみを意識すればよく、SDMのスキーマまではひつようないからです。メタ、メタ！ http://lab.msdn.microsoft.com/teamsystem/workshop/sdm/default.aspx 2005/4/19 UIP Application Block Version2.0UIPのバージョン2.0がダウンロード可能になっています。Software Factoryの題材にあがりやすい、UIナビゲーションです。 Downloadしたモジュールには、大きめのドキュメントとUIPのモジュールのMSIが入っています。 UIフローフレームワークを開発している方は、要チェックですね、私も待っていました。
2005/4/16 SAFで Web Services Interop資料http://simon.guest.members.winisp.net/ppts/japan2005/WebServicesInterop_JP.ppt 残念ながら参加できなかったMicrosoft Japan Strategic Architect Forum (SAF) 2005での日本語に翻訳されたPPTを公開されています。非常に現状のWebServiceに関する情報がまとまっていて参考になると思います。 XSDファーストなどは興味深い内容です。 一番気に入ったのは、NUnitよるテストを作成する点を紹介しているところです。もうこの流れは止められないのと、ほぼスタンダードになることを予感させます。 現状のWebServiceを整理したい方は、是非参照ください。
2005/3/9 SOAの見方 - その２昨日は、”SOAの今”を書きましたが、その中でステークホルダーによってビューが違いSOAの考え方が違うように見えると記しました。 すべての人（会社）の言っているSOAを理解するには、様々な人（会社、ステークホルダー）のビューを統合する必要があります。上、下、横、ミドル、インターネットと様々な視点が必要です。結局自分の理解しなければいけない視点でのSOAを理解していればいいのです。 その２では、サービスデザインの観点で見てみようと思います。私は、少なくとも２つ、Webサービスの実装を元に考えた利用とデザイン（アーキテクチャ）として捉えるSOAの視点があると思っています。 ボトムアップ的な考え方では、昨日の記述が近いのですが、トップダウンつまり大きな意味でコンポーネントとは、"開発者から見た利用単位"で、サービスとは、"利用者から見た利用単位"と言えます。1componet,1serviceと言えます・・ サービスの単位は、安定した粒度、つまりビジネスコンサルの言うプロセス（シェブロン）がふさわしいと言えます、それぞれビジネス上の責務があります。その意味でSOAの単位の粒度をディシジョンするお客様は、それなりの視点の高さを持った方になります。 お客様の部門、地位、会社の戦略によりサービス単位でとらえ、ビジネスを向上させることが重要なのかもしれません。経営層の方は、このサービスのトレーサビリティこそが会社を捉える重要な指標のひとつとなることでしょう。 開発者の積木と利用者の積木の大きさが違うのは仕方のないことかもしれません。利用者の積み木をコンポーネントでデザインする方が遙かにデザインが優しくなると考えます。A3に書いたモデル図をつなげて床に広げてデザインを考えるよりサービスの単位で理解して、デザインすることを想像してください。
2005/3/8 サービス指向アーキテクチャについて下記にSOAについての記述がされています。 http://www.microsoft.com/japan/msdn/architecture/journal/dnmaj/aj1soa.asp 以下SOAの抜粋です。 ・呼び出すことができる一連のコンポーネントであり、そのインターフェイス記述を公表及び発見することが可能。(W3C) ・アプリケーションの機能が、サービス コンシューマに関連のある粒度で公開される一連のサービスとして提供され、利用されるようにできるポリシー、プラクティス、フレームワーク。 サービスは、呼び出し、公開、発見することができ、単一で標準ベースの形式のインターフェイスを使用する実装から抽象化されます。 (CBDI) これまで、”SOAとは”と言った基本的な原則に関して大きな見解の相違がありました。各ベンダーの自社戦略のロードマップとしてのSOAであったからではないかと考えています。 もしかしたら大きな意味で同じ事を言っているのではないかと思います。プロットフォームベンダー、ミドルウェアベンダー、ＥＡＩベンダーによって自社の製品、あるいは戦略の過程でSOAを利用しているだけで、一見違う事を言っているようなSOAですが、それだけ大きな網（投網）からみたアーキテクチャを目指しているからだと思っています。 この記事で言っているSOAは、マイクロソフトの見解に非常に近い意見なのかもしれませんが、.NETを利用される方には、この見解でひとまず理解をしてもいいと思っています。 つまり、この記事の最後の方で書かれている”外部公開は、Webサービス、内部実装はコンポーネントを結びつけるアイデア”こそがエンタープライズSOAと言う説明です。ややボトムアップ的（歴史的）な解説ですが、現段階でわかりやすい説明と言えます。Enterprise SOA = Web Service + Component Base. もちろん、単にWebサービスの実装アーキテクチャと言う批判には何も言えません。 SOA の最適な実装アーキテクチャは、コンポーネント ベースのアーキテクチャです。 多くの人々がプロセスやエンティティ コンポーネントの概念に慣れていて、このコンポーネント アーキテクチャに継承される安定性と柔軟性を理解しています。これにより、ビジネス エンティティとコンポーネントの実装間に 1 対 1 のマッピングが提供されます。 エンタープライズ SOA (ESOA) は、2 つの主要な道筋、Web サービスと CBD (または CBSE) を結び付けます。その結果は、外部に対して使用可能な Web サービスと、内部使用向けに構築または指定された核となるビジネス コンポーネント サービスの両方に適用する、エンタープライズ SOA になります。 |
|
|
