ヘッダーをスキップ
Oracle® Fusion Middleware Oracle WebLogic Server Microsoft .NET対応のWebLogic JMSクライアントの使用
12c リリース1 (12.1.1)
B65901-01
  ドキュメント・ライブラリへ移動
ライブラリ		 製品リストへ移動
製品		 目次へ移動
目次
前
前 		 次
次		  

4 プログラミングの考慮事項

この章では、JMS .NETクライアント・アプリケーションを作成する際のプログラミングの考慮事項とベスト・プラクティスを示します。

WebLogic JMS拡張機能の使用

表4-1では、このリリースのJMS .NETクライアントでサポートされるWebLogic JMS拡張機能を示します。メッセージングを構成するにはいくつかの方法があります。

JMS .NETクライアントとJavaクライアントでは、拡張機能の構成方法や動作に違いがある場合もあります。たとえば、拡張機能によっては、JMS .NET APIを使用してプログラム的に有効にすることはできず、構成を通じてのみ有効にできるものもあります。以下の表にその違いをまとめています。それ以降の節では、必要に応じて、追加の詳細情報を示しています。

表4-1 JMS .NETクライアントでサポートされるWebLogic JMS拡張機能

機能 接続ファクトリで構成可能 サーバーで構成可能 Java API JMS .NETAPI 説明

分散宛先(共通、重み設定)

詳細は、次を参照してください:

  • 『Oracle WebLogic Server JMSのプログラミング』の「分散宛先の使用」

  • 『Oracle WebLogic Server JMSの構成と管理』の「分散宛先リソースの構成」

はい

はい

いいえ

いいえ

フロー制御プロデューサ

詳細は、『Oracle WebLogic Serverパフォーマンスおよびチューニング』の「JMSサーバーおよび宛先のメッセージのフロー制御」を参照

はい

はい

いいえ

いいえ

割当て条件内でのプロデューサのブロック

詳細は、『Oracle WebLogic Serverパフォーマンスおよびチューニング』の「接続ファクトリでの送信タイムアウトの定義」を参照

はい

はい

いいえ

いいえ

WebLogic Serverのリモート・インスタンス用の外部宛先

詳細は、『Oracle WebLogic Server JMSの構成と管理』の「外部サーバー・リソースからサード・パーティJMSプロバイダへのアクセスの構成」を参照

いいえ

はい

いいえ

いいえ

「以前のリリースのWebLogic Serverとの相互運用」を参照してください。

ストア・アンド・フォワード(SAF)インポート済み宛先

詳細は、『Oracle WebLogic Serverストア・アンド・フォワードの構成と管理』の「SAFインポート済宛先」を参照

いいえ

はい

いいえ

いいえ

再配信制限

詳細は、『Oracle WebLogic Server JMSのプログラミング』の「メッセージの再配信制限の設定」を参照

いいえ

はい

はい

いいえ

再配信遅延

詳細は、『Oracle WebLogic Server JMSのプログラミング』の「メッセージの再配信遅延の設定」を参照

はい

いいえ

はい

いいえ

エラー宛先

詳細は、『Oracle WebLogic Server JMSのプログラミング』の「配信されなかったメッセージに対するエラー宛先の構成」を参照

いいえ

はい

いいえ

いいえ

「WLDestination.getCreateDestinationArgument」

いいえ

いいえ

はい

はい

「確認応答なし」モード

詳細は、『Oracle WebLogic Server JMSのプログラミング』の「NO_ACKNOWLEDGEの使用」を参照

いいえ

いいえ

はい

はい

順序単位

詳細は、次を参照してください:

  • 『Oracle WebLogic Server JMSのプログラミング』の「メッセージ順序単位の使用」

  • 『Oracle WebLogic Serverパフォーマンスおよびチューニング』の「WebLogic JMSのチューニング」での「順序単位を使用したアプリケーションのチューニング」

はい

はい

はい

はい

