はじめに
トレンドのモバイルアプリケーションの開発は、急速な技術開発によって促進されるという秘密をあなたに伝えません。モバイルデバイスは、あらゆる点で毎年向上し、幅広い人々がよりアクセスしやすくなります。 モバイルガジェット（スマートフォン、コミュニケーター、タブレット）を手に持っているほとんどすべての人が、ブラウザー、メール、インスタントメッセージングクライアント、ゲーム、ビジネス、金融プログラムなどのアプリケーションを使用しています。 また、多くのアプリケーションがリモートサーバーと対話することはユーザーから隠されていることが多く、インターネット経由でデータを交換します。
職業（Javaサーバーアプリケーション開発者）ごとに、チーム内のモバイルクライアント用のサーバーを開発する必要があります（過去2年間、外国企業向けにこのような3つのプロジェクトの実装に参加しました）。 この種の問題を解決するための一連のJavaテクノロジーが特定されています。これは、テクノロジーを選択する自由があなたに実験を許すため、要件と便宜性（言い換えれば、欲求）によって異なります。 形成された視点と経験をコミュニティと共有したいと思います。
必要条件
特徴は、サーバーアプリケーションとクライアントアプリケーションの両方に対して要件が形成されることであり、場合によっては相互接続されます。 最初に、データ交換メカニズムのコンテキストで基本的な要件を説明します。
•クロスプラットフォームクライアント：多くの場合、異なるプラットフォーム（Android、iOS、Windows Phoneなど）のサポートを提供することが重要です。顧客が1つのタイプのデバイスに満足することはめったにありません。
•パフォーマンス：ワークフローに十分な作業速度を提供する必要があり、グラフィカルユーザーインターフェイスでの快適な応答。
•単純さ：プロトコルのAPIが単純であればあるほど、コードの実装と保守にかかる時間が短くなり、開発者の資格が低下する可能性があります。
•効率：プロトコルの実装が複雑になるほど、モバイルデバイスが消費するリソースが制限されます。
追加の要件は、アプリケーションの詳細に依存します。
•サーバーのスケーラビリティ-理想的には大量の訪問者が予想されるSaaS、ソーシャルアプリケーションの場合、この条件は必須です。 ユーザー数に制限があるか、数が予測されるビジネスアプリケーションの場合、このプロパティは必要ありません。
•対話性：多数のアプリケーションに通知メカニズムを提供する必要があります。特定のイベントの発生についてアプリケーション（ユーザー）に通知し、ユーザーにメッセージを送信します。 たとえば、交換システムまたは自動タクシーディスパッチャにはこのプロパティが必要です。
•オープンAPI：サードパーティの開発者は、文書化されたプロトコルを通じてシステムの機能を活用できると想定されています。 結局のところ、クライアントはモバイルアプリケーションと外部サーバーアプリケーションの両方にすることができます。
•その他の要件...
チーム
システム開発のプロジェクトチームの構成は、理想的には次のとおりです。
•プロジェクトマネージャー：プロジェクトを管理、制御し、顧客と直接やり取りします。
•サーバーアプリケーション開発者：ビジネスロジックサーバー、データベース、ネットワークプロトコルを開発します。
•管理者アプリケーション開発者：Webアプリケーション、サーバーアプリケーションを構成および管理するためのユーザーインターフェイスを開発します。
•Android用クライアントアプリケーションの開発者。
•iOS用クライアントアプリケーションの開発者。
•のクライアントアプリケーション開発者...
•テスター：管理者アプリケーションとクライアントアプリケーションをテストします。
注意深い読者であれば、たとえばHTML5などのグラフィカルインターフェイスを使用してサーバーアプリケーションを作成すると、保存できることに気付くでしょう。 この場合、クライアントアプリケーションの開発は必要ありません-ユーザーインターフェイスはブラウザーを提供します。 この記事はそのようなケースを扱っておらず、モバイルデバイス用の「ネイティブ」アプリケーションを開発する問題です。
私は完全に補完してチームで働いてきましたが、それは現実的です-常に人的資源とは限らず、予算は私がそのようなチームを組み立てることを可能にします。 また、プロジェクトマネージャー+サーバーアプリケーション開発者、クライアントアプリケーション開発者+テスターの役割を組み合わせる必要がある場合があります。
技術、ツール、ライブラリ
モバイルクライアントサーバーを開発するには、通常、次の「無料」テクノロジーのスタックを使用します。
• Apache Tomcat-サーブレットコンテナ。
• MySQL -DBMS;
• Subversion-バージョン管理システム。
• Maven-プロジェクトのアセンブリを自動化するためのフレームワーク。
• JUnit- 自動化されたアプリケーションテストの有効性を確保します 。
• Apache Log4j-ロギングライブラリ。
• Jenkins-継続的インテグレーションのシステム。
• Hibernate -ORM（設定、プロパティの構成、xmlファイルおよび注釈）;
• hibernate-generic-dao -GoogleのDAO実装。データベースデータを操作するための基本的なメソッドを実装し、メソッドのフィルタリングとソートの実装を簡素化します。
• Spring-認証と承認（セキュリティ）の実装、サービスとBeanのコンテナ（xmlファイルと注釈の構成）。テストの作成時にも使用します。
システムの仕様とその要件に応じて、データ交換プロトコルを実装するために2つのオプションのいずれかを使用します。
クロスプラットフォーム、パフォーマンス、シンプルさ、効率、スケーラビリティ、オープンAPIが必要な場合、 Jersey -RESTful Webサービスの実装が必要です。 このライブラリにより、JSONまたは（および）XML形式のデータのシリアル化を使用できます。 REST構成は、アノテーションを介して行われます。 モバイルデバイスとの交換では、JSON形式が採用されました。これは、クライアント側での実装が単純であるためです（このため、「クラシック」Webサービスを使用しません）。 Jerseyを使用すると、最も適切な「外観」JSONに調整できます。
それ以外の場合、クロスプラットフォーム、高性能、シンプルさ、効率、対話性が必要な場合は、
• Apache MINA-ネットワークアプリケーションを作成するためのフレームワーク、
• Google protobuf-構造化データのエンコードとデコードのライブラリ。 データ構造は* .protoヘッダーファイルによって決定され、コンパイラはそれらからJavaクラスを生成します（他のプログラミング言語：クロスプラットフォームプロパティを提供するC ++、Objective-Cなどの生成の可能性もあります）。
•java.util.concurrent-標準パッケージを使用します。
このオプションは拡張できますが、ビジネスロジックを考慮して、アーキテクチャレベルの設計段階で配置する必要があります。
実際のSaaSサービスのテクノロジーを選択する例による仮想タスクを考えてみましょう。 「Auknem」サービスオークションでは、必要なサービスや仕事を実行するための注文を行い、組織は代わりに提案を残します。 デフォルトでは、すべての基本的な要件を満たしています。 このシステムへの登録は無料で無料であるため、それらにスケーラビリティを追加する必要があります。 そして、双方向性はどうですか？ 新しい注文の作成について請負業者（実行者）に通知し、電子メールだけでなく、アプリケーションで同時に受信した提案について顧客に通知することは素晴らしいことです。 これに基づいて、実装にApache MINA、Google protobufを使用します。 次のプロパティを見てください-オープンAPI。 このサービスは一般公開されているため、外部の開発者がこのサービスとの統合に関心があると仮定します。 ちょっと待って！ それほど単純ではありません。 Apache MINAに基づくプロトコルは、ニュアンスが透過的とはほど遠いことを知らずに実装と統合に非常に依存しています。 このような状況では、どちらの要因がより重要かを検討し、選択する必要があります。
おわりに
モバイルデバイスや同様のシステム用のサーバーを開発するときに使用したテクノロジとライブラリを知りたいですか？ すべてが変化し、永遠に続くものはありません。各レベルには、長所と短所を持つ選択肢があります。MySQL- PostgreSQL 、Subversion- Git 、Apache Tomcat- Jetty 、Apache MINA- Netty ...