• Time stamp symbols (%GyMdhHmsSEDFwWakKz). Java simple

• Working file name replacement (%f), usually used in pre/post

• UUID - %u, a UUID compliant with JDK 1.5 java.util.UUID, when

• Sequence Numbering - %{seq_name}, a reference to a persisted

Application Variable

A service assembly (SA) configured for one particular context are often migrated to a different context, one of the context specific information is the binding information in extensibility elements' attributes, for example, a service bound to FTP could have the following segment in its WSDL:

...
<ftp:address url=”ftp://usr1:pass1@localhost:21” ...>
...

<ftp:address
url=”ftp://${my_ftp_acct}:${my_ftp_acct_password}@${my_ftp_host}:${my
_ftp_port}” ...>

3. Message Transportation Via FTP

As illustrated in Figure 1, FTP BC uses directories on FTP server as
message persistence where service consumers and service providers
exchange messages, in the implementation, some assumptions are made
so that message transportation can be done in a FTP context in a more
controllable manner, especially when a directory is accessed
concurrently by multiple components (refer to “FTP BC Clustering
Support Design” for more details).
Here are the assumptions:

(1) For a specific service operation with FTP binding, the endpoint
information, i.e., host name, port, account login, password, plus a
base directory, specifies a message exchange area on the remote FTP
server where consumer and provider communicate, take a requestresponse
type operation for example, the followings are performed in
the area when carrying out the message transportation from consumer
to provider (request – IN-Route) and from provider to consumer
(response – OUT-Route):

Consumer: Staging (Put) request
Consumer: Expose (Rename to target location) request to provider when
staging completes
Provider: Poll (Get periodically) request
Provider: Archive/Remove request after received
Provider: Staging (Put) response
Provider: Expose (Rename to target location) response to consumer
when staging completes
Consumer: Poll (Get periodically) response
Consumer: Archive/Remove response received
The message exchange area – a dedicated directory on remote FTP
server and all its sub-directories (serving as archiving area,
staging area, exchange area, etc) can be created by either FTP BC
runtime or administratively, just as queues and topics in JMS
paradigm.

(2) For a given service, both the service consumer and service
provider either login using the same FTP account (so they share the
same FTP context – e.g., login home where all relative paths refer
to), or if different accounts are used, administrative configuration
need to be made to ensure the login home is mapped to the same
location on FTP server and appropriate access rights granted
accordingly

(3) Different service operations use dedicated message exchange areas
on the remote FTP server, no overlapping between these base
directories

(4) FTP file names are leveraged so that the consumers and providers
can push and poll messages between them, e.g., consumers post request
messages into FTP file with names that match the following pattern:
msg.., while the corresponding providers retrieve
these request messages with the same pattern from the agreed
location, similar process occurs for the response routing from
providers to consumers, numerous patterns are available for
configuration of a particular message transfer (implemented as FTP BC
extensibility elements: ftp:message, ftp:messageActivePassive (deprectaed),
ftp:transfer) so that messages posted got polled according to their
name pattern; note, however, it does not provide request-response
messages correlate across the FTP

(5) Request-response correlation is supported by leveraging names of
the FTP files that serve as intermediary message persistence on FTP
server, the contract is described as follows:

On the consumer side:

the message routing starts with consumer who invokes a service
(INVOKE in BPEL script), on the other side of the NMR, FTP BC
OutboundProcessor accepts the request message and de-normalized it
and put the message body – the payload to a FTP file with name as
req. (see Figure 1 for examples), then the consumer
thread (FTP BC OutboundProcessor) will spawn off a ResponsePoller
thread which starts polling a response with name
resp., note that the is the same
UUID for request and response, when resp. becomes
available at the agreed on location between the consumer and
provider, it is fetched, and the request-response correlation
completes, the fetched message is wrapped up in a normalized message
and send back into NMR using the same Message Exchange ID so that the
response will be available as the OUT variable of the INVOKE activity
in the BPEL script.

Figure 2. UUID tagged request files
On the provider side:

