Channels developed

  1. Basically, the channel is BTT enabled. Actions are invoked by the BTT controller and the actions are the bridges between the "channel request sequences" and the reusable business services.
  2. During the course of the operation in channel side, the BTT controller will put data into the CHA in a well defined manner using CHA Facade. Data may be obtained from different screens, but whether to put the data into CHA is business requirement-driven, not screen-driven.
  3. The business service (EJB or BPEL in this case) is invoked by the BTT controller.
  4. Depending on the business requirements, the business services may invoke other shared components subsequently. The shard components may reside in other EJB containers.
    Note: Controller is expected to be in the standalone Container while the business services and the CHA services will be residing in the same or different EJB container.
  5. All components involved obtain data from CHA in the same way, which is well defined by customer across the enterprise. When they complete their part of processing, the results can be sent back to the controller for result-display.
    Note: Because of the Shared Context, as long as the business requirements do not change, the change in channel request sequence should not require changes to the business service, nor the way data is passed to/from the CHA.

    Technically speaking, to reuse or share the same context instance by controller or business service, the context instanceID (the unique ID created by CHA) is necessary and mandatory to be held by controller or transformed between channel side and business service.

    The figure below shows the process from 1 to 5.

    Channel

  6. If a new BTT-based channel is introduced, the new channel is expected to be able to make use of the existing reusable business services quickly if required. The controller can put data into the CHA in a well defined manner as in the new Channel. Same well-defined "areas" and the new "areas" of the CHA can be used.
  7. Similar to the existing Channel, the controller can then invoke the business services to perform the task. The business services invoked can may also invoke other sharable components.
  8. All involved components obtain data from CHA in the same way.
    Note:
    • The Controllers of the two channels may be the same BTT controller.
    • The addition of the new channel will not necessitate the existing business services components to be modified if there are no business requirement changes that affetct them.

    The following figure shows the process from 6 to 8.

    New channel

  9. If a new non-BTT channel is introduced and required to share the reusable business services developed, the new channel can pass data to Service Gateway, which shares the data required using the CHA in the same across-the-enterprise well-defined way. There are other technical alternatives, for example, Web Services, http, but the architecture arrangement is similar.
  10. Service Gateway provides Strong Type based interface definition, and then transforms parameter into shared Context which is re-used by business services. The addition of the new channel will not necessitate the existing business services components to be modified if there are no business requirement changes that affect them.
  11. Service Gateway then accesses reusable business service by the same way. As the execution result, Service Gateway also transforms result data in CHA server to channel specified response data. No extensive changes to the reusable business components are expected unless business-wise required.

    The figure below shows the process from 9 to 11

    Non-BTT channel