### Business Service Transport Configuration page

Use the AquaLogic Business Service Transport Configuration page to select, review, or change the service's transport protocol and to set, review, or change general transport configuration settings. This page appears both in the New AquaLogic Business Service wizard and in the AquaLogic Business Service editor:

Outbound transport-level security applies to the connections between ALSB proxy services and business services. For more information about transport-level security, see Configuring Transport-Level Security in the AquaLogic Service Bus Security Guide.

Option | Description
--- | ---
Protocol | Select a transport protocol from the list. The protocols available differ, depending on the service type: WSDL Web Service: DSP, HTTP, JMS, JPD, SB, WS Transport-Typed Service: EJB, Flow Messaging Service: E-mail, File, FTP, HTTP, JMS, MQ (if available), SFTP, Tuxedo Any SOAP Service: DSP, HTTP, JMS, JPD, SB Any XML Service: DSP, E-mail, File, FTP, HTTP, JMS, JPD, MQ (if available), SB, SFTP, Tuxedo
Load Balancing Algorithm | Select one of these load-balancing algorithms: Round-robin - This algorithm dynamically orders the URLs that you enter in the Endpoint URI field for this business service. If the first one fails, it tries the next one, and so on until the retry count is exhausted. For every new message, there is a new order of URLs. Random - This algorithm randomly orders the list of URLs that you enter in the Endpoint URI field for this business service. If the first one fails, it tries the next one, and so on until the retry count is exhausted. Random-weighted - This algorithm randomly orders the list of URLs that you enter in the Endpoint URI field for this business service, but some are retried more than others based on the value you enter in the Weight field. None - This algorithm orders the list of URLs that you enter in the Endpoint URI field for this business service from top to bottom.
Endpoint URI | Enter an endpoint URL in the format based on the transport protocol you selected in the Protocol field, above: The formats are: DSP -`t3://dsp-ip-address:port/dsp-app-name` EJB - `ejb:provider:jndiname` In the URI, `provider` is the name of the JNDI provider resource, and `JNDIname` is the JNDI name in the JNDI server for the EJB. If the JNDI provider is located on the same server, the JNDI provider need not be specified. The URI then would be `ejb::jndiname` E-mail - `mailto:foo@bar.com` File - `file:///root-dir/dir1` FTP - `ftp://hostname:port/directory` HTTP - `http://host:port/someService` The HTTP transport supports both `HTTP` and `HTTPS` endpoints. JMS - `jms://host:port[,host:port]*/factoryJndiName/destJndiName` To target a JMS destination to multiple servers, use the following URI format: `jms://host1:port,host2:port/QueueConnectionFactory/DestName` JPD - `jpd:[<provider>]:<jpd_uri>` `provider` (optional) is the name of the JNDI provider which corresponds to the WLI JNDI provider resource. When omitted, the JNDI provider on the local server is used. `<jpd uri>` is the relative URL of the JPD on the WLI server. For example, if `processes.Process.jpd` is in the SampleApp Web project, then the relative URL of the JPD is `/SampleApp/processes/Process.jpd`. MQ - `mq://local-queue-name?conn=mq-connection-resource-ref` `local-queue-name` is the name of the MQ queue from which the business service reads messages. `mq-connection-resource-ref` is the path (`project/folder`) and name of the MQ connection resource; for example, `default/my_MQconnection`. To make the MQ transport available in ALSB, see MQ Connections in Using the AquaLogic Service Bus Console. SB - `sb://<jndi_provider_name/>service_name` `jndi_provider_name` (optional) is the name of the ALSB JNDI provider resource. When omitted, the default context is used. `service_name` is a target service and corresponds to the remote proxy service URI. SFTP - `sftp://hostname:port/directory`
Endpoint URI (continued) | Tuxedo - `tuxedo:resourcename/remotename` `tuxedo-queue:sendQSpace/sendQName[/[rcvQspace:]rvcQname][/failureQname]` In the URI, `resourcename` corresponds to a WTC Import name and `remotename` corresponds to the service name exported by the remote Tuxedo domain. The URI `resourcename` is required, and the `remotename` is optional. If more than one URI is specified, you must have unique resource names for the endpoints. If no remote name is specified, its value is the value of the resource name. If no remote name is entered or if remote and resource name are the same, only one URI is allowed. In this case resource name and remote name have the same value. This allows already defined WTC Imports to make use of WTC load-balancing and failover. For more information, see AquaLogic Service Bus Interoperability Solution for Tuxedo. WS - `http://host:port/someService`
Note: | ALSB no longer supports duplicate endpoint URIs within the same business service.
Click Add to add one or more additional URIs. At run time, the URLs are selected based on the load balancing algorithm you selected in the Load Balancing Algorithm field. If you selected Random-weighted in the Load Balancing Algorithm field, you can also enter a weight in the Endpoint URI field. The default is `1`. If you have multiple endpoint defined, and you selected None in the Load Balancing Algorithm field, the order of endpoints is significant. You can reorder the endpoints using the Up and Down buttons. ALSB does not support duplicate endpoint URIs within the same business service.
Retry count | In case of delivery failure when sending outbound requests, specify the number of times to retry individual URL endpoints; in other words, the number of failover attempts. For example, a business service has one configured URI (U1) and the number of retries is set to 3. If U1 fails on the first attempt, the system retries the U1 endpoint 3 more times. If a business service has 2 configured URIs (U1 and U2) and a retry count of 3, if the first attempt (for example, to U1) fails, the system tries (fails over to) the next URI (U2). If that also fails, the system makes two more attempts, once to U1 and once to U2.
Retry Iteration Interval | Specify the number of seconds the system pauses before iterating over all the endpoint URIs in the list again. For example, a business service has two configured URIs (U1 and U2) and a retry count of 2 with a retry iteration interval of 5 seconds. If the first attempt (to U1) fails, the system tries U2 right away. But if U2 also fails, the system waits for 5 seconds and retries U1 once more.
Retry Application Errors | Select Yes or No. In case of delivery failure when sending outbound requests, specify whether or not to retry endpoint URIs based on application errors (for example, a SOAP fault).