「順序単位」を参照してください。

メッセージ配信のスケジューリング

詳細は、『Oracle WebLogic Server JMSのプログラミング』の「メッセージ配信時間の設定」を参照してください。

はい

はい

はい

はい

「メッセージ配信時間」を参照してください。

非同期コンシューマのメッセージ最大パイプライン

  • 詳細は、『Oracle WebLogic Server JMSのプログラミング』の「非同期のメッセージ・パイプライン」を参照

  • 『Oracle WebLogic Serverパフォーマンスおよびチューニング』の「MessageMaximumのチューニング」

はい

いいえ

はい

いいえ

メッセージの圧縮

詳細は、『Oracle WebLogic Server JMSのプログラミング』の「メッセージ圧縮」を参照

はい

いいえ

はい

いいえ

「メッセージの圧縮」を参照してください。

割当て

詳細は、『Oracle WebLogic Serverパフォーマンスおよびチューニング』の「割当ての定義」を参照

いいえ

はい

いいえ

いいえ

一方向のメッセージ送信

詳細は、『Oracle WebLogic Serverパフォーマンスおよびチューニング』の「一方向メッセージ送信による非永続メッセージングのパフォーマンスの向上」を参照

はい

いいえ

いいえ

いいえ

「一方向のメッセージ送信」を参照してください。

確認応答ポリシー

詳細は、Oracle WebLogic Server管理コンソール・ヘルプの「JMS接続ファクトリ: 構成: クライアント」を参照

はい

いいえ

いいえ

いいえ

メッセージ・プロパティJMSXUserIDとして自動的にuser-idを含む

はい

はい

いいえ

いいえ

「JMSXUserIdとしてのuser-idの使用」を参照してください。

メッセージ・プロパティJMSXDeliveryCountとして配信試行回数を取得

いいえ

いいえ

いいえ

いいえ

「メッセージ配信の試行」を参照してください。

メッセージの圧縮

このリリースでは、JMS .NETクライアントとWebLogic Server上で実行されるJMS .NETクライアント・ホストの間のメッセージ送信において、メッセージの自動圧縮はサポートされていません。ただし、接続ファクトリで圧縮が設定されている場合、.NETクライアント・ホストと宛先の間でのメッセージ圧縮の動作は、Javaクライアントの場合と同じになります。動作は次のとおりです。

  • クライアント・ホストと宛先がWebLogic Serverの別々のインスタンス上で実行されている場合、送信されたメッセージはクライアント・ホストにおいて自動的に圧縮されます。

  • クライアント・ホストと宛先がWebLogic Serverの同じインスタンス上で実行されている場合、送信されたメッセージは圧縮されません。

圧縮されたメッセージは、.NETクライアントが受信するときに、JMS .NETクライアント・ホストによってサーバー側で解凍されます。

詳細は、『Oracle WebLogic Server JMSのプログラミング』の「メッセージ圧縮」を参照

順序単位

JMS .NET APIで順序単位(UOO)を指定する方法はJava APIとは異なります。JMS .NET APIで順序単位を設定するには、希望するUOOを持つメッセージにConstants.MessagePropertyNames.UNIT_OF_ORDER_PROPERTY_NAMEという文字列プロパティを追加します。

詳細は、『Oracle WebLogic Server JMSのプログラミング』の「メッセージ順序単位の使用」を参照

メッセージ配信時間

JMS .NET APIでメッセージ配信時間を指定する方法はJava APIとは異なります。JMS .NET APIでメッセージ配信時間を設定するには、long型のプロパティConstants.MessagePropertyNames.DELIVERY_TIME_PROPERTY_NAMEをメッセージに追加します。この値は、メッセージが配信される将来のミリ秒数です。

一方向のメッセージ送信

接続ファクトリで一方向のメッセージ送信を構成することはできますが、この動作はJMS .NETクライアントでは完全にサポートされていません。一方向送信として送信されたメッセージは、.NETクライアントと.NETクライアント・ホストの間では自動的に双方向送信となり、.NETクライアント・ホストとJMS接続ホストの間では一方向送信になります。

