現時点では、我々は現在拡張して次のレベルに引き上げようとしている半RESTfulインターフェイスだけでなく、WSDLインターフェイスも備えています。WSDL、RESTなどを統合するためのJavaフレームワーク
メインアプリケーションは、Servlets + JSPとSpringを使用して実行されます。
考えられるのは、RESTとWSDLが設計されるAPIのインタフェースであるということです。これら（将来の潜在的なもの）は、単にクライアントがインターフェイスと統合できる方法です。
アンダースレイドAPIを実装するためのフレームワーク/メソドロジなどに関する提案や推奨事項があるのでしょうか？それとも、WSDLまたはRESTのどちらかと呼ばれるいくつかのSpring Beanを作成するのは意味がありますか？
希望は意味があります。
あなたのアプローチは理にかなっています。おそらく最も重要なアドバイスは、外部APIレイヤーを可能な限り薄くすることです。 Axis、Apache CXF、Jerseyなどを使用してRESTプロトコルまたはSOAPプロトコルの実装を処理できますが、これらのサービスの実装では、渡されたデータを共通の要求オブジェクトにロードし、それを別のサービスに渡すだけですリクエストを処理し、外部APIレイヤが正しいフォーマットにマーシャルするレスポンスオブジェクトを返します。
このアプローチは、類似のサービスを提供する競合他社があり、お客様が簡単に切り替えられるようにしたい場合に特に効果的です。競合他社を反映した新しい外部APIを構築し、その形式を内部APIモデルに変換するだけで、サービスが機能的に同等であれば、完了です。
Eunicateをご覧ください。それは素晴らしいです。あなたは春を使用しており、SpringはSOAPのサポートをしばらく持っており、Spring 3はREST（作成と消費）をサポートしています。
これは本当に遅い応答ですが、私はこのトピックについて別の見解を持っています。私たちが知っている伝統的な方法は、xmlをjavaにアンマーシャリングし、javaをxmlにマーシャリングすることです。しかし、wsdlが変更されると、コード内の構造的な変更になり、展開が再び必要になります。
上記のアプローチの代わりに、既存のストア内のwsdlに記載されているフィールドをリストする場合は、メモリにマッピングをロードし、これらのマッピングに基づいて構造を準備します。これにはあまり変更を加える必要はありません。既存のライブラリを使用する代わりに、アンマーシャリングとマーシャリングの設定可能なアプローチを取る必要があります。