the provider polls (RECEIVE activity in BPEL) the message receiving
area that is agreed on between the consumer and provider for a
request with FTP file name pattern like req.%u, where suffix %u
denotes any string match the pattern of a typical UUID in string form
(refer to JDK java.util.UUID – since 1.5), see Figure 1 for examples.
Upon receive of the request message (polled from remote FTP
directory), the UUID tag is extracted from the file name, and
attached as meta data for the message exchange, the payload is
wrapped in a normalized message and send into the NMR.
The request message participates in any business logic in the service
unit and a response is figured out and send back to NMR with the same
message exchange (ME – attached with meta information including the
UUID tagged with the request), the OutboundProcessor will fulfill the
contract by putting the message to a FTP file named as
resp., see Figure 3 for exampes of UUID tagged
response messages.

Figure 3. UUID tagged response files

This completes the request-response correlation.

Note that message correlation scheme can be applied to multi-hop
service invoking, i.e., during the processing of the first service
invoking, e.g., invoke service1.operation1, the provider might in
turn invoke other services, such as service2.operation2 as shown
below:

Figure 4. Two hop synchronous services invoking with message
correlation

Note also, though the UUID tagging mechanism described above is
provided by FTP BC implementation, it is not the only means to
achieve message correlation, the service unit doing the message
transportation can use the information embedded inside the message
payload to do the correlation at application level, but that is
beyond the scope of this document, see scenarios on FTP BC wiki page
for samples.

4. FTP BC Runtime Configuration

4.1 FTP BC Runtime Parameters

• Number of Outbound Threads – the number of outbound threads, default is 10.
• InvokeTimeout – Time out in milliseconds for a synchronous service invoking, after a consumer sends a request, it will poll the response periodically (the polling interval is specified by ftp:pollIntervalMillis), InvokeTimeout is the elapsed milliseconds when the response poller thread will exit and report a timeout, default is 1000,000.
• Use Passive FTP - indicate if passive ftp is enabled.
• UseProxy – if proxy is used for FTP transfer, default is “false”.
• ProxyURL – the URL for the proxy, default is “socks5://localhost:1080”.
• Proxy User ID - if it is socks5, the user login id to the socks5 server, if specified, overwrite the one in ProxyURL
• Proxy ser Password - if it is socks5, the password for the specified user id, if specified, overwrite the one in ProxyURL
• Connection Pool Minimum Size - default = 2, the minimum number of connections that should be kept in the pool
• Connection Pool Maximum Size - default = 32, the maximum number of connections that can be kept in the pool, when a connection is returned to the pool, the value is checked, if the return of the connection will cause the pool size greater than this value, the connection is thrown away
• Max Idle Timeout for Pooled Connections - default = 60000, a timeout in milli-seconds, if a connection stays in the pool longer than the value, the connection will be evicted from the pool.
• Application Variables – Application variables are tokens defined for specific JBI components on the application server, application variables can be referenced in the attribute values of the extensibility elements in the specific BC's WSDLs, the references are resolved at the Service Unit deployment time.
• Application Configuration - Application configuration is a mechanism that allows the definition of named group of configuration parameters specific to a JBI component, and allow the group of parameters be referenced by an end point so that the binding can be completed with the parameters (e.g. host, port, user, password, etc.) provided in the named group.

4.2 FTP BC Application Variables

here are some examples:

4.3 FTP BC Application Configurations

Runtime Configuration Params (Top Level):

persisted in the file: /domains/domain1(e.g.)/jbi/components/sun-ftp-binding/install_root/workspace/config.properties

#Tue Aug 26 13:21:26 PDT 2008
ProxyUserID=proxy_user_001
ConnectionPoolMaxSize=32
ProxyURL=socks5\://localhost\:1080
ConnectionMaxIdleTimeout=60000
ConnectionPoolMinSize=2
UseProxy=false
ProxyUserPassword=xuVNoOTI6ShZYj2zMy8YQw\=\=
UsePassiveFTP=true
InvokeTimeout=1000000
OutboundThreads=10

Runtime Configuration Params (App Var):

persisted in the file: /domains/domain1(e.g.)/jbi/components/sun-ftp-binding/install_root/workspace/ApplicationVariables.properties

my_ftp_host=nova.stc.com{STRING}
my_ftp_port=21{NUMBER}
my_ftp_password=xuVNoOTI6ShZYj2zMy8YQw=={PASSWORD}

Runtime Configuration Params (App Configurations):

persisted in the file: /domains/domain1(e.g.)/jbi/components/sun-ftp-binding/install_root/workspace/ApplicationConfigurations.properties

