なぜオートメーションを使用しないのか

セキュリティ

以下は上記のMicrosoftの記事からの直接引用です：“Officeアプリケーションはサーバーサイドでの使用を想定しておらず、分散コンポーネントが直面するセキュリティ問題を考慮していません。 Officeは着信リクエストを認証せず、またサーバーサイドコードから意図せずにマクロを実行したり、他のサーバーを起動したりしてしまいます。Webからサーバーにアップロードされたファイルを開かないでください！最後に設定されたセキュリティ設定に基づいて、サーバーは管理者やシステムコンテキストで完全な権限を持つマクロを実行し、ネットワークを危険にさらす可能性があります！また、Officeは多くのクライアント側コンポーネント（Simple MAPI、WinInet、MSDAIPPなど）を使用しており、クライアントの認証情報をキャッシュし、処理を高速化しています。 Officeがサーバーサイドでオートメーションされている場合、1つのインスタンスが複数のクライアントをサービスでき、セッションの認証情報がキャッシュされているため、1つのクライアントが他のクライアントのキャッシュされた資格情報を利用して非許可のアクセス許可を与える可能性があります。他のユーザーに成りすましたことで非付与されたアクセス権を得てしまう場合があります”

Aspose製品は非常にセキュアです。AsposeコンポーネントはすべてのASP.NETアプリケーションと同じユーザーコンテキストで、ASPNETユーザーの下で実行されます。したがって、Asposeコンポーネントは重要なシステムリソースに潜在的なリスクをもたらすことはありません。さらに、Asposeコンポーネントによってドキュメントが開かれるときに、マクロは自動的に実行されません。Asposeコンポーネントは、開発者がOfficeファイルを作成、操作、保存することを目的として構築されています。Microsoft Officeパッケージに関連するリスクは、Asposeコンポーネントには内在しません。

安定性

上記のMicrosoftの記事から直接引用します:“Office 2000、Office XP、およびOffice 2003では、インストールおよびセルフリペアのために Microsoft Windows Installer (MSI) テクノロジを使用しています。MSIは「最初の使用時にインストール」の概念を導入し、機能をランタイム中に動的にインストールまたは構成できるようにします (システム用またはより頻繁には特定のユーザ用)。サーバーサイドの環境では、これによりパフォーマンスが低下し、ユーザーにインストールの承認を求めるダイアログボックスが表示される可能性が高まります。Officeをエンドユーザー製品としての弾力性を高めるために設計されているものの、サーバーサイドの環境に向けては MSI の機能は逆効果です。さらに、Officeの安定性はこのような使用には設計されておらず、テストされていないため、保証されません。Officeをネットワークサーバーのサービスコンポーネントとして自動化する場合は、必要に応じて再起動できる重要な機能に影響を与えない専用コンピュータにプログラムを分離することをお勧めします。"

Asposeコンポーネントは1つのDLLにパッケージ化されているため、機能するために追加の部品や部品をインストールする必要はありません。Asposeコンポーネントは.NETアプリケーションだけで利用され、コンポーネントコードの部分が人間の応答を待つように設計されていることはありません。Asposeコンポーネントは徹底的にテストされています。AsposeコンポーネントはIBM、Hilton、Reader’s Digest、Bank of Americaなどの企業によって使用されています。

スケーラビリティ/スピード

上記のMicrosoftの記事から直接引用します:“サーバーサイドコンポーネントは、最小限のオーバーヘッドや高いスループットを持つ高度に再入可能な、マルチスレッドのCOMコンポーネントである必要があります。ほぼすべての点でOfficeアプリケーションはこれとは正反対です。Officeアプリケーションは再入不可、STAベースの自動化サーバーであり、単一のクライアント向けに多様でリソース集約型の機能を提供するように設計されています。それらはサーバーサイドソリューションとしてはスケーラビリティがほとんどありませんし、メモリなどの重要な要素には固定された制限があり、設定を介して変更することはできません。さらに重要なこととして、それらはグローバルリソース (メモリマップドファイル、グローバルアドインまたはテンプレート、共有自動化サーバーなど) を使用しており、同時に実行できるインスタンス数を制限し、マルチクライアント環境で構成されている場合は競合状態をもたらす可能性があります。同時に複数のOfficeアプリケーションインスタンスを実行することを計画している開発者は、「プーリング」またはOfficeアプリケーションへのアクセスをシリアル化してデッドロックやデータの破損を避けることを検討すべきです。"

Asposeコンポーネントは非常にスケーラブルで高速です。Officeアプリケーションは数百から数千のユーザーによって同時に使用されるように設計されていませんが、Asposeコンポーネントはその点において設計されています。当社のコンポーネントは、1つのアプリケーションを駆動する単一のサーバー上で動作する場合でも、企業全体のアプリケーションをパワーアップする負荷分散型Webファーム上で動作する場合でも、完璧に動作します。

価格

アプリケーションがMicrosoft Office Automationを利用する場合、アプリケーションを実行する各マシンのMicrosoft Officeのコピーを購入する必要があります。アプリケーションがOfficeファイルを作成または操作する必要がある場合でも、ユーザがOfficeを必要としない場合があります。Asposeは、無制限のユーザへの展開を可能にする非常に費用対効果の高いロイヤリティフリーの再頒布ライセンスを提供しています。

Webベースのアプリケーションを作成する際には、Microsoft Officeの自動化コンポーネントはサーバーサイドのソリューションに対して価格設定やライセンスがされていないため、Microsoft Officeコンポーネントを利用するWebアプリケーションのデプロイには良いライセンスソリューションがありません。Asposeはサーバーベースのアプリケーション向けに非常に費用対効果の高いソリューションを提供しています。

機能

AsposeコンポーネントはOfficeファイルを管理するために必要なすべてのものと、さらにもっと多くを提供します。それらは、開発者が最小限の作業で最大の結果を達成できるように設計されています。Officeの自動化とは異なり、Asposeコンポーネントは多くの強力で時間を節約する機能を提供しています。たとえば、Aspose.Cells では、開発者が DataTable や DataView から直接Excelファイルにエクスポートする機能を提供しています。Asposeファミリーの各コンポーネントは、それぞれ独自の一連のユニークな強力な機能を提供しています。

Asposeコンポーネントまたはコンポーネントスイートを購入する最大の利点は、開発チームにアクセスできることです。開発チームは、貴社が必要とする機能が他の企業にも必要とされる可能性が高いことを認識しています。すべての機能リクエストを追加できるわけではありませんが、チームは支援を提供する際に非常に柔軟でオープンな考え方を心がけています。この考え方がAsposeコンポーネントを現在のように強力なものに育てたのです。Officeの自動化オブジェクトから必要とする追加の機能がある場合、追加される可能性は非常に低いです。

結論

Apache POI SS HSSFおよびXSSF用のAspose.Cells Java