Configuration d'une composition d'application SIP

La norme JSR 116 pour les applications SIP indique dans la section 2.4 que plusieurs applications peuvent être appelées pour une même requête SIP. Le processus de configuration des applications afin qu'elles respectent cette norme est appelé composition d'application.

Pourquoi et quand exécuter cette tâche

Pour la composition d'application, il est nécessaire que les implémentations utilisent un modèle de services en cascade. Le modèle de services en cascade requiert que les applications de service déclenchées sur le même hôte soient déclenchées à la suite, comme si cette opération avait eu lieu sur des hôtes différents. C'est pourquoi, les réponses sont dirigés vers l'amont et atteignent les applications dans l'ordre inverse des demandes correspondantes.

La norme JSR 116 n'indique pas comment implémenter la composition d'application. C'est pourquoi, il existe plusieurs moyens d'être en conformité avec cette norme. Pour WebSphere Application Server, la composition de l'application dépend de l'ordre des applications déployées et de l'ordre des règles de mappage dans le descripteur de déploiement de chaque application.
  • Pour une requête entrante initiale, le conteneur SIP essaie, dans l'ordre, chaque règle potentielle. Lorsque le conteneur trouve la correspondance nth, le conteneur appelle le servlet correspondant.

  • Si le servlet doit traiter par proxy la requête, le conteneur scanne les règles afin de trouver des correspondances supplémentaires. Lorsque le conteneur trouve la correspondance (n+1)th, le conteneur appelle le servlet correspondant.

  • Tout servlet dans la même application que le servlet précédemment appelé est exclu du processus correspondant. Aucun servlet ne peut être appelé deux fois pour la même requête SIP.

Vous pouvez spécifier la charge lors de la priorité du démarrage. La priorité <load-on-startup> dans sip.xml définit l'ordre dans lequel les servlets sont initialisés au démarrage. Si cette valeur est inférieure à zéro, les servlets seront initialisés lorsque la première demande sera mise en correspondance avec ces derniers conformément à la règle de correspondance et à l'ordre de composition. Zéro est une pondération admissible pour un ordre d'initialisation de démarrage. Si cette balise n'existe pas ou si elle contient une valeur négative, le servlet n'est pas initialisé au démarrage.

Vous devez également ajouter <load-on-startup> à la même balise du fichier web.xml si vous la modifiez manuellement. Le conteneur Web charge les servlets (et siplets), et il n'analyse que le fichier web.xml. Lors du déploiement d'un fichier SAR, seul le fichier sip.xml doit être modifié. Le fichier web.xml est automatiquement généré après le déploiement.

La balise load-on-startup intégrée au descripteur de déploiement SIP d'un servlet indique l'ordre de chargement de l'application au démarrage du serveur. Elle n'indique pas l'ordre d'appel d'une application lorsque celle-ci fait partie d'une chaîne de composition d'applications qui met les règles en correspondance afin de traiter un nouveau message entrant.

La pondération de démarrage des applications et de leurs modules est indiquée dans le fichier deployment.xml. L'ordre dans lequel les modules choisissent des demandes lors de la composition est d'abord évalué par la pondération des applications, puis par celle des modules. La procédure ci-après peut être suivie afin de définir la pondération des applications ou la pondération des modules à partir de la console d'administration.

Procédure

  1. Pour indiquer la pondération des applications (fichiers EAR), développez Applications d'enterprise > Nom_application > Comportement de démarrage. Définissez ensuite l'ordre de démarrage.
  2. Pour indiquer la pondération des modules (fichiers WAR), développez Applications d'enterprise > Nom_application > Gestion de modules. Définissez ensuite la pondération de démarrage.
  3. Redémarrez les applications modifiées.

Exemple

