問題タブ [enterprise]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
delphi - Delphi 用の「メッセージ バス」パターンのオープン ソース実装はありますか?
このエンタープライズ統合パターンの実装を探しています
http://msdn.microsoft.com/en-us/library/ms978583.aspx
より一般的な方法で説明する
http://www.eaipatterns.com/Messaging.html
Delphi 用の「メッセージ バス」(またはメッセージ キュー)パターンのオープン ソース実装はありますか。
web-applications - Web アプリケーション フレームワークの独自機能
Java/Ruby/Python/PHP などに基づいたWeb アプリケーション フレームワークは数多くあります。個々のフレームワークに固有の機能を発見、比較、対比することに熱心です。
フレームワークのどの機能が便利だと思いますか? また、知っておくことが重要な理由は何ですか?
例えば
- ストライプ: FlashScope - Flash スコープは、セッションを一時的に使用して 2 つの要求間の情報を保存できるため便利です。URL パラメーターとして情報を入力するか、使用後にパラメーターを削除するカスタム ロジックを実装する代わりの方法。
http://stripes.sourceforge.net/docs/current/javadoc/net/sourceforge/stripes/controller/FlashScope.html
投稿ごとに 1 つの機能に制限してください。
概要:
- ストライプ - フラッシュ スコープ
- Django - テンプレート内の JSON 化された変数
- Symfony - モデル生成。バックエンド管理の生成
- Grails - GORM 形式の強力な ORM
- Seaside - リレーショナル データベースはなく、OO をコーディングするだけ
- シナトラ - ミニマリズム
- Spring Web Flow - フローとビューのスコープ
search - 異なるデータソース全体を検索するための戦略
私は、いくつかの属性に基づいて人々を検索するツールを構築しています。これらの属性の値は、複数のシステムに分散しています。
例として、dateOfBirthはシステムABCの一部としてSQLServerデータベースに保存されます。その人の販売地域の割り当ては、いくつかの恐ろしいレガシーデータベースに保存されています。その他の属性は、XMLWebサービスを介してのみアクセス可能なシステムに格納されます。
さらに悪いことに、レガシーデータベースとWebサービスは非常に遅くなる可能性があります。
これらすべてのシステムに検索を実装するには、どのような戦略とヒントを検討する必要がありますか?
注:私は回答を投稿しましたが、それが素晴らしい回答であるとは確信していません。他の誰もより良い洞察を与えない限り、私は自分の答えを受け入れるつもりはありません。
search - アドバイスを求めるエンタープライズサーチエンジンの開発
いくつかの内部サーバーのすべてのWebページにインデックスを付けることができるエンタープライズ(イントラネット)検索エンジンを展開または開発し、Googleがイントラネットに対して行っていることと同様に、関連するすべてのコンテンツを表示する検索ポータルを用意するように求められます。
迅速に開発または展開する方法についてアドバイスはありますか?Microsoft FAST製品について聞いたことがありますが、それがこの目的のためであるかどうかわかりませんか?
よろしくお願いします、ジョージ
soa - DRY原則と依存関係の最小化のバランスをとる方法は?
私は、DRY 原則 (Don't Repeat Yourself) に問題があり、Rete ルール エンジンを中心に展開する依存関係を最小限に抑えています。
大規模な IT 組織のルール エンジンはエンタープライズになる傾向があります (大文字の「E」に注意してください。これは深刻なビジネスです)。すべてのルールは一度だけ表現され、ナイスで DRY であり、高価なルール エンジンに集中化される必要があります。グループはルール エンジンを維持し、ルール セットの管理者です。
その IT 組織がアメリカの保険会社の一部である場合、多くの規則が存在する傾向があります。すべての州と製品に適用される規則がありますが、各州は製品ごとに独自の法律を展開する傾向があるため、規則はこれらの癖を反映する必要があります。カテゴリは多数あります: 保険数理、保険引受、さらには第三者機関からの信用および自動車のレポートの注文などです。
設計の観点から私が抱えている問題は、ルールと処理を集中化することは確かに素晴らしく DRY ですが、コストがかかることです。
- 中央に配置されたルール サービスにアクセスして結果を返すための追加のネットワーク ホップ。
- ルール エンジンが SOAP Web サービスとして公開されている場合はさらに複雑になります。消費者は SOAP 要求をパッケージ化し、応答を OXM して自分のドメインに戻す必要があります。
- ルール エンジンを維持する企業グループ、ルールを設定および維持するビジネス、ルールを使用する開発者の間の追加のインターフェイス。
- 追加の複雑さ - データ駆動型のソリューションで十分な場合があります。
- 追加の依存関係 - 独自のルールを制御できないコンポーネントは、テスト、展開、リリースなどのために、ルール エンジンの外部依存関係について心配する必要があります。
これらの問題は、他の多くのエンタープライズ テクノロジ (B2B ゲートウェイ、ESB など) で発生します。
同じエンタープライズ グループも、SOA を基本原則として宣伝しています。しかし、適切なサービス設計についての私の理解では、それらはビジネス スペースを並べて表示し、冪等、独立、および分離する必要があります。ルールが別の場所で維持されている場合、サービスはどのように独立して分離されているのでしょうか?
ルールが孤立した状況でのみ適用されることを示すことができる場合、依存関係を排除することは集中化よりも優先されるべきであると主張して、私は単純さの側で誤りを犯したいと思います. 議論がその日に勝つかどうかはわかりません。
だから私の質問は:
- 中央集権化と独立性の議論のどこに当てはまりますか?
- ルール エンジンなどのエンタープライズ ツールの使用経験は?
- どうすれば孤立の主張をより強くすることができますか?
- 私の見解が間違っているとすれば、中央集権化を支持する理由は何ですか?
java - エンタープライズJava/.Netプロジェクトでは、すべての開発者がクラスパスにすべての依存関係を持っていますか?
大規模なJava/.Net Enterpriseプロジェクトでは、すべての開発者がビルドするために、クラスパス/ローカル開発環境にすべてのコンポーネント/ライブラリ/依存関係を持っている必要がありますか?
または、それらを小さなセクションに分割して、個別に構築することができますか(すべての依存関係を参照する必要がないように)?
つまり、アプリケーション全体を実行する場合は、すべてのコンポーネントが必要です。ただし、アプリのサブセットのみを実行している場合は、対応するコンポーネントのサブセットのみが必要になります。
大企業プロジェクトは通常、最初の方法で編成されていますか、それとも2番目の方法で編成されていますか?
考えられる編成は、自己完結型であるが他のモジュールによって参照されているプロジェクト全体のモジュール(つまり、依存関係ツリーのリーフノード)で作業している場合です。
もう1つの構成は、使用するクラスを動的にロードする場合、クラスパスにクラスを含めずにビルドできることです。それを実行するには、クラスパスは実際にロードしたものにアクセスするだけで済みます(プロジェクトのさまざまな部分を形成し、ロードしないものが他にもたくさんある場合があります)。
これらは理論上の可能性です。しかし、実際には、エンタープライズプロジェクトの標準的な方法は何ですか?
同じ問題がそこで発生すると思うので、これを.Netを含むように拡張しました(DLL地獄?)
enterprise - エンタープライズアプリケーションの場合、毎日または100%の稼働時間で再起動しますか?
かなり自由形式の一般的な質問があります(つまり、「プラットフォーム、アプリケーションタイプなどによって異なります)が、答えとして一般的なガイドラインを探しています。
継続的な運用(100%の稼働時間)とスケジュールされた毎日のシャットダウン/再起動のアプリケーションを設計することが望ましいのはいつですか?
明らかに、Webアプリは常に稼働している必要があるため、この質問では、会計システムなどの内部エンタープライズアプリケーション、または平日の営業時間中にのみアクティブに使用されるB2Bシステムについて説明していると想定します。
私がそれぞれについて聞いた議論は次のとおりです。
Pro 100%稼働時間:「アプリケーションを実行した後は、シャットダウンしても再起動しない可能性があるため、アプリケーションを稼働させたままにしておくことをお勧めします。」
Proは毎日再起動します:「3年間継続して稼働しているアプリケーションは、いつかダウンする可能性があり、誰もそれをオンラインに戻す方法を知りません。」
その他の考慮事項は、メモリの増加、パフォーマンス、メンテナンスの必要性などです。これはプログラミングの問題です。これは、選択が技術設計に影響を与える可能性があるためです。たとえば、アプリケーションが毎日シャットダウン/再起動されることがわかっている場合は、特定のバッチジョブをコーディングして状態を毎日クリアする必要はありません。
考え?
python - 企業におけるPython:長所と短所
私は、商業銀行の分野でのミッションクリティカルな作業のためにPythonでアプリケーションを調査および開発してきました。
銀行は、新しいアプリケーションを選択する際にかなり保守的です。
安定性や他の人が使用していることの本当の証拠が必要です。
Pythonサイトを見てきましたが、この群衆が私にもっと教えてくれることを願っています。
これまでのところ、次の段階で必要となる開発銀行のパートナーがいないため、証拠と売り込みの情報を収集しています。すべてのヘルプとコメントに感謝します。
java - エンタープライズ Java システムにパッチを適用するためのベスト プラクティスは?
私が検索した限り、実稼働エンタープライズ Java システムにパッチを適用するためのベスト プラクティスのセットを 1 つも見つけることができませんでした。ある人がそれを黒魔術と呼んでいるのを聞いたことさえあります.
私の質問は、運用システムにパッチを提供するための定義済みのベスト プラクティスはありますか? 彼らは何ですか?そのような慣行への参照は、感謝して高く評価されます。
ありがとう、スティーブオ
authentication - エンタープライズSSOおよびID管理/推奨事項
SSOについては前に説明しました。最近の新たな展開を踏まえ、定義された要件で会話をさらに充実させたいと思います。
先週、私は次の重要な問題に対する答えを探して市場調査を行ってきました。
プロジェクトは次のようになります。
要件
- Webアプリケーション用のSSOソリューション。
- 既存の開発製品に統合します。
- ポリシーベースのパスワードセキュリティ(長さ、複雑さ、期間など)があります
- セキュリティポリシーは、Webインターフェイスを使用して管理できます。
- カスタマイズ可能なユーザーインターフェイス(パスワードプロンプトと共同画面)。
- 高可用性(99.9%)
- スケーラブル。
- RedHatLinuxで実行されます。
あった方がよい
- ユーザーグループとロールが含まれます。
- Javaで書かれています。
- 自由ソフトウェア(オープンソース)ソリューション。
これまでに出てきたソリューションはどれも「キラーチョイス」ではないため、いくつかのプロジェクト(OWASP、AcegiSecurity + X ??)をツール化することになると思います。したがって、このディスカッションを行います。
私たちは、フロントエンドとバックエンドのアプリケーションスイートを提供するISVです。フロントエンドはいくつかのモジュールに分割されており、自律ユニットとして機能する必要があります。クライアントの観点からは、彼は「アプリケーション」を使用します。これにより、SSOのグレードアップに関するこの議論につながります。
適切な解決策に関する経験とアイデアを共有していただければ幸いです。
いくつかの解決策は興味深い
またはより一般的に言えば、このリスト
ありがとう、マキシム。