JMSXUserIdとしてのuser-idの使用

受信メッセージに対するシステム生成のメッセージ・プロパティJMSXUserId (オプション)では、元の送信者の資格証明を指定します。このプロパティを有効にするには、宛先、分散宛先、またはテンプレートで「センダー資格証明をアタッチ」属性を構成し、接続ファクトリで「JMSXUserIdをアタッチ」属性を構成します。取得するには、msg.GetStringProperty(Constants.MessagePropertyNames.USER_ID_PROPERTY_NAME)を呼び出します。

メッセージ配信の試行

受信メッセージに対するシステム生成のメッセージ・プロパティJMSXDeliveryCountでは、メッセージ配信の試行回数を指定します。最初の試行は1になります。値を取得するには、msg.GetIntProperty(Constants.MessagePropertyNames.DELIVERY_COUNT_PROPERTY_NAME)を呼び出します。

WebLogic JMS .NETクライアントの使用に関する制限事項

以下の節では、JMS .NETクライアントでサポートされないJMS機能について説明します。

サポートされないJMS 1.1の標準機能

このリリースでは、以下のJMS 1.1の標準機能はサポートされません。

  • 一時的な宛先の作成とクローズ(javax.jms.TemporaryQueueおよびjavax.jms.TemporaryTopic)。ただし、受信メッセージのJMSReplyToヘッダーから宛先オブジェクトを取得する場合は、Javaクライアントで作成された一時的な宛先に対してJMS .NETクライアントはメッセージを生成できます。

  • javax.jms.QueueRequesterおよびjavax.jms.TopicRequester。(これらのヘルパー・クラスは一時的な宛先に関連しています)。

  • キュー・ブラウザ(javax.jms.QueueBrowser)。

  • キューおよびトピックのインタフェース(QueueConnectionFactory、TopicConnectionFactory、QueueConnection、TopicConnection、QueueSession、TopicSession)。これらのキューとトピックのインタフェースはJMS 1.0.2のレガシー・インタフェースであり、JMS 1.1の共通インタフェースで置き換えられました。

サポートされないJMS 1.1のオプション機能

このリリースでは、以下のJMS 1.1のオプション機能はサポートされません。

  • XAインタフェース(XAConnectionFactory、XAConnection、およびXASession)。

  • グローバルXAトランザクションへの参加(「トランザクション」を参照)。

  • 接続コンシューマとサーバー・セッション・プール(javax.jms.ConnectionConsumer、ServerSessionPool、およびServerSession)。これらはJava EE MDBで置き換えられたオプション機能であり、WebLogic Java JMSクライアントではサポートされていません。

  • MessageProducer.setDisableMessageTimestampメソッド。WebLogic JMS Javaクライアントはこのメソッドを無視します。

サポートされないWebLogic JMS拡張機能

このリリースでは、以下のWebLogic JMS拡張機能はサポートされません。

  • SSL

  • HTTPトンネリング

  • SAFクライアント - 『Oracle WebLogic Serverスタンドアロン・クライアントのプログラミング』の「JMS SAFクライアントによる確実なメッセージ送信」を参照

  • マルチキャスト・サブスクライバ - 『WebLogic JMSのプログラミング』の「WebLogic JMSでのマルチキャストの使い方」を参照

  • 自動再接続 - 『Oracle WebLogic Server JMSのプログラミング』の「JMSクライアントの自動フェイルオーバー」を参照

  • 作業単位(UOW) - .NETクライアントがメッセージにUOWプロパティを設定しようとすると、Weblogic.Messaging.MessageExceptionが生成されます。また、.NETコンシューマは、Javaクライアントによって送信されたデシリアライズ可能なコンテンツを持つUOWメッセージを受信します。この場合、コンシューマは、ObjectMessageのObjectMessage.getObject()メッセージを呼び出すと、MessageFormatExceptionを受け取ります。作業単位はサポートされませんが、より一般的な拡張機能である順序単位は完全にサポートされています。順序単位の詳細は、 「順序単位」を参照してください。


    注意:

    JMS .NET APIではJMSリソース(トピックやキューなど)をプログラム的に構成するための拡張機能は提供していません。Javaでプログラム的に構成するには、JMX MBeansまたはweblogic.jms.extensions.JMSModuleHelperヘルパー・クラスを使用します。JMSを構成するその他の方法としては、WLSTスクリプトやWebLogic管理コンソールがあります。