Spécification de l'exemple de priorité load-on-startup :
sip.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE sip-app
PUBLIC "-//Java Community Process//DTD SIP Application 1.0//EN"
"http://www.jcp.org/dtd/sip-app_1_0.dtd">
<sip-app>
	<display-name>SIPSampleProxy</display-name>
	
	<servlet>
		<servlet-name>SIPSampleProxy</servlet-name>
		<servlet-class>sipes.test.container.proxy.SIPSampleProxy</servlet-class>
		<load-on-startup>1</load-on-startup>
	</servlet>

	<servlet-mapping>
		<servlet-name>SIPSampleProxy</servlet-name>
		<pattern>
			<equal>
				<var>request.uri.user</var>
				<value>SIPSampleProxy</value>
			</equal>
		</pattern>
	</servlet-mapping>
	
	<proxy-config>
		<sequential-search-timeout>1000</sequential-search-timeout>
	</proxy-config>
	<session-config>
		<session-timeout>12</session-timeout>
	</session-config>
</sip-app>

web.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app id="WebApp">
	<display-name>SIPSampleProxy</display-name>
	<servlet>
		<servlet-name>SIPSampleProxy</servlet-name>
		<display-name>SIPSampleProxy</display-name>
		<servlet-class>sipes.test.container.proxy.SIPSampleProxy</servlet-class>
	</servlet>
	<servlet-mapping>
		<servlet-name>SIPSampleProxy</servlet-name>
		<url-pattern>/SIPSampleProxy</url-pattern>
	</servlet-mapping>
	<welcome-file-list>
		<welcome-file>index.html</welcome-file>
		<welcome-file>index.htm</welcome-file>
		<welcome-file>index.jsp</welcome-file>
		<welcome-file>default.html</welcome-file>
		<welcome-file>default.htm</welcome-file>
		<welcome-file>default.jsp</welcome-file>
	</welcome-file-list>
</web-app>
Spécification de l'exemple de la pondération de démarrage :

L'exemple suivant est destiné à un serveur autonome.

deployment.xml

<?xml version="1.0" encoding="UTF-8"?> 
- <appdeployment:Deployment xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI" 
xmlns:appdeployment="http://www.ibm.com/websphere/appserver/schemas/5.0/appdeployment.xmi" 
xmi:id="Deployment_1137951186883">
- <deployedObject xmi:type="appdeployment:ApplicationDeployment" xmi:id="ApplicationDeployment_1137951186883" 
deploymentId="0" startingWeight="1" binariesURL="$(APP_INSTALL_ROOT)/OrangeNode08Cell/SipContainerTestSuite.ear" 
useMetadataFromBinaries="false" enableDistribution="true" createMBeansForResources="true" reloadEnabled="false" 
appContextIDForSecurity="href:OrangeNode08Cell/SipContainerTestSuite" 
filePermission=".*\.dll=755#.*\.so=755#.*\.a=755#.*\.sl=755" allowDispatchRemoteInclude="false" 
allowServiceRemoteInclude="false">
  <targetMappings xmi:id="DeploymentTargetMapping_1137951186883" enable="true" target="ServerTarget_1137951186883" /> 
  <classloader xmi:id="Classloader_1137951186883" mode="PARENT_FIRST" /> 
- <modules xmi:type="appdeployment:WebModuleDeployment" xmi:id="WebModuleDeployment_1137951186883" 
deploymentId="1" startingWeight="10000" uri="sipunit.war">
  <targetMappings xmi:id="DeploymentTargetMapping_1137951186884" target="ServerTarget_1137951186883" /> 
  <classloader xmi:id="Classloader_1137951186884" /> </modules>
  <properties xmi:id="Property_1137951186883" name="validateinstall" value="warn" /> </deployedObject>
  <deploymentTargets xmi:type="appdeployment:ServerTarget"
xmi:id="ServerTarget_1137951186883" 
name="server1" nodeName="OrangeNode10" /> </appdeployment:Deployment>

Icône indiquant le type de rubrique Rubrique de tâche



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tsip_appchain
Nom du fichier : tsip_appchain.html