States are basic building blocks that you can link sequentially to model application-process flows.
- Standalone – implemented natively.
- Service – proxy to a Web service or aggregated Web services that are exposed through the service-oriented architecture (SOA) layer.
You can meet customer requirements by developing custom states using the State SDK. You can add custom states dynamically using the plug-in mechanism that is enabled by the OSGi services registry.
- Interactive – provide a user-interactive mobile service; typically invoked when mobile consumers send a keyword to a preassigned short code.
- Event – designed for batch processing; invoked by events, such as scheduled times, system triggers, or external triggers.
Most states can be used in either application type. However, there are a few states that are available only to a specific application type. For example, you can use the Process Subscriber state only in event applications, because it relies on the callback mechanism provided by the processing engine. You can use Application Call and Application Call Return states only in interactive applications, because these states do not support the callback mechanism. The Application Composer prevents you from adding invalid states to an application.