Overview
The Directly Integrated Single Channel application pattern represents a starting point for delivering e-business applications. The Directly Integrated Single Channel application pattern extends the Stand-Alone Single Channel application pattern by providing connections to one or more back-end systems, but a single delivery channel is still assumed.
The next step is to choose Runtime patterns that most closely match the requirements of the application. A Runtime pattern uses nodes to group functional and operational components. The nodes are interconnected to solve a business problem. Each Application pattern leads to one or more underpinning Runtime patterns.
The Runtime pattern does not differentiate between intranet and Internet implementations. However, you should be aware of certain issues:
- Bandwidth is usually greater in an intranet, allowing the use of more network-intensive solutions, such as thick clients.
- Security may be less of an issue in an intranet. However, protecting the network is still important and firewalls protecting resources from unauthorized access are still advisable.
- Due to corporate rules you may expect certain browsers to be used, allowing you to exploit all available features and not code to the least common denominator.
Generic DC runtime patterns
Basic Runtime pattern
Although this Runtime pattern was historically used as an entry-level footprint, the proliferation of hacker attacks has caused it now to be regarded as an anti-pattern. However for the moment we will keep it on the web site because it has been used in the IBM Redbook, IBM WebSphere V5 Edge of Network Patterns (SG24-6896), as the simplest base design to which various High Availability and High Performance nodes can be added.
Directly Integrated Single Channel application pattern: Runtime pattern
Design Last Updated: 11-5-2002
(Click a node to get a detailed explanation.)
Example
A discount brokerage firm wishes to establish a Web sales channel. They may select the Directly Integrated Single Channel application pattern because real-time integration with their back-end applications is critical. In implementing this application they could use the Runtime pattern shown above. The Web application server would host the presentation and some limited business logic. The majority of the business logic would continue to reside on existing applications and data sources. The Directory and Security Services node is used to implement features including authentication and authorization.
Runtime pattern: Variation 1
This variation to the basic Runtime pattern uses one Web server redirector containing the Web server and one application server, effectively splitting the function of a Web application server across two machines. In this case the application server resides in the internal network to provide it with more security. The application server node will run both presentation and business logic. The Web server remains in the DMZ and serves static pages. A Web server redirector is used to forward the requests from the Web server to the application server.
Directly Integrated Single Channel application pattern: Runtime pattern: Variation 1
Design Last Updated: 06-13-2006
(Click a node to get a detailed explanation.)
The nodes depicted with dotted lines provide important functionality, but are optional for the focus of the Runtime pattern.
The discount brokerage application described earlier can be deployed on this Runtime pattern variation to achieve a higher level of security. The discount brokerage developed complex investment tools within the Web application. These tools needed to be protected behind a firewall. This approach helps secure their highly sensitive business logic.
Runtime pattern: Other Variations
Other variations to the Directly Integrated Single Channel application pattern::Basic runtime pattern can be used to address the availability and performance requirements of your application.
As with the Stand-Alone Single Channel application pattern::Runtime pattern, the Non-Functional Requirements custom designs can be applied to the Directly Integrated Single Channel application pattern::Basic runtime.
SOA profile
Design Last Updated: 07-12-2005
(Click a node to get a detailed explanation.)
In this SOA profile, the application server node becomes the service consumer with the back-end applications acting as service providers. The service consumer is connected to the service providers via a simple enterprise service bus. Due to the nature of the SOA approach, the consumer and provider could be reversed.
Implementing the SOA profile with an ESB adds extra capabilities to the runtime pattern, for example routing and decomposition capability. Because of this, the SOA profile for the Directly Integrated Single Channel runtime pattern can be applicable to multiple Self-Service application patterns. This highlights the fact that using SOA facilitates the future expansion of solution functionality without requiring major changes to the middleware structure.
- Minimizes the number of adapters required for each point-to-point connection to link service consumers to service providers.
- Improves reuse in multiple point-to-point scenarios.
- Addresses any technical and information model discrepancies amongst services.
- Provides a single configuration point for distributed deployment.
- Decouples service requesters from providers
- Provides a common access point for service requesters
- Provides centralized security for services