トランザクション

このリリースでは、JMS .NETクライアントはJMS仕様での定義にのみ従ってトランザクション・セッションをサポートします。トランザクション・セッションは標準のローカル・トランザクションの機能を提供します。Javaクライアントの場合と同様に、同じクラスタ内の1つまたは複数のWebLogic JMS宛先がトランザクション・セッションのローカル・トランザクションに参加できますが、他のリソースは参加できません(他のクラスタ内のJMSサーバー、データベース、外部JMSプロバイダなど)。

グローバルXAトランザクションはサポートされないため、JMSは.NETトランザクションには参加できません。接続ファクトリのXAの設定は.NETクライアントによって無視されます。JMS .NETクライアントの処理は.NETトランザクションには参加できません。

異なる言語環境間でのメッセージの交換

.NETプロデューサとJavaまたはCコンシューマ、あるいはJavaまたはCプロデューサと.NETコンシューマの間で、以下のJava JMSメッセージ・タイプを交換できます。

ただし、ObjectMessageタイプは一方の言語から別の言語に送信することはできますが、そのメッセージは同じ言語で記述されない限り、解釈可能になりません。ObjectMessageタイプのプロデューサとコンシューマは同じ言語で記述する必要があります。不一致が生じた場合、つまり、.NET ObjectMessageがJavaコンシューマで受信されたり、Java ObjectMessageが.NETコンシューマで受信されたりした場合、message.getObject()はMessageFormatExceptionを送出します。

URLフォーマットの指定

Provider_URLには、以下のフォーマットを使用して、カンマで区切って複数のアドレスを格納できます。

t3://address [,address]...

特定のアドレスで複数のポート範囲を指定できます。

複数のアドレスを指定する構文は次のとおりです。

address = hostlist : portlist

説明:

hostlist = hostname [, hostname]...
portlist = portrange [+ portrange]...
portrange = port [- port]

port -portを使用してポート範囲を指定し、+ (プラス記号)を使用して複数のポート範囲を区切ります。

表4-2に、URLフォーマットの例を示します。

表4-2 URLフォーマットの例

フォーマット 可能なフォーマット 
t3://hostA:7001
t3://hostA,hostB:7001,hostC:7002

t3://hostA:7001,hostB:7001,hostC:7002

t3://hostA:7001+7005+7007,hostB:7001

t3://hostA:7001,hostA:7005,hostA:7007,
hostB:7001

t3://hostA:7001-7003+7005+7007,hostB:8001

t3://hostA:7001,hostA:7002,hostA:7003,
hostA:7005,hostA:7007,hostB:8001

DNS別名ホスト名の使用

複数のホストに展開されるDNS別名ホスト名を指定することもできます。たとえば、DNS別名myclusterがhost1,host2に解決される場合、URL t3://mycluster:7001はアドレス・リストt3://host1:7001,host2:7001に展開されます。このURLを指定して作成されたコンテキストでは常に、host1にアクセスできない場合はhost2を使って再試行します。DNS別名は通常、ネットワーク管理者が構成します。

JMS .NETクライアントでのセキュリティの実装

JMS .NETクライアントを作成する場合は以下のセキュリティの考慮事項に注意する必要があります。

ロギングとデバッグの構成

