Requires Platform version 4version 4.2 or earlier;
Not supported in version またはそれ以前のversionが必要
4.5 or higher またはそれ以降のversionではサポートしていない - for 4.5 Web Service support see Data Services
Web service is a software system designed to support interoperable machine-to-machine interaction over a network. With Nexaweb platform, you can invoke webservices from both the server side and the client side. Nexaweb leverages two aspects of using web services:
- The web services that will be used are not known at a development time.
- Use of the web services needs to take place on the client side, but the client can not have connectivity to the web service itself due to security concerns and firewall/network issues.
You can find more information from the API document in the comsupportはデータサービス を参照
Web サービスは、相互運用可能なコンピュータ間のネットワーク上でのインタラクションをサポートする目的でデザインされたソフトウェア システムです。Nexaweb Platform では、サーバーサイドとクライアントサイドの両方から Web サービスを起動できます。Nexaweb では、Web サービスの使用に関して次の 2 つの特徴が利用されます。
- 開発段階では、どの Web サービスが使用されるか判明していません。
- Web サービスの使用はクライアントサイドで行われる必要があります。ただし、セキュリティ上の懸念やファイアウォールまたはネットワークの問題により、クライアントは Web サービス自体への接続を持つことができません。
詳細については、com.nexaweb.server.webservices and および com.nexaweb.client.webservices package.
Two ways of using webserivces
Since a web service is usually running on a remote machine and the data types used by this web service might or might not be known in advance, you can access the web service data two ways:
1. Strongly typed usage, when you already know the data types at the compile time, you can call the methods directly in a strongly typed fashion at your compile time. For example, if the api.google.com provides a spelling suggestion web service and the service returns a GoogleSearchPort object as a service port, you can write code by directly calling:webservices パッケージ内の API ドキュメントで説明されています。
Web サービスを使用する 2 つの方法
通常、Web サービスはリモートコンピュータで実行されるため、この Web サービスで使用されるデータ型が事前に判明している場合と判明していない場合があります。そのため、Web サービスのデータにアクセスするには、次の 2 つの方法が使用されます。
1. 強く型付けされた方式: コンパイル時にデータ型が既にわかっている場合に使用します。コンパイル時に、強く型付けされた方法でメソッドを直接呼び出すことができます。たとえば、 api.google.com で正しいスペルの候補を表示する Web サービスを提供しているとします。このサービスが GoogleSearchPort オブジェクトをサービスポートとして返す場合は、次のようにコードを記述して直接呼び出します。
_googlePort.doSpellingSuggestion("mykey",
...
"pirimaid");
...
to get a spelling suggestion for the word.
2. Reflection usage, when you don't know or care much on the data type at the complie time, but you know the methods you want to call. Then for the same spelling suggestion service example, you would write:
...
この方法により、目的の単語に対する正しいスペルの候補が表示されます。
2. リフレクション方式: コンパイル時にデータ型が判明していないか、データ型をあまり問わないが、呼び出すメソッドがわかっている場合に使用します。正しいスペルの候補を表示する例では、次のようにコードを記述します。
Class[]
...
argsType
...
=
...
{String.class,
...
String.class};
...
Method
...
getSpellingMethod
...
=
...
getMethod("doSpellingSuggestion",
...
argsType);
...
Object[]
...
args
...
=
...
{"mykey",
...
"pirimaid"}
...
String suggestion = (String)getSpellingMethod
...
.invoke(_googlePortObject,
...
args);
...
Configuring a web service through nexaweb-webservices.xml Before configuring a webservice, you must know its Web での Web サービスの設定
Web サービスを設定する前に、WSDL (Web Services Description Language (WSDL) document location. WSDL is an XML format for describing network services. A WSDL document is published by the web service provider. If you don't know how to get it, check with the web service provider. It's typically a url, like this one ") ドキュメントがどこにあるか知っている必要があります。WSDL は、ネットワークサービスを記述するための XML 形式による仕様です。WSDL ドキュメントはWeb サービスプロバイダから発行されています。入手方法がわからない場合は、Web サービスプロバイダにお問い合わせください。通常の場合、http://apiwww.googlesoapclient.com/xml/GoogleSearchgoogleSearch.wsdl". To make sure your WSDL url is correct, you should try to link to the url from your browser and, you should see an xml file.The next step is to create a のような URL 形式となっています。WSDL の URL が正しいことを確認するには、使用するブラウザから目的の URL にリンクして、XML ファイルが表示されることを確認します。
次の手順では、アプリケーションの "WEB-INF" フォルダ内にある "nexaweb-webservices.xml" under your app's "WEB-INF" folder. You can add an entry like this:
...
を作成します。次のようにエントリを追加できます。
<?xml
...
version="1.0"
...
encoding="UTF-8"?>
...
<web-services>
...
<web-service
...
xmlns="http://nexaweb.com/webservices"
...
name="Google"
...
scratchDir="{0}/WEB-INF/WebServices/{1}"
...
wsdlUrl=">
</web-
...
In this setting, you only need to modify two attributes for your particular web service:
...
...
...
services>
この設定では、特定の Web サービスに使用する、次の 2 つの属性を変更するだけです。
- name - Web サービスとキーに与えられた名前です。Java コードで、WebServiceBroker から Web サービス ポートを取得するために使用されます。
- wsdlUrl - サービスを記述する WSDL ドキュメントへの URL です。これは、java.net.URL オブジェクトとして有効な完全修飾 URL でなければなりません。この属性は、"wsdlPath" 属性と共に使用することはできません。どちらか 1 つのみを指定できます。
- scratchDir - この属性を変更する必要はありません。この属性は、java.io.File オブジェクトに対する引数として使用される java.text.MessageFormat 文字列です。WebService ソースおよびクラス ファイルのディレクトリとして順に使用されます。この MessageFormat に渡される引数は次のとおりです。
{0} - ServletContext.getRealPath("/") 、{1} - The logical name of the web services
...
- Web サービスの論理名
また、wsdlUrlでは次の設定も行われます。
- wsdlPath - the path to the WSDL document describing the service This path is relative to your web application context. (e.g. - サービスを記述する WSDL ドキュメントへのパス。このパスは、Web アプリケーションのコンテキストへの相対パスです (例: /WEB-INF/weather.wsdl). Keep in mind, it's mutually exclusive with wsdlUrl attribute.
Web service classes needed for compilation and runtime
Compilation time requirement.
When you choose the reflection usage, at the compilation time, you need only the classes required for developing a standard Nexaweb application. The web service data type will be discovered at runtime.
When you choose the strongly typed usage, you need a set of classes to compile your application. Nexaweb platform has automated most of the steps for you to generate these classes. However, you still need some manual steps to put them together.
The steps to pull out these classes are:
...
- 。このパスは、wsdlUrl 属性と共に使用できないことに注意してください。
コンパイル時および実行時に必要な Web サービスのクラス
コンパイル時に必要な条件
コンパイル時にリフレクション方式を選択する場合に必要なクラスは、標準的な Nexaweb アプリケーションの開発に必要なものだけです。Web サービスのデータ型は実行時に判明します。
強く型付けされた 方式を選択する場合は、アプリケーションのコンパイルにクラスのセットが必要です。Nexaweb Platform では、このようなクラスを生成する手順のほとんどが自動化されています。ただし、これらを統合するにはいくつかの手順を手動で実行する必要があります。
これらのクラスを取り出す手順を次に示します。
- "nexaweb-webservices.xml" and put the file under the WEBを設定して、WEB-INF folder.
- Deploy your application before writting any strongly-typed web service code.
- Launch your application, Nexaweb webservice servlet will automatically generate these classes in the folder you defined in the scratchDir.
- By default, when using the above defined フォルダにこのファイルを配置します。
- 強く型付けされた Web サービスのコードを記述する前にアプリケーションをデプロイします。
- アプリケーションを起動します。Nexaweb webservice サーブレットは、scratchDir で定義したフォルダにこれらのクラスを自動的に生成します。
- 上記の定義済み nexaweb-webservices.xml , you will see a folder structure similar to the following (you need to have valid name and wsdlUrl first):The name you provide, in this case, 'Google' will be used as a folder name in which to put these classes.を使用すると、デフォルトで次のようなフォルダ構造が表示されます (まず、有効な name と wsdlUrl が必要です)。
- この場合で指定する名前 'Google' は、これらのクラスを配置するフォルダ名として使用されます。
WEB-INF/WebServices/Google/classes
/AxisClasses
/ClientClasses
/ServerClasses
The classes under the /ClientClasses are the ones required at the client compilation time. The classes under the /ServerClasses are the ones required at the server compilation time. Make sure these classes are in the classpath when you compile strongly-type usage codes using this web service.
Runtime requirement
The runtime requirements are the same for both the reflection usage and the strongly-typed usage. By default, everytime you launch an application with a valid nexaweb-webservices.xml, these classes will be generated once, and you don't need to explicitly put them into the runtime classpath. This is different from compilation requirement where you need to have the classes and put them into the classpath first before compiling the code. This guarantees you will always get up-to-date proxy classes and the data types at the runtime.
In the above strongly-typed compilation requirements, we talked about
/ClientClasses
/ServerClasses
they are also required at runtime regardless of the usage. There is another folder
/AxisClasses
that is also required at runtime. This is where Nexaweb uses the Axis library to generate the proxy classes for the web services support.
The classes listed in /AxisClasses and its dependency, the Axis libary, will be reserved and only loaded by the Nexaweb private classloader at the runtime. If you need to use other Axis libraries, you do not need to worry about any incompatibility issues.
Examples
The following web service sample codes are almost the same and fit running on the client side or the server side usage. There are only two differences to be noted.
1. To get the WebServiceBroker, on the server side, you can call:
| Code Block | ||||
|---|---|---|---|---|
| ||||
//Get the broker through ServiceManager on the server side
WebServiceBroker broker = ServiceManager.getWebServiceBroker(); |
On the client side, you can call:
...
| language | java |
|---|---|
| linenumbers | true |
...
フォルダ内のクラスは、クライアントでコンパイルを行う際に必要です。/ServerClasses フォルダ内のクラスは、サーバーでコンパイルを行う際に必要です。この Web サービスを使用して強く型付けされた方式のコードをコンパイルする場合は、これらのクラスがクラスパスにあることを確認してください。
実行時に必要な条件
実行時に 必要な条件は、リフレクション方式および強く型付けされた方式と同じです。有効な nexaweb-webservices.xml を持つアプリケーションを起動するたびに、これらのクラスはデフォルトで一度生成されるため、これらのクラスを実行時のクラスパスに明示的に配置する必要 はありません。この点は、コンパイル時に必要な条件と異なります。コンパイル時の場合は、コードをコンパイルする前にクラスを持っていて、それらをクラス パスに最初に配置する必要があります。これにより、実行時には必ず、最新のプロキシクラスとデータ型が常に取得されます。
強く型付けされた方式のコンパイル時に必要な条件では、次のフォルダについて説明しました。
/ClientClasses
/ServerClasses
これらのフォルダは、使用する方式に関係なく、実行時にも必要です。また、次のようなフォルダもあります。
/AxisClasses
このフォルダも実行時に必要になります。Axis ライブラリを使用して Web サービスのサポート用にプロキシクラスを生成する場合に使用されます。
/AxisClassesとそのサブフォルダに表示されるクラス、Axis ライブラリは予約され、実行時にNexaweb の非公開クラスローダーによってのみロードされます。その他の Axis ライブラリを使用する必要がある場合、互換性について心配する必要はありません。
例
次に示す Web サービスのコード例はほとんど同じで、クライアントサイドまたはサーバーサイドでの実行に適しています。注意すべき相違点は次の 2 つだけです。
1. WebServiceBroker を取得するには、サーバーサイドで次の呼び出しを行います。
// サーバーサイドで、ServiceManager を使用してブローカーを取得します。
WebServiceBroker broker = ServiceManager.getWebServiceBroker();
クライアントサイドでは、次の呼び出しを行います。
// クライアントサイドで、ClientSession を使用してブローカーを取得します。
WebServiceBroker broker = clientSession.getWebServiceBroker();
2. When the code is running on the server side, you need to make an additional call to disover the web service.
...
| language | java |
|---|---|
| linenumbers | true |
...
サーバーサイドでコードが実行されている場合は、追加の呼び出しを行って Web サービスを検出する必要があります。
// Web サービスの検出、Java クラスの記述、クラスのコンパイルとロードを行います。
// この呼び出しはサーバーサイドでのみ使用できます。
broker.createWebService(
...
name,
...
wsdlUrl
...
);
Also, make sure the runtime required classes are generated in the appropriate client and server classpaths even if you don't have to configure them.
Strongly-type usage example
In strongly-type usage case, besides runtime requirement classes, make sure you compile your code with the client or server's compile time required classes in the compile paths.
...
| language | java |
|---|---|
| linenumbers | true |
...
また、実行時に必要なクラスがクライアントとサーバーの適切なクラスパスに生成されることを確認してください。このようなクラスを設定する必要がない場合でも同様です。
強く型付けされた方式の例
強く型付けされた方式では、実行時に必要なクラスに加え、クライアントまたはサーバーのコンパイル時に必要なクラスを使用して、コンパイル用のパスでコードをコンパイルするようにしてください。
// クライアントサイドまたはサーバーサイドのコードに基づいて、まずブローカーを取得します。
String wsdlUrl = "http://
...
...
...
...
String
...
name="GoogleWebService";
...
//
...
サーバーサイドのみの呼び出し
//
...
broker.createWebService(name,
...
wsdlUrl);
...
// この呼び出しで、Web サービスのメソッドで使用可能なポートを
// 取得します。
GoogleSearchPort googlePort = (GoogleSearchPort)broker.getServicePort(name);
...
String
...
pyramid
...
=
...
googlePort.doSpellingSuggestion("myKey",
...
"piramid");
...
//
...
ここでは、間違ったスペル'piramid'
...
In this example, the GoogleSearchPort is a strongly typed object, which is an instance of a class defined by the GoogleSearch service.
Reflection usage example
...
| language | java |
|---|---|
| linenumbers | true |
...
を意図的に使用します。
この例のGoogleSearchPortは強く型付けされたオブジェクトで、GoogleSearchサービスで定義されたクラスのインスタンスです。
リフレクション方式の例
// クライアントサイドまたはサーバーサイドのコードに基づいて、まずブローカーを取得します。
String wsdlUrl = "http://
...
...
...
...
String
...
name="GoogleWebService";
...
//
...
サーバーサイドのみの呼び出し
//
...
broker.createWebService(name,
...
wsdlUrl);
...
// この呼び出しで、Web サービスのメソッドで使用可能なポートを取得します。
Object googlePort = broker.getServicePort(name);
...
//
...
ここでは、リフレクションを使用して "doSpellingSuggestion"
...
メソッドを取得します。
Method
...
method
...
=
...
googlePort.getClass().getDeclaredMethod
...
("doSpellingSuggestion",
...
new
...
Class[]
...
{String.class,
...
String.class}
...
);
...
// Java リフレクションを使用して、引数を提供し、メソッドを呼び出します。
String pyramid = (String)method.invoke
...
( googlePort,
...
new
...
Object[]{"myKey",
...
"piramid"});
制限事項
Limitations
With the current framework, to compile the strongly-type application, a user still needs to manually start the application once and jar the classes in the /ClientClasses or /ServerClasses folder for future strongly-type code compilation. This will be addressed in the future release.現在のフレームワークで強く型付けされたアプリケーションをコンパイルするには、アプリケーションを一度手動で起動する必要があります。また、強く型付けされたコードを今後コンパイルするために、/ClientClassesまたは /ServerClasses フォルダ内のクラスを jar コマンドを使用してまとめる必要があります。この問題については、今後のリリースで取り組みが行われる予定です。