myAppCfgObj001.SECURE_TYPE=ExplicitSSL
myAppCfgObj001.KEYSTORE=c:\key_and_trust\keystore.jks
myAppCfgObj001.USERDEFINEDDIRLISTSTYLECFG=
myAppCfgObj001.USEUSERDEFINEDDIRLISTSTYLE=false
myAppCfgObj001.PASSWORD=xuVNoOTI6ShZYj2zMy8YQw==
myAppCfgObj001.DIRLISTSTYLE=UNIX
myAppCfgObj001.configurationName=myAppCfgObj001
myAppCfgObj001.PORT=21
myAppCfgObj001.USERDEFINEDDIRLISTSTYLE=
myAppCfgObj001.TRUSTSTOREPASSWORD=xuVNoOTI6ShZYj2zMy8YQw==
myAppCfgObj001.KEYSTOREPASSWORD=xuVNoOTI6ShZYj2zMy8YQw==
myAppCfgObj001.USER=user1
myAppCfgObj001.KEYALIAS=ftp_client_001
myAppCfgObj001.KEYPASSWORD=VWiPa0YG6Ob+dOcTW4F6iQ==
myAppCfgObj001.HOST=nova.stc.com
myAppCfgObj001.TRUSTSTORE=c:\key_and_trust\keystore.jks
myAppCfgObj001.ENABLE_CCC=false
myAppCfgObj002.SECURE_TYPE=None
myAppCfgObj002.KEYSTORE=
myAppCfgObj002.USERDEFINEDDIRLISTSTYLECFG=C:\MY_FTP_HEURISTICS.CFG
myAppCfgObj002.USEUSERDEFINEDDIRLISTSTYLE=true
myAppCfgObj002.PASSWORD=+SCWwXgGwzOR3PsSvaCc/w==
myAppCfgObj002.DIRLISTSTYLE=AS400
myAppCfgObj002.configurationName=myAppCfgObj002
myAppCfgObj002.PORT=21
myAppCfgObj002.USERDEFINEDDIRLISTSTYLE=MY_AS_400
myAppCfgObj002.TRUSTSTOREPASSWORD=GA324/Om18roWSXF30Lx+g==
myAppCfgObj002.KEYSTOREPASSWORD=GA324/Om18roWSXF30Lx+g==
myAppCfgObj002.USER=anonymous
myAppCfgObj002.KEYALIAS=
myAppCfgObj002.KEYPASSWORD=GA324/Om18roWSXF30Lx+g==
myAppCfgObj002.HOST=localhost
myAppCfgObj002.TRUSTSTORE=
myAppCfgObj002.ENABLE_CCC=false

5. FTP BC Extensibility Elements

• <ftp:binding> - required as indication of FTP based binding, no attributes.
• <ftp:operation> - required as indication of FTP based operation binding, no attributes.
• <ftp:address> - specify end-point for FTP based operation binding, see annotations for attribute descriptions.
• <ftp:message> - specify message transfer for FTP based operation binding, this element takes same attribute values when used by either service consumer and service provider, making it suitable to be used in a symmetrical WSDL, see annotations for attribute descriptions.
• <ftp:transfer> - specify message transfer details for FTP based operation binding, the difference between this element and <ftp:message> are that the attributes are represented from perspective of sender and receiver involved in the message transfer, see annotations for attribute descriptions.

<ftp:address
url=”ftp://${my_ftp_acct}:${my_ftp_acct_password}@${my_ftp_host}:${my
_ftp_port}” ...>

ftp://<user>:<password>@<host>:<port>

Figure 11. Attribute Grouping for ftp:address

* ftp:transfer

//.../ or absolute ///.../, where , , ..., can be literal or pattern, depending on “sendToHasPatterns”.

(2) append (true/false – default is false): a flag indicating if the message is appended to the target file, when true, the message is appended to the target file (specified as “sendTo”), otherwise, it is an overwrite.

(3) sendToHasPatterns (true/false – default is false): when true, the “sendTo” contains patterns in its path components and/or file name, otherwise, the path and file name are literals.

(4) receiveFrom (String): the target where the receiver polls the message from, i.e., the target of a FTP get, it takes the form of relative //.../ or absolute ///.../, where , , ..., can be literal or regular expression, depending on “ReceiveFromHasRegexs”.

(5) receiveFromHasRegexs (true/false – default is false): when true, the “receiveFrom” contains regular expressions in its path components and/or file name, otherwise, the path and file name are literals.