サーバー側の転送と、WebLogic Server上で実行される.NETクライアント・ホストにおいて、基本的なロギングとデバッグを使用できます。

サーバー側

サーバー側でデバッグを有効にするには、以下のコマンドを使用します。

-Dweblogic.debug.DebugJMSDotNetT3Server=true
-Dweblogic.debug.Debug.JMSDotNetProxy=true

クライアント側

クライアント側のロギングとデバッグを有効にして制御するには、アプリケーション構成ファイル内の様々な構成設定を使用します。生成されたビルド・ファイルに対するアプリケーション構成ファイルの名前はyourapplicationname.exe.configです。yourapplicationnameはメッセージング・クライアントを実行するアプリケーションの名前です。

例4-1では、ロギングとデバッグを構成するためにアプリケーション構成ファイルに追加する必要のあるXMLコンテンツを示します。その後の節で、各種の設定の詳細について補足します。すでにyourapplicationname.exe.configファイルがある場合は、以下のリストで示すXMLコンテンツをファイルに追加してください。既存のファイルがない場合は、ファイルを作成して、yourapplicationname.exeファイルと同じディレクトリに格納してください。


注意:

Visual Studioを使用している場合は、例4-1に示すロギングとデバッグの設定をApp.configファイルに追加する必要があります。Visual Studio環境でC#プロジェクトにApp.configファイルを追加するには、Microsoft Webサイトhttp://msdn.microsoft.com/en-us/library/ms184658.aspxの指示に従ってください。

例4-1 yourapplicationname.exe.configファイルのXMLファイル・コンテンツ

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <appSettings>
    <!-- To forward log output to a file, please uncomment the following line, and replace the file name with the desired one -->
    <!--- <add key="weblogic.JMSDotNet.debugConfig.LogFileName" value="c:\test\MyLogFile.log" /> -->
    
    <!-- To prevent log messages from displaying to the console, use the value 'false' -->
    <!-- <add key="weblogic.debug.JMSDotNet.config.IsLogToConsole" value="false" /> -->    
  </appSettings>
  <system.diagnostics>
    <switches>
      <!-- Please set the switch value as desired for logging to each Category -->
      <!-- value for Off=0, Error=1, Warning=2, Info=3, Verbose=4    -->
 
      <!-- if "AllLogger" is enabled (no zero for the value), every individual category is set to the same level as the AllLogger,
            no matter how individual category's value is set -->
      <add name="weblogic.debug.JMSDotNet.All" value="0" />
      <add name="weblogic.debug.JMSDotNet.Socket" value="0" />
      <add name="weblogic.debug.JMSDotNet.T3" value="0" />
      <add name="weblogic.debug.JMSDotNet.Transport" value="0" />
      <add name="weblogic.debug.JMSDotNet.PhysicalMsg" value="0" />
      <add name="weblogic.debug.JMSDotNet.LogicalMsg" value="0" />
    </switches>
  </system.diagnostics>
</configuration>

メッセージ出力

ログ・メッセージをコンソールに出力するか、ファイルに保存するかを指定するには、表4-3に示すように、<appSettings>要素を使用します。

表4-3 appSettingsの値

キー 値 設定 
weblogic.JMSDotNet.debugConfig.LogFileName

String

ログ・ファイルの絶対パスとファイル名(c:\test\MyLogFile.logなど)。

注意: デフォルトのログ・ファイル・サイズ制限は500KB。ログ・ファイルがこのサイズに達するたびに、サーバーはログ・ファイルの名前を変更し、新しいMyLogFile.logを作成して新しいメッセージを格納します。デフォルトでは、ローテーションされるログ・ファイルには、MyLogFile.log.0、MyLogFile.log.1、MyLogFile.log.2、...のように作成順に番号が付けられます。MyLogFile.log.0に最新のログ・メッセージが格納されます。

 
weblogic.JMSDotNet.debugConfig.IsLogToConsole

