The discussion on very large messages focused on the significant effect on the design of messaging endpoints. Endpoints cannot assume that all messages can be processed in memory, and may need to be able to chunk portions of received messages to disk.

Also, discussion revealed that at least one STAR BOD, Inventory Update, may result in very large messages.

Business analysts and BOD designers should take into account that extremely large messages can cause both business and technical problems, BOD designers should strive for flexible patterns business patterns that allow for small messages.

Discussion centered on the complexity of handling time out issues; if a synchronous message times out the receiving system should be able to back out any changes. Systems that are unable to support back-out of transactions should lean toward asynchronous messaging styles.

Discussion was that business analysts and BOD designers need to discuss these requirements before the issues can be related to Transport.

The initial STAR Collaboration requirements included a requirement for Push Messaging. Discussion focused on the fact that the Push requirement is similar to the concept of store-and-forward, in other words the message sender is queuing outbound messages. Consensus was reached that system implementers can queue and push messages and no specific changes need to be made to the guidelines to support this model.

There was discussion on the possible use of cell phones and or PDA (Personal Digital Assistant) devices for STAR Transport messaging. There was no consensus on any needed changes to the Guidelines to support these devices, and this is still an open issue that should be raised with STAR membership in general to understand if there are requirements to support these types of devices.

There was discussion on how STAR Transport and STAR BOD specifications can address long running business processes. There was no consensus on making changes to the STAR Transport Guidelines to support these concepts, the discussion focused on the Transport not needing to be aware of long running processes, but that the Transport SHOULD be able to easily share key information, in particular the MessageID of messages, so that backend applications can correlate messages and implement higher level business processes that span multiple messages.