 |
|
| 4. Recommendations | |
| 4.2 Recommendations | |
| 1. The destination of a
message must be dynamic--and does not fall into the specific categories
of Broadcast, Contend, Send to Specific IC, etc. The difficulty
here is that in some instances, it is not sufficient for example,
to allow any Visa Instrument to receive a payment message.
Such a message must be sent to a specific IC, but one that is determined
during execution, not as part of the model.
2. Caller/Recipient Model. Difficulty arises when an IC must respond to a specific message from another IC. Although this can be accomplished (as shown) by adding states which cause an IC to await a response message, this is still a tenuous relationship. 3. Extending the design might also include the ability to "reuse" transitions. This could merely be a function of the IC Builder. As described in the model of the G-Net, there may be a hierarchical nature to the IC design, where a particular "subroutine" should be reused. 4. The final recommendation is that of code reuse and compatibility. As stated earlier, the e-wallet is best coded in Java due to the platform independent nature. Using Java ensure that all wallets are compatible and provide equal functionality. Additionally, if the system is implemented in Java, an additional recommendation would be to create a conformance to the JavaBean model.
|
|