Boolean

  • True - ログ・メッセージをコンソールに表示します。

  • False - ログ・メッセージをコンソールに表示しません。

ログのカテゴリとレベル

クライアント側のロギングは以下のカテゴリに分類されます。

  • Socket

  • T3

  • Transport

  • PhysicalMsg

  • LogicalMsg

  • All (上記の個々のカテゴリのすべてを表します)

カテゴリごとに次のロギング・レベルを指定できます。

Off(0), Error(1), Warning(2), Info(3), Verbose(4)

Allカテゴリの重要度レベルは個々のカテゴリの設定をオーバーライドすることに注意してください。

ソケットとスレッドの動作について

WebLogic JMS .NETクライアントは他のタイプのWebLogicクライアントと同じWebLogic Server T3ポートを共有します。.NETクライアントはContextFactoryクラスを使用してIContext初期コンテキストを作成するときに、サーバー上のT3対応のポートを参照するURLを指定します。要求されたネットワーク接続を処理するために、1つのソケット・ペアが暗黙的に作成されます。ソケット・ペアはクライアント上の1つのソケットと、WebLogic Server JMS .NETクライアント・ホスト上のもう1つのソケットから成ります。.NETコンテキストから取得されたJMSオブジェクトに対するJMS操作はすべて、コンテキストの暗黙的なネットワーク接続を通じてルーティングされます。

同じ.NET CLR上で2つのIContext初期コンテキスト・インスタンスが、同じWebLogic Server JMS .NETクライアント・ホストに同時に接続した場合は、2つのネットワーク接続が作成されます。各ネットワーク接続はそれぞれ1組のソケット(サーバー側ソケットとクライアント側ソケット)を保持します。したがって、2つのネットワーク接続が作成された場合は、CLRクライアント上で2つのソケットが作成され、JMS .NETクライアント・ホストとして機能するWebLogic Server上でも2つのソケットが作成されます。この動作はWebLogic Javaクライアントとは対照的です。WebLogic Javaクライアントでは、リモートのJVMへのネットワーク接続が重複していれば自動的に検出し、重複した接続を閉じます。かわりに、特定のリモートJVMとの間のすべてのトラフィックを、1つのネットワーク接続上で暗黙的に多重化します。

JMS .NETクライアントのサーバー側ソケットは、他のタイプのWebLogicクライアントと同じWebLogic Serverソケット・リーダー・マルチプレクサ・スレッド・プールによって提供されます。JMS .NETクライアントのリクエストを処理する場合、ソケット・リーダー・マルチプレクサ・スレッド・プールは受信リクエストをソケットから読み取り、WebLogic Serverのデフォルト・スレッド・プールに作業をディスパッチします。デフォルト・スレッド・プールでは、リクエストを処理してクライアントに応答を返送します。

JMS .NETクライアントでは、ネットワーク接続ごとに(つまり、各IContext初期コンテキスト・インスタンスに対して)新しい内部スレッドが自動的に作成されます。この専用のスレッドがクライアントで受信するすべてのデータを読み取り、関連する作業をCLRスレッド・プールにディスパッチします。つまり、.NETクライアント・アプリケーションの非同期メッセージ・イベント・ハンドラはCLRスレッド・プール内で実行されます。


注意:

CLRスレッド・プールは.NET FrameworkのSystem.Threading.ThreadPoolクラスで提供されます。1つのプロセスにつき1つのスレッド・プールが存在します。スレッド・プールのデフォルト・サイズは1プロセッサ当たり25スレッドですが、ThreadPool.SetMaxThreadsメソッドを使用すると、スレッド・プール内のスレッド数を変更できます。スレッド・プール内の各スレッドはデフォルトのスタック・サイズを使用し、デフォルトの優先順位で実行されます。詳細は、Microsoft .NET FrameworkのドキュメントでSystem.Threading.ThreadPoolクラスを参照してください。