(6) pollIntervalMillis (Integer – default is 5000): interval for an inbound component (receiver) polling the target in milliseconds.

(7) preSendCommand (Enumeration – default is NONE): operation performed before sending the message, can be NONE/COPY/RENAME.

(8) preSendLocation (String): a destination file for “preSendCommand”, it takes the form of relative //.../ or absolute ///.../, where , , ..., can be literal or pattern, depending on “preSendLocationHasPatterns”.

(9) preSendLocationHasPatterns (true/false – default is false): a flag indicating if “preSendLocation” contains patterns.

(10) postSendCommand (Enumeration – default is NONE): operation performed after sending the message, can be NONE/RENAME.

(11) postSendLocation (String): a destination file for “postSendCommand”, it takes the form of relative //.../ or absolute ///.../, where , , ..., can be literal or pattern, depending on “postSendLocationHasPatterns”.

(12) postSendLocationHasPatterns (true/false – default is false): a flag indicating if “postSendLocation” contains patterns.

(13) preReceiveCommand (Enumeration – default is NONE): operation performed before receiving the message, can be NONE/COPY/RENAME.

(14) preReceiveLocation (String): a destination file for “preReceiveCommand”, it takes the form of relative //.../ or absolute ///.../, where , , ..., can be literal or pattern, depending on “preReceiveLocationHasPatterns”.

(15) preReceiveLocationHasPatterns (true/false – default is false): a flag indicating if “preReceiveLocation” contains patterns.

(16) postReceiveCommand (Enumeration – default is NONE): operation performed after receiving the message, can be NONE/DELETE/RENAME.

(17) postReceiveLocation (String): a destination file for “postReceiveCommand”, it takes the form of relative //.../ or absolute ///.../, where , , ..., can be literal or pattern, depending on “postReceiveLocationHasPatterns”.

(18) postReceiveLocationHasPatterns (true/false – default is false): a flag indicating if “postReceiveLocation” contains patterns.

(19) senderUsePassive (true/false – default is true): use passive FTP on the sender side.

(20) ReceiverUsePassive (true/false – default is true): use passive FTP on the receiver side.

(21) use (Enumeration): “literal”/”encoded”, indicating if the message is a literal or has an encoder associated with it, when use=”encoded”, encodingStyle must be specified.

(22) encodingStyle (String): URI identifying a encoder for the message body.

(23) part (String): reference to a part name in the abstract message defined in the WSDL for the operation concerned.

(24) messageCorrelate (true/false – default is true): a flag indicating if the UUID tagging based message correlation is enabled, when true, the message correlation is enabled, otherwise, message correlation is not enabled.

Attributes from ftp:transfer are grouped into "Sender", "Receiver", "Message Encoding", "Message Part", "Message Correlate" (QoS : Usability)
as shown in figure 12.

Figure 12. Attribute Grouping for ftp:transfer

* ftp:message

#	Element Name	Attribute Name	Description	Mandatory	Default	Example
1	ftp:message	ftp:messageRepository	directory on FTP server where messages are stored, staged, retrived and archived	Yes	N/A
2	ftp:message	ftp:messageName	message name, usually is a name pattern expression	No	%u
3	ftp:message	ftp:messageNamePrefixIB	message name prefix for inbound message	No	req.
4	ftp:message	ftp:messageNamePrefixOB	message name prefix for outbound message	No	resp.
5	ftp:message	ftp:pollIntervalMillis	the polling interval in milli seconds when ftp:message is used as inbound	No	N/A
6	ftp:message	ftp:archive	if message is moved to a archive directory after retrieved	No	true
7	ftp:message	ftp:protect	if message is moved to a protect directory before overwritten by next message	No	true
8	ftp:message	ftp:stage	if staging is enabled for message transportation	No	true
9	ftp:message	ftp:use	weather the message is used as a literal or encoded by an encoder - encoded/literal	No	N/A	literal
10	ftp:message	ftp:part	reference to the part name of the abstract message	No	N/A
11	ftp:message	ftp:encodingStyle	encoding style used to identify an associated encoder	No	N/A	ud1encoder-1.0
12	ftp:message	ftp:messageCorrelate	if message name GUID tagging is enabled to correlate request to a response during a synchronous service invoking	Yes	true

Among other message transfer information, implicitly assumes the working directories layout shown below for per service message exchange.

