この章では、アプリケーション開発用のParlay X Multimedia Messaging Web Servicesインタフェースに対するOCMSのサポートについて説明します。この章の内容は次のとおりです。
OCMSでは、「ETSI ES 202 391-5 V1.2.1 (2006-12), Open Service Access (OSA), Parlay X Web Services Part 5: Multimedia Messaging (Parlay X 2)」で定義されるように、SendMessageインタフェース、ReceiveMessageインタフェースおよびMessageNotificationManagerインタフェースの操作のサブセットのサポートが実装されています。
Multimedia Messaging Web Servicesは、次のインタフェースで構成されます。
SendMessage: メッセージを送信し、送信されたメッセージのステータスをチェックする操作を提供します(表10-1)。
ReceiveMessage: 受信したメッセージを取得する操作を提供します(表10-2)。
MessageNotificationManager: マルチメディア・メッセージに関する通知が配信されるアプリケーション側の通知インタフェースを提供します(表10-3)。
MessageNotification: マルチメディア・メッセージに関する通知を提供します(表10-4)。
MessagingNotificationListener: Parlay X MessagingNotificationインタフェースの上位にあるThin Javaラッパー・レイヤーです。Oracle拡張機能では、可能な場合、ユーザー・コンテキストが提供されます。クライアント・アプリケーションはこのインタフェースを実装し、MessagingNotificationListenerManager
のaddMessagingNotificationListener()メソッドを使用して登録する必要があります。管理者に登録すると、着信通知がある場合にインタフェースがコールされます。エンド・クライアントは、複数のリスナーを登録できます。すべてのリスナーは、着信通知があるたびにコールされます。SIPアドレス形式のユーザー・コンテキストは、コンテキスト・パラメータに渡されます。このクラスは、messagingwsnotification-10.1.3.4.warに含まれています。
操作 | 説明 |
---|---|
sendMessage |
宛先アドレスのセットにメッセージを送信するリクエスト。メッセージを識別するためにrequestIdentifierを戻します。requestIdentifierは、メッセージのステータスをポーリングするために、その後アプリケーションで使用できます。 |
getMessageDeliveryStatus |
このメソッドはこの実装でサポートされていません。常にServiceExceptionがスローされ、コードSVC0001が発生します。送信したメッセージの配信ステータスを取得するには、各ターゲットURIに対して起動する通知エンドポイントを有効なSimpleReferenceが指し示している状態で |
操作 | 説明 |
---|---|
getReceivedMessages |
このメソッドはこの実装でサポートされていません。クライアントは、受信したメッセージをポーリングすることを許可されていません。かわりに、 |
getMessageURI |
このメソッドはこの実装でサポートされていません。このメソッドをコールすると、常にコードSVC001でServiceExceptionが発生します。 |
getMessage |
このメソッドはメッセージ全体を読み取ります。データは、戻りメッセージの添付ファイルとして戻されます。 |
表10-3 MessageNotificationManagerインタフェース
操作 | 説明 |
---|---|
startMessageNotification |
指定のメッセージ・サービスのアクティブ化番号と基準に関して、アプリケーションへの通知を開始します。 「Parlay X 2.1 specification, section 8.4.1」に従い、「インタフェース: MessageNotificationManager、操作: startMessageNotification」で説明する点を明確にして実装されています。 |
stopMessageNotification |
この操作により、アプリケーションでマルチメディア・メッセージ通知を終了できます。 「Parlay X 2.1 specification, section 8.4.2」に従い、「インタフェース: MessageNotificationManager、操作: stopMessageNotification」で説明する点を明確にして実装されています。 |
この項では、インタフェースの各操作を使用する際のガイドラインについて説明します。
このメソッドは、実際のエンド・ユーザーにかわって常に起動されます。エンド・ユーザーは、SIP Address-Of-Record(AOR)によって識別されます。メッセージ・リクエストの一部を解析して、AORを決定します。
getMessageDeliveryStatusメソッドでメッセージ・ステータスをポーリングするために、戻されたrequestIdentifierは使用できません。この実装には、getMessageDeliveryStatusメソッドが実装されていないためです。かわりに、配信ステータスの通知を取得するには、各ターゲットURIに対してsendMessageメソッドを使用できる場合、有効なSimpleReferenceオブジェクトをsendMessageメソッドに渡します。
現行では、senderAddress、優先度およびチャージングのパラメータは無視されます。
グループURLはサポートされていません。
このメソッドのコール元にSOAPコンテキストの添付ファイルが含まれる場合、その添付ファイルにはメッセージの本文が含まれていると考えられます。この場合、サブジェクト・パラメータは無視され、添付ファイルの生のコンテンツ(バイト)がターゲットURIに送信されます。ただし、コール元にSOAPの添付ファイルが含まれない場合、サブジェクト・パラメータはメッセージ全体で構成されていると考えられます。そのため、コンテンツ・タイプがテキストまたはプレーンのSIPメッセージがターゲットの受信者に送信されます。
このメソッドはこの実装でサポートされていません。常にServiceExceptionがスローされ、コードSVC0001が発生します。送信したメッセージの配信ステータスを取得するには、各ターゲットURIに対して起動する通知エンドポイントを有効なSimpleReferenceが指し示している状態でsendMessage
メソッドをコールします。
このメソッドはこの実装でサポートされていません。常にServiceExceptionがスローされ、コードSVC001が発生します。クライアントは、受信したメッセージをポーリングすることを許可されていません。かわりに、MessageNotificationManager
インタフェースのstartMessageNotification
メソッドを使用して、新しいメッセージをエンドポイント・ユーザーのために取得できる場合に起動する通知エンドポイントを登録する必要があります。
このメソッドはこの実装でサポートされていません。このメソッドをコールすると、常にコードSVC001でServiceExceptionが発生します。
「Parlay X 2.1 specification, section 8.2.3」に従い、次の点を明確にして実装されています。
このメソッドが、サーバーに存在しないmessageRefIdentifierでコールされると、エラー・コードSVC002でServiceExceptionがスローされます。
「Parlay X 2.1 specification, section 8.4.1」に従い、次の点を明確にして実装されています。
messageServiceActivationNumberは、メッセージ通知が配信されるユーザーのSIP Address-Of-Recordに変換します。
現行では、基準のパラメータは無視されます。
このメソッドで使用するSimpleReferenceオブジェクトの相関パラメータは、任意のクライアントのエンド・ユーザーのすべてのインスタンスに対してグローバルに一意である必要があります。次のstopMessageNotificationの説明を参照してください。
「Parlay X 2.1 specification, section 8.4.2」に従い、次の点を明確にして実装されています。
startMessgeNotificationのコールで提供されるmessageServiceActicationNumberはエンド・ユーザーのSIP AORであるため、stopMessageNotificationに渡される相関パラメータは、特定のクライアントから特定のエンドユーザー・インスタンスに一意にマップできる必要があります。そのため、通知相関パラメータは任意のクライアントの各エンド・ユーザー・インスタンスに対してグローバルに一意である必要があります。その結果、正しいユーザー・インスタンスに中止通知リクエストを正しくマップできます。