JMS .NETアプリケーションで同時に多数の初期コンテキストが作成され、そのすべてが同じWebLogic Server .NETクライアント・ホストに接続する場合は、1つの共有初期コンテキストを使用するようにアプリケーションを変更すると、パフォーマンスを改善できます。共有コンテキストを使用すると、クライアントは1つのネットワーク接続のみを作成するようになります。

Javaおよび.NET間のデータ変換

エンディアンの変換

Javaと.NETではプリミティブ型を格納するために異なる形式のバイト順序を使用しています。

  • Microsoft Windows .NETはリトル・エンディアン(下位順序)形式を使用

  • Javaはビッグ・エンディアン(上位順序)形式を使用

Javaと.NETの相互運用性をサポートするために、データはビッグ・エンディアン形式を使用してネットワーク上で転送されます。.NETアプリケーションがJMS .NET APIを使用してプリミティブの読み書きを行うときに、データは必要に応じて自動的に、ビッグ・エンディアンとリトル・エンディアンの間で変換されます。たとえば、JMS .NET APIのBytesMessage.WriteIntを使用する場合、データは常にビッグ・エンディアンで格納され、Java APIとJMS .NET APIの両方のバイト・メッセージ読込み整数メソッドを使用して読み込むことができます。

JMS .NET APIを使用してプリミティブを渡すかわりに、未加工のバイト配列を使用してプリミティブ・データを転送する特殊なアプリケーションの場合は、Javaとやり取りする際にバイト形式をビッグ・エンディアンに手動で変換する必要があります。アプリケーションでエンディアンの手動変換を実行する必要がある場合は、JMS .NETクライアント・ライブラリで提供されているユーティリティ・クラスWebLogic.Messaging.Transport.Util.EndianConvertorの以下のヘルパー・メソッドを使用できます。

public static char SwitchEndian(char x)
public static short SwitchEndian(short x)
public static int SwitchEndian(int x)
public static long SwitchEndian(long x)
public static ushort SwitchEndian(ushort x)
public static uint SwitchEndian(uint x)
public static ulong SwitchEndian(ulong x)
public static double SwitchEndian(double x)
public static float SwitchEndian(float x)
public static byte[] SwitchEndian(byte[] x)

たとえば、未加工のバイト配列との間でプリミティブの読み書きを行う標準の.NETクラスSystem.IO.BinaryReaderとSystem.IO.BinaryWriterでは、リトル・エンディアンを使用します。以下のコードの抜粋は、.NETのバイト配列との間で整数を格納および取得する方法を示しています。

binaryWriter.WriteInt(EndianConverter.SwitchEndian(i))
i=EndianConverter.SwitchEndian(binaryReader.ReadInt())

符号付きバイトと符号なしバイトの変換

Javaプリミティブ・データ型のそれぞれに同じ名前と定義のC#データ型が対応していますが、byteデータ型については例外があります。以下の表に、C#とJavaで符号付きバイトと符号なしバイトに使用される異なる名前を示します。

表4-4 C#とJavaのバイト・プリミティブ・データ型

C# Java 説明 
byte

N/A

符号なしバイト

 
sbyte

byte

符号付きバイト

表4-4に示すように、Microsoft .NETでは、byte (符号なしバイト)とsbyte (符号付きバイト)の両方をプリミティブ・データ型としてサポートしていますが、Javaでは、byte (符号付きバイト)のみを直接のプリミティブ型としてサポートしています。どちらの言語の標準規約でもbyteデータ型の使用が規定されていますが、.NETでは符号なしバイトを表し、Javaでは符号付きバイトを表します。