Figure 5. working directories layout for per service message transfer specified by ftp:message

(1) messageRepository (String): a base directory on FTP server, where sub-directories are created as working directories for conducting message transfer, see Figure 5 for an example, where messageRepository = MSG_REPO – a path relative to login account home directory, and working directories are created using default values such as “inbox”, “instage”, “inarchive”, “outbox”, “outstage”, and etc.

(2) messageName (String – default “%u”): message name, i.e., the name of the FTP file created for each message transported via FTP, usually it is a name pattern expression containing special symbols (escaped by percentage sign) such as %u (a UUID value), %h%h (hour of current time), %S%S%S%S (millisecond of current time), etc.

(3) messageNamePrefixIB (String – default is “req.”): a prefix added in front of the messageName to form the actual message name for messages transported in the INBOUND direction (consumer to provider), it should not contain any pattern symbols nor percentage sign.

(4) messageNamePrefixOB (String – default is “resp.”): a prefix added in front of the messageName to form the actual message name for messages transported in the OUTBOUND direction (provider to consumer), it should not contain any pattern symbols nor percentage sign.

(5) pollIntervalMillis (Integer): interval for an inbound component polling the target, default is 5000 milliseconds.

(6) archive (true/false - default is true): a flag indicating if message will be archived after it is fetched by a component (either consumer or provider), when true, the message will be archived (moved to a dedicated directory such as “inarchive” or “outarchive”), when false, the message will be deleted.

(7) protect (true/false - default is true): a flag indicating if in the way message will be moved to a dedicated directory such as “inprotect” or “outprotect” before incoming message overwrite it, when true, in the way message will be moved (protected), when false, overwritten.

(8) stage (true/false – default is true): a flag indicating if staging is enabled or not during message transfer.

(9) use (Enumeration): “literal”/”encoded”, indicating if the message is a literal or has an encoder associated with it, when use=”encoded”, encodingStyle must be specified.

(10) encodingStyle (String): URI identifying a encoder for the message body.

(11) part (String): reference to a part name in the abstract message defined in the WSDL for the operation concerned.

(12) messageCorrelate (true/false - default is true): a flag indicating if the UUID tagging based message correlation is enabled, when true, the message correlation is enabled, otherwise, message correlation is not enabled.
Attributes from ftp:message are grouped into "Messaging Configuration", "Message Encoding", "Message Part", "Message Correlate" (QoS : Usability)
as shown in figure 13.

Figure 13. Attribute Grouping for ftp:message

Extensibility Elements Validation Rules

A set of validation rules are introduced and can be checked at design time and enforced at runtime as well, such that errors in extensibility element's settings can be detected as early as possible.

The following table list all the validation rules and their corresponding error messages are shown in “comment” column, see APPENDIX B for a list of all validation error messages.

Name spaces:

xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:ftp="http://schemas.sun.com/jbi/wsdl-extensions/ftp/"

Design Time Validation Rules:

element	attribute	rule	comment
ftp:binding		for one operation, there can be at most 1 ftp:binding	FTPBindingValidation.ONLY_ONE_FTP_BINDING_ALLOWED
ftp:address		if ftp:binding presents for the operation, ftp:address must present	FTPExtValidation.MISSING_FTP_ADDRESS
ftp:address	url	when ftp:address presents, attribute url is mandatory, and must be a valid FTP URL defined as follows: ftp://<user>:<password>@<host>:<port>	FTPAddress.MISSING_FTP_URL
ftp:address	url	url must start with ftp://	FTPAddress.INVALID_FTP_URL_PREFIX
ftp:address	url	must be a valid URL defined as follows: ftp://<user>:<password>@<host>:<port>	FTPAddress.MALFORMED_FTP_URL
ftp:address	url	url should not include a path	FTPAddress.INVALID_FTP_URL_PATH_NOT_ALLOWED
ftp:address	url	url must include	FTPAddress.MALFORMED_FTP_URL_HOST_REQUIRED
ftp:address	url	url still have a place holder value – not set with a real URL	FTPAddress.REPLACE_FTP_URL_PLACEHOLDER_WITH_REAL_URL
ftp:address	url	in URL must be positive integer	FTPAddress.INVALID_PORT_IN_URL
ftp:address	useUserDefinedHeuristics, userDefDirListStyle	if useUserDefinedHeuristics = true, userDefDirListStyle must be specified	FTPAddress.MISSING_UD_DIRLSTSTYLE_NAME
ftp:address	useUserDefinedHeuristics, userDefDirListHeuristics	if useUserDefinedHeuristics = true, userDefDirListHeuristics must be specified	FTPAddress.MISSING_UD_HEURISTICS_CFG_LOC
ftp:address	cmdChannelTimeout,dataChannelTimeout	Must be >= 0	FTPAddress.INVALID_FTP_CH_TIMEOUT
ftp:transfer	sendTo, receiveFrom	both sendTo and receiveFrom not specified is a sure invalid ftp:transfer	FTPTransfer.BOTH_SENDTO_AND_RECEIVEFROM_ARE_NOT_SPECIFIED
ftp:address	preSendCommand, preSendLocation, postSendCommand, postSendLocation, preReceiveCommand, preReceiveLocation, postReceiveCommand, postReceiveLocation	if pre/post operation presents, i.e., not “NONE”, corresponding location must be specified.	FTPTransfer.PRE_POST_OPERATION_WO_LOCATION
ftp:transfer	sendTo, receiveFrom, preSendLocation, postSendLocation, preReceiveLocation, postReceiveLocation	It is invalid to specify a directory (i.e., path ending with '/') as value for these attributes.	FTPTransfer.A_PATH_POINTING_TO_FILE_REQUIRED
ftp:transfer	use, encodingStyle	If use=”encoded”, encodingStyle must be specified with a URI identifying a encoder.	FTPTransfer.MISSING_STYLE_WHEN_USE_ENCODED
ftp:message	use, encodingStyle	If use=”encoded”, encodingStyle must be specified with a URI identifying a encoder.	FTPMessage.MISSING_STYLE_WHEN_USE_ENCODED
ftp:message	messageRepository	messageRepository must be specified	FTPMessage.A_PATH_POINTING_TO_MESSAGE_EXCHANGE_AREA_REQUIRED
ftp:message, ftp:transfer		ftp:binding presents, but there is no ftp:transfer or ftp:message in wsdl:input	FTPBindingValidation.NO_EXTENSIBILITY_ELEMENT_FOUND_IN_INPUT
ftp:message, ftp:transfer		ftp:binding presents, but there is no ftp:transfer or ftp:message in wsdl:output	FTPBindingValidation.NO_EXTENSIBILITY_ELEMENT_FOUND_IN_OUTPUT
ftp:message, ftp:transfer	part	when part is specified in ftp:message or ftp:transfer, the referenced part must exist in the corresponding abstract message definition	FTPExt.PART_REFERENCE_INVALID
ftp:message, ftp:transfer	pollIntervalMillis	must be > 0	FTPExt.INVALID_POLL_INTERVAL
ftp:message, ftp:transfer		actually this rule concerns operation binding element wsdl:operation, the input and output binding element(s) or wsdl:operation element should match the corresponsing abstract operation's input and output child element(s), e.g., if the abstract operation has one input and one output, then the operation binding should also have one input and one output, if the abstract operation only requires one input, then the operation binding should also have only one input accordingly.	FTPBindingValidation.OP_SIG_MISMATCH_BINDING_ABSTRACT
ftp:message, ftp:transfer		for a FTP BC operation binding, if it requires input and output, then its input and output binding should have the same type of FTP BC extensibility elements.	FTPBindingValidation.INPUT_OUTPUT_REQUIRE_SAME_TYPE_FTPBC_EXT
ftp:transfer		when ftp:transfer presents in wsdl:output, it presents at most once.	FTPBindingValidation.ATMOST_ONE_TRANSFER_IN_OUTPUT
ftp:transfer		when ftp:transfer presents in wsdl:input, it presents at most once.	FTPBindingValidation.ATMOST_ONE_TRANSFER_IN_INPUT
ftp:message		when ftp:message presents in wsdl:output, it presents at most once.	FTPBindingValidation.ATMOST_ONE_TRANSFER_IN_OUTPUT
ftp:message		when ftp:message presents in wsdl:input, it presents at most once.	FTPBindingValidation.ATMOST_ONE_TRANSFER_IN_INPUT
ftp:message	messageNamePrefixIB	When presents, should not contain percentage sign %	FTPMessage.IB_MSG_PREFIX_HAS_PATTERN
ftp:message	messageNamePrefixOB	When presents, should not contain percentage sign %	FTPMessage.OB_MSG_PREFIX_HAS_PATTERN
ftp:operation		ftp:operation must present when ftp:binding presents	FTPBindingValidation.MISSING_FTP_OPERATION
ftp:operation		ftp:operation presents but ftp:binding is not	FTPBindingValidation.FTP_OPERATION_WO_FTP_BINDING
ftp:operation		ftp:operation can present at most once as child element of wsdl:operation	FTPBindingValidation.AT_MOST_ONE_FTP_OPERATION
ftp:operation		when presents, must reference an abstract operation	FTPBindingValidation.OP_ABSTRACT_NOT_FOUND

