Application Development Overview
TIBCO ActiveMatrix BusinessWorks™ applications can be developed using either the traditional phases of waterfall development, or using an incremental and iterative approach such as Scrum.
The TIBCO ActiveMatrix BusinessWorks™ Application Development guide explains the following:
- Approaches to application development.
- Considerations to be made when building an application.
- Information on how to work with various software components and how to generate the deployment artifact.
Application development consists of the following phases:
- Analysis - Analyze the business problem and identify the applications, modules, services, and processes that need to be created to solve the problem.
- Application Creation/Design - Create one or more applications identified during the analysis phase. TIBCO Business Studio™ for BusinessWorks™ provides the design-time environment to design an application and its components that implement the business logic.
- Service Design - Create the services identified in the analysis phase. The services can be accessed by processes that are used to implement the business logic.
- Process Design - Create the processes that implement the business logic. These processes can access the services configured.
- Generating Deployment Artifacts - Create a deployment artifact — an archive file, after creating and configuring the processes and services.
There are two main approaches to application development: top-down and bottom-up.
Top-down is a design approach that begins with a holistic view of the application, specifying the major functions or interfaces it will need before the next level of details. This process is repeated until the most granular pieces are designed and implemented. The application is then ready for testing. Top-level services and processes can be designed and developed first before moving to the lower levels.
In the bottom-up approach, the basic elements of the application are first specified and developed as building blocks. These reusable parts are then connected to form functional units that serve a higher purpose. This process is repeated until the design grows in complexity and completeness to form an application. The building blocks can be created as layers of services, subprocesses, and shared resources. These building blocks are assembled together to form application modules or shared modules. These modules are then assembled together to form an application.
In practice, even a new application can have existing services to leverage from. As a result, a problem can be approached from both top and bottom, resulting in a hybrid approach. The bottom part can start creating reusable shared modules to encapsulate existing system services that are well defined. The top part can start with the business requirements and break it down to intermediate layers, until the reusable modules are reached.
Either top-down or bottom-up approaches can be used with service-driven or process-driven design patterns. Service-driven means the service contract or interface of each functional component is formalized first. The processing logic behind the service simply becomes an implementation detail that is encapsulated. This is where these SOA design principles can be followed: standardized service contract, loose coupling, service abstraction, service reusability, service statelessness, and service composability.
Process-driven means the business processes or integration flows are first realized and captured. Service contracts may or may not be applicable in a process-centric application, especially for batch or EAI-type automation scenarios.
Each of these approaches can be followed in conjunction with the waterfall or Scrum development methods.
The generation of the deployment artifact indicates that the application can be deployed to the run time. Any further changes to the design-time configurations require the deployment artifact to be regenerated. For deployment and administration details, see TIBCO ActiveMatrix BusinessWorks™ Administation guide.