.NETとJavaの間の相互運用性を確保するため、JMS .NETクライアントではバイトの読み書きに符号付きバイトのみを使用するようになっています。バイト値が127以下の場合は符号付きバイトと符号なしバイトの間に違いはありません。値が127以下の符号なしバイトはsbyteとして格納されます。ただし、.NETクライアントで127より大きな値の符号なしバイトを符号付きバイトに格納する必要があった場合は、その値を符号付きバイトから符号なしバイトに変換する必要が生じます。以下のサンプルでは、符号なしバイトを符号付きバイトとして読み書きするために使用できる変換メソッドを例示します。

  • C#でのバイト変換

    符号なしバイト値の255を次のように符号付きバイトとして渡すことができます。

    • byte unsignedByteValue = 255;

    • sbyte signedByteValue = unchecked ( (sbyte)unsignedByteValue ); //変換後の符号付き値 =-1

    同様に、以下のメソッドを使用して、符号付きバイト値を符号なしバイト値に変換できます。

    • sbyte signedByteValue = -1;

    • byte unsignedByteValue = unchecked ( (byte)signedByteValue ); //変換後の符号なし値 =255

  • Javaでのバイト変換

    次のように、符号なしバイトは符号付きバイトとして読み込んでから、符号なしバイト値に変換できます。

    • byte signedByteValue = -1;

    • int unsignedByteValue = 0xFF & signedByteValue; //変換後の符号付き値 = 255

    符号なしバイト値は次のように書き込むことができます。

    • Int unsignedByteValue = 255;

    • byte signedByteValue = 0xFF & unsignedByteValue; //変換後の符号付き値 =-1

JMS .NET APIでは1つのバイトを符号付きバイトとしてのみ格納できます。JMS .NET APIを使用してsbyteをshort、int、long、またはstringとして取得する場合、値は符号なしバイトではなくsbyteとして扱われます。たとえば、符号なしバイト値255をmessage.SetByteProperty("myvalue", unchecked( (sbyte)((byte)255) ))を使用して格納した場合、message.GetByteProperty("myvalue")またはmessage.GetShortProperty("myvalue")を呼び出すと「-1」が返されます。

バイト配列の転送

JMS .NETクライアントからWebLogic JMSにバイト配列を転送する場合、すべてのバイト配列(byte[])はそのまま渡されます(つまり、符号なしから符号付きへの変換はありません)。そのため、変換でデータが失われることはありません。

時間の変換

WebLogic JMS .NET APIでは、.NETの規約ではなくJavaの規約を使用して日付と時間を表現します。WebLogic.Messaging.IMessageメッセージ・インタフェースのJMSTimestampおよびJMSExpiration属性はlong型であり、Javaプログラミング言語で規定されているミリ秒の絶対時間を格納します。Javaのミリ秒の絶対時間の値は、協定世界時(UTC)の1970年1月1日午前0時から特定の時間までの差異をミリ秒単位で測定したものです。

以下の例では、.NET時間とJavaのミリ秒の絶対時間の値の変換方法を示します。

例4-2 現在の.NET時間をJavaのミリ秒時間に変換するC#サンプル・コード

// Example:  C# code for converting the current .NET time to Java millisecond time
DateTime baseTime = new DateTime(1970, 1, 1, 0, 0, 0);
DateTime utcNow = DateTime.UtcNow;
long timeInMillis = (utcNow.Ticks - baseTime.Ticks)/10000;
Console.WriteLine(timeInMillis);

例4-3 Javaのミリ秒時間を.NET時間に変換するC#サンプル・コード

// Example:  C# code for converting Java millisecond time to .NET time
DateTime baseTime = new DateTime(1970, 1, 1, 0, 0, 0);
long utcTimeTicks = (timeInMillis * 10000) + baseTime.Ticks;
DateTime utcTime = new DateTime(utcTimeTicks, DateTimeKind.Utc);
Console.WriteLine(utcTime);
Console.WriteLine(utcTime.ToLocalTime());

ベスト・プラクティス

以下の節では、JMS .NETクライアント・アプリケーションを作成する際のプログラミングのベスト・プラクティスを示します。

  前
前 		 次
次
  ドキュメント・ライブラリへ移動
ライブラリ		 製品リストへ移動
製品		 目次へ移動
目次