PAT.Application Hosting: Difference between revisions
m (link fixes) |
(updated pres eng optional) |
||
(One intermediate revision by the same user not shown) | |||
Line 20: | Line 20: | ||
}} | }} | ||
{{Pattern Type Composition}} | {{Pattern Type Composition}} | ||
{{Pattern Type Composition Row | |||
|facility=BT.Application Engine | |||
|choice=must | |||
|reason=This BBT delivers the core functionality of the pattern. | |||
}} | |||
{{Pattern Type Composition Row | {{Pattern Type Composition Row | ||
|facility=BT.Presentation Engine | |facility=BT.Presentation Engine | ||
|choice= | |choice=may | ||
|reason=This BBT delivers an important part of the core functionality of any application hosting solution: the presentation of the application to the client. The technology used here must match those available at the client (e.g. HTTP implies browser, X Window implies X Server etc) | |reason=This BBT delivers an important part of the core functionality of any application hosting solution: the presentation of the application to the client - although an Application Hosting facility may be deployed behind a separate facility that takes care of this. The technology used here must match those available at the client (e.g. HTTP implies browser, X Window implies X Server etc) | ||
}} | }} | ||
{{Pattern Type Composition Row | {{Pattern Type Composition Row | ||
Line 29: | Line 34: | ||
|choice=may | |choice=may | ||
|reason=When combining multiple hosted applications, Presentation Aggregation may serve to share (presentation-specific) functionality. | |reason=When combining multiple hosted applications, Presentation Aggregation may serve to share (presentation-specific) functionality. | ||
}} | }} | ||
{{Pattern Type Composition Row | {{Pattern Type Composition Row | ||
Line 49: | Line 49: | ||
|choice=may | |choice=may | ||
|reason=The Application Hosting facility should preferably be managed by a centralized facility, but if this is not possible or feasible, then a means must be offered to manage the facility itself - and the Control Interface offers this means. Note that this facility is limited to the Application Hosting facility, and cannot directly manage the applications running on the Application Hosting facility. | |reason=The Application Hosting facility should preferably be managed by a centralized facility, but if this is not possible or feasible, then a means must be offered to manage the facility itself - and the Control Interface offers this means. Note that this facility is limited to the Application Hosting facility, and cannot directly manage the applications running on the Application Hosting facility. | ||
}} | |||
{{Pattern Type Composition Row | |||
|facility=BT.Message Coordination | |||
|choice=may | |||
|reason=If an Application Hosting facility is to be able to offer its applications the possibility to send out messages (such as e-mail), then this function acts as intermediary between the application and the message handling service | |||
}} | }} | ||
{{Table Ending}} | {{Table Ending}} |
Latest revision as of 06:20, 16 August 2013
This page has maturity level 3 (usable)
PAT | Application Hosting | Version: | 0.2 | ||
---|---|---|---|---|---|
Document type: | Pattern Type | Owner: |
Description
This Pattern Type belongs to "Infrastructure Sector Business Support". Application hosting provides a set of facilities to accommodate (business) application services. Accommodation entails
- the runtime environment that the applications can use
- a means to expose or publish the application services' results using web protocols
- the connectivity that consumers of the application's services require for access
- and optionally, extra functionality to service the application services.
Authentication/authorization is optionally included in the pattern type, but should preferably be performed using the pattern Access Security, as most necessary security functions are located in this pattern.
Graphical Overview
This is the graphical representation of the infrastructure functions in this Pattern Type, plus their main relations:
(The source file of this picture can be downloaded here).
Pattern Type Composition
This pattern has the following mandatory and optional subfunctions, expressed in Building Block Types:
Icon | Function | WA | Inclusion | Rationale |
Application Engine | SE | mandatory | This BBT delivers the core functionality of the pattern. | |
Presentation Engine | SE | optional | This BBT delivers an important part of the core functionality of any application hosting solution: the presentation of the application to the client - although an Application Hosting facility may be deployed behind a separate facility that takes care of this. The technology used here must match those available at the client (e.g. HTTP implies browser, X Window implies X Server etc) | |
Presentation Aggregation | SE | optional | When combining multiple hosted applications, Presentation Aggregation may serve to share (presentation-specific) functionality. | |
Scheduling | MW | optional | While application hosting usually responds to client request, it may be convenient to have the application also respond to other triggers; the Scheduler BBT provides the capability for this. | |
Transaction Coordination | MW | optional | When multiple instances of one business application are necessary AND the transactions that the facility must process are interdependent, then this BBT can provide the necessary coordination. | |
Control Interface | SE | optional | The Application Hosting facility should preferably be managed by a centralized facility, but if this is not possible or feasible, then a means must be offered to manage the facility itself - and the Control Interface offers this means. Note that this facility is limited to the Application Hosting facility, and cannot directly manage the applications running on the Application Hosting facility. | |
Message Coordination | SE | optional | If an Application Hosting facility is to be able to offer its applications the possibility to send out messages (such as e-mail), then this function acts as intermediary between the application and the message handling service |
Pattern Type Neighbors
This pattern has the following mandatory and optional relations with adjacent (sub)functions, expressed in Pattern Types (PAT). Note: if the table below is empty, then there are no architecturally prescribed relations with adjacent subfunctions:
Function | Adjacency | Description |
Raw Storage | optional | Should the Application Hosting facility need to offer hosted applications the ability to store unstructured data, then inclusion of this pattern is needed. |
Data Management | optional | Should the Application Hosting facility need to offer hosted applications the ability to store structured data, then inclusion of this pattern is needed. |
Authentication & Authorization | optional | When authentication/authorization (A&A) is needed and cannot be (fully) catered for in an Access Security pattern, then the A&A facility is necessary. Authorization can be paired with Application Hosting relatively easy, but application of authorization is more secure if it takes place earlier in the traffic stream from client to application - hence the usage of Access Security --including A&A-- is preferable. |
Message Handling | optional | This facility offers the means to deliver data to applications, and/or to enable applications to send data out. It may provide asynchronous messaging (like email or XML messages), synchronous messaging (like SOAP messages over HTTP or RPC) or both. |
Pattern Variants based on this type
Pattern Variant | Brief description | Owner | maturity |
---|---|---|---|
PAV.Application Hosting.Cloud - Internal Access Only Best Effort | Cloud - Internal Access Only Best Effort | S.A.D. Jumelet | 3 |