Runtime Time Validation Rules:
All the design time rules will be checked at runtime also and in addition to that, the proxy information is validated as follows: If useProxy = true, proxyURL must be specified and must be a valid proxy URL in the form of:

{socks4|socks5}://[<user>[:<password>]@]<host>[:<port>]

Runtime validation error messages are similar to those of design time
and they are not listed here for brevity.

6. Usage of FTP BC Extensibility Elements

Please refer to FTP BC wiki page, for video captures, showing how to
use FTP BC extensibility elements in a WSDL, and further implement
and/or invoking the services defined by the WSDL in business
processes (as BPEL scripts).

7. Message Types And Encoding

As described in the extensibility elements, the following attributes
are used for message encoding:

• ftp:message->use, ftp:transfer->use – the value can be “literal” meaning the
  

message part is used as is (no encoder associated to encode it)
or “encoded” meaning the part has to be encoded by an encoder
specified by another attribute - “encodingStyle”.

• ftp:message->part, ftp:transfer->part – a reference (by name) to the message-part
  

in the abstract message, when not specified the first part is
picked as the payload.

• ftp:message->encodingStyle, ftp:transfer->encodingStyle – a name associated with an encoder
  

which will parse the part into a XML model.

8. References

• JBI Specification 1.0 (JSR 208)
  
• FTP BC Clustering Support Design
  

9. APPENDIX

APPENDIX A: Sample User Heuristic Definition

1. --------------------------------------------------------------------------
   
2. Section: UNIX
   
3. --------------------------------------------------------------------------
   
4. 
   

UNIX!Commands Supported By FTP
Server!value=APPE%CWD%DELE%LIST%MKD%NOOP%PASS%QUIT%RETR%RNFR%RNTO%SITE%STOR%TYPE%USER!set=APPE%CWD%DELE%LIST%MKD%NOOP%PASS%QUIT%RETR%RNFR%
RNTO%SITE%STOR%TYPE%USER
UNIX!Header Lines To Skip!value=1!set=1
UNIX!Header Indication Regex Expression!value=^ *total!set=^ *total
UNIX!Trailer Lines To Skip!value=0!set=0
UNIX!Trailer Indication Regex Expression!value=!set=
UNIX!Directory Indication Regex Expression!value=^ *d!set=^ *d
UNIX!File Link Real Data Available!value=Yes!set=No%Yes
UNIX!File Link Indication Regex Expression!value=^ *l!set=^ *l
UNIX!File Link Symbol Regex Expression!value=[ ]->[ ]!set=[ ]->[ ]
UNIX!List Line Format!value=Blank Delimited!set=Blank Delimited%Fixed
UNIX!Valid File Line Minimum Position!value=9!set=9
UNIX!File Name Is Last Entity!value=Yes!set=No%Yes
UNIX!File Name Position!value=9!set=9
UNIX!File Name Length!value=0!set=0
UNIX!File Extension Position!value=0!set=0
UNIX!File Extension Length!value=0!set=0
UNIX!File Size Verifiable!value=Yes!set=No%Yes
UNIX!File Size Position!value=5!set=5
UNIX!File Size Length!value=0!set=0
UNIX!Special Envelope For Absolute Pathname!value=!set=
UNIX!Listing Directory Yields Absolute Pathnames!value=No!set=No%Yes
UNIX!Absolute Pathname Delimiter Set!value=///!set=///
UNIX!Change Directory Before Listing!value=No!set=No%Yes
UNIX!Directory Name Requires Terminator!value=No!set=No%Yes

APPENDIX B: Validation Error Code

Omitted for brevity, also the validation error messages grows, for the current, check out the Bundle.properties from CVS