The following are some critical-thinking questions that architects should think about before getting into architecture description:
- What is the scope of the architecture?
- Who are the intended audiences for the architecture description?
- What architecture style should be used for architecture description?
- What approaches and methodologies should be adopted?
- Are there any helpful tools?
· A validated architecture does not guarantee the quality of the resulting system. How can downstream design decisions undermine the architecture’s ability to meet its quality objectives?
· How can the introduction of evaluations help your organization adopt a standard method of architectural description?
- Why are you doing an estimate?
- Do you know the relative levels of effort of project phases and tasks in your organization?
- What factors do you have available?
- Do your organization’s time- and expense-tracking numbers feed back into your estimation mechanisms?
- After you have built an estimate, can you explain where your numbers come from?
- What are the sources and sizes of document sets and streams to be analyzed? How large is the topic space or knowledge schema? How dynamic is it?
- Will there be any formal knowledge-representation or document-organization schemes? Will these be homegrown and stored in the database? Will more formal knowledge-representation schemes be considered? What repository will store derived information?
- Are there experts who will read, validate, refine, and calibrate various intelligence-gathering and inference processes over time? Are these experts threatened by the use of an automated system?
- Should the system process be primarily automatic and self-sustaining? If not, will responsibility be centralized or distributed?
- Will the end results of your queries be knowledge about the states of documents (term frequency and trends, regular expression conformance, term proximity and co-occurrence counts, vector-representations of author keywords, and so on)? Alternately, will the end results be concerned with the inferred probabilistic states of the world, as inferred from the documents (the likelihood that a given off-label usage will result in injury or penalty to Contoso)?
- Which is desired: a point solution or a more general infrastructure? What is a realistic end goal by which to define project success?
· In what parts of your architecture do you employ asynchronous communication? Why? If not, why not?
· Do you treat distribution boundaries different from logical boundaries, in your architecture? If so, in what way are they different?
· How would you test the scalability of an architecture? When would be the earliest that you could perform such a test?
· When one is architecting solutions, why is it important to think about maintenance?
· How did “soft skills” affect the outcome of this story? Why are they important for an architect?
· Which elements of this story demonstrated the value of business, instead of technical knowledge? Which characters held this knowledge?
To benefit fully from leveraging software architectural and design patterns, an architect must always try to answer the following questions:
· What is the problem that I am trying to solve?
Understand conceptually the problem that the solution is intended to solve. Software architecture begins at the conceptual level, and it is imperative that architects have an understanding of the big picture. The ability to articulate the solution succinctly in nontechnical terms is a good indication that the problem space is understood.
· How has this problem been solved in the past?
In any software solution, there is a good chance that a similar problem has been solved in the past. Research how this problem has been solved, and leverage the design to solve the new problem.
· How might the solution be extended in the future?
The intent of many patterns is to provide a level of extendibility for a solution. If the solution’s requirements for extendibility are understood, it might be beneficial to leverage those patterns early on in the design.
User Experience
· Remember: There is always a UE. What can you do to make it positive?
· Are you following the UI standards? Should you follow the standards?
· Is there a way to increase the system’s responsiveness?
· What are your users’ key tasks? How easy is it to perform them? How can you make it easier?
· What operational requirements does a service directory satisfy?
· Should JMS services have WSDL definitions? If so, why?
· What is the difference between orchestration and choreography?
· When you are choreographing services, will you need to add transaction semantics (for example, rollback)?
· Where are your developers resorting to copy-paste reuse?
· How much better is the code from the top 20 percent of your developers than from the bottom 40 percent?
· How much time is spent on problems stemming from poor communication between domain experts and developers?
- Why is it important to understand different architecture styles?
- Would a pipe-and-filter style be better for an online-transaction processing (OLTP) or a warehouse application? Why?
- What is meant by synchronous and asynchronous topologies?
· Is there any difference between an Enterprise Service Bus and an Enterprise Message Bus?
· Are there any real issues in today’s hub-and-spoke integration architecture? If we were to replace the architecture with an ESB, how much of these issues would be solved?
· Can we buy an ESB from some market one fine morning that can then straightaway solve all our integration headaches?
· Bakker, Loek. “Goodbye Hub-and-Spoke, Hello ESB? Integration Architecture with BizTalk 2004.” .NET Developer’s Journal. September 12, 2005.(Accessed January 24, 2007.)
· Fielding, Roy Thomas. “Architectural Styles and the Design of Network-Based Software Architectures.” Dissertation (Ph.D.), University of California, Irvine. 2000. (Accessed January 24, 2007.)
· Gavin, Lee, et al. “An EAI Solution Using WebSphere Business Integration (V4.1).” IBM Redbooks. July 28, 2003. (Accessed January 24, 2007.)
· Keen, Martin, et al. “Patterns: Implementing an SOA Using an Enterprise Service Bus.” IBM Redbooks. July 25, 2004. (Accessed January 24, 2007.)
· Keen, Martin, et al. “Patterns: SOA with an Enterprise Service Bus in WebSphere Application Server V6.” IBM Redbooks. June 6, 2005. (Accessed January 24, 2007.)
· Martinez,Frank. “Reliable Messaging in a Services Network.” Enterprise Architect Web site. June 2, 2005. (Accessed January 24, 2007.)
· “Microsoft BizTalk Server 2006: Business Process Management (BPM).”Microsoft BizTalk Web site. 2007. (Accessed January 24, 2007.)
· “Mule: Open-Source ESB and Integration Platform.” Mule Web site. 2007. (Accessed January 24, 2007.)
· “Patterns and Best Practices for Enterprise Integration.” Enterprise Integration Patterns Web site. 2007. (Accessed January 24, 2007.)
· “Service-Oriented Business Integration.” Java Technology and Business Integration Web site. 2007. (Accessed January 24, 2007.)
· Van de Putte, Geert, et al. “Using Web Services for Business Integration.” IBM Redbooks. April 14, 2004. (Accessed January 24, 2007.)
Most development shops have a handful of both seasoned businesspeople and top developers who are capable of isolating and describing a problem and building an elegant, maintainable object-oriented solution. To get the biggest bang for your customer’s buck, you want to be sure to understand the core domain of your application. The core domain is the Bounded Context that brings the most value to applying DDD.
In any given enterprise system, there are some areas that are more important than others. The more important areas tend to fall into alignment with the core competencies of the client. It’s rare that a business will be running custom general ledger software. But if that business is in insurance (going with my previous example) and their money-making offering is managing risk pools where liability is spread among all members, then they had better be darned good at rejecting bad risks and identifying trends. Or perhaps you have a client that’s a medical claims processor, and their strategy is to flank their competition on pricing by automating payments to amplify the efforts of their bill payor workforce.
Whatever the industry, your employer or client has some edge in the market, and this edge is usually where you find the custom software. That custom software is where you’re likely to find and model the core domain.
We can measure our investment in value on another dimension, namely where we invest our intellectual capital in reaching technical excellence. Too many times senior developers are the kind of people who get obsessed with new technologies. A certain amount of this is to be expected—the industry innovates at a relentless pace, and vendors are compelled to frequently release new technology offerings to satisfy their customers’ demands and stay competitive. The challenge, as I see it, is for senior developers to master the fundamental principles and patterns that contribute value to the heart of a system. It’s tempting to get wrapped up in a new framework or platform, but we need to remember the reason vendors produce these things is so we can just trust that they work.
Resulting Context
When considering integration through a message bus, you should weigh the following benefits and liabilities that are associated with it:
Benefits
- Improved modifiability. Each application has a single connection to the message bus instead of multiple dedicated connections to each of the other applications. Adding or removing an application has no impact on the existing applications. In addition, upgrading the bus interface does not require changing any applications as long as the messages remain compatible with existing ones. For example, this is the case when you add new message types.
- Reduced application complexity. The message bus transports messages between senders and receivers. Senders no longer interact with all the receivers that they need to send messages to.
- Improved performance. There are no intermediaries between the communicating applications. Communication latency depends only on how fast the message bus can move messages.
- Improved scalability. Adding applications has a constant low cost. In addition, you can add applications to the message bus until the message bus is saturated. A message bus is saturated when it cannot keep up with the data that it has to move between applications.
Liabilities
- Increased complexity. Integrating through a message bus increases the complexity of the integration solution for the following reasons:
- Architectural mismatch. The applications of an integration solution typically make conflicting architectural assumptions [Garlan95]. Designing the message bus interface and solving the mismatch around the data model is a difficult endeavor.
- Message bus access policies. Communication through a shared resource such as a message bus requires you to implement policies that ensure fair access and that resolve concurrency conflicts.
- Lowered modifiability when the bus interface breaks compatibility. Changing the message bus interface in a way that breaks compatibility typically affects all the applications that use the bus. In other words, the bus interface represents an extreme example of a published interface. Designing it requires foresight.
- Lowered integrability. All the applications that are hooked to the message bus must have the same message bus interface. Applications that have incompatible interfaces cannot use the message bus. Because the message bus interface includes a common set of command messages, message schemas, and shared infrastructure, these elements together define a common subset that may somewhat restrict the operation of the participating applications.
- Lowered security. A message bus that uses the Broadcast-Based Publish/Subscribe pattern reaches all the applications that are connected to the bus, regardless of the applications that the message is intended for. Broadcasting to all participants may not be acceptable if the messages contain sensitive data.
- Low tolerance for application unavailability. The receiver must be able to process messages when the sender passes the messages to the bus. This solution does not tolerate receiver downtime. In addition, it does not provide direct support for disconnected operation.
Operational Considerations
When a message bus becomes saturated, message delivery may take a long time or even fail. Saturation could occur after you add new applications or after you make changes to the communication profile of existing applications. For example, changes to the communication profile include changes in the message size and rate. Because both situations are common in bus-centered integration solutions, it is important to prevent saturation. This translates into monitoring the operation of the message bus and proactively keeping the message volume below the maximum capacity of the message bus.
- Publish/Subscribe. This pattern helps keep cooperating systems synchronized by one-way propagation of messages; one publisher sends a message to any number of intended subscribers.
- Message Bus Architecture [Hohpe04]. This pattern revolves around a messaging infrastructure, and it relies on a canonical data model and a common command set that is mentioned earlier in “Liabilities.”
- Blackboard [Buschmann96]. The Blackboard pattern describes a shared storage area that the components of the pattern use to communicate. Consumer components monitor the blackboard and grab the data that matches their interest. Producers put their output on the blackboard so that it becomes available to the others. Typically, integration applications such as rule engines and expert systems use this pattern.
Security Considerations
Before you use a message bus that uses Broadcast-Based Publish/Subscribe, you should consider whether this configuration meets your security requirements. The applications that are connected to the bus receive every message that goes through the message bus. Participants that require a private conversation must encrypt their communication. Also, applications that communicate through the message bus do not have intermediate components between them. In other words, no physical component exists for mapping between different security contexts. Consequently, this configuration is appropriate when the security context is managed through impersonation.
Resulting Context
Using Publish/Subscribe has the following benefits and liabilities. Evaluate this information to help you decide whether you should implement Publish/Subscribe:
Benefits
- Lowered coupling. The publisher is not aware of the number of subscribers, of the identities of the subscribers, or of the message types that the subscribers are subscribed to.
- Improved security. The communication infrastructure transports the published messages only to the applications that are subscribed to the corresponding topic. Specific applications can exchange messages directly, excluding other applications from the message exchange.
- Improved testability. Topics usually reduce the number of messages that are required for testing.
Liabilities
- Increased complexity. Publish/Subscribe requires you to address the following:
- You have to design a message classification scheme for topic implementation.
- You have to implement the subscription mechanism.
- You have to modify the publisher and the subscribers.
- Increased maintenance effort. Managing topics requires maintenance work. Organizations that maintain many topics usually have formal procedures for their use.
- Decreased performance. Subscription management adds overhead. This overhead increases the latency of message exchange, and this latency decreases performance.
Testing Considerations
The topics of a Publish/Subscribe implementation facilitate the testing of an integration solution. Subscriptions provide isolation by segmenting the message space. By subscribing only to the topics or to the content of interest, testers and testing tools have fewer messages to sift through. Likewise, by subscribing to other topics or content, testers can catch messages that are published to the wrong topic.
Security Considerations
An integration solution that uses Publish/Subscribe can restrict the participants of a message exchange, thus enabling applications to have private message exchanges. Depending on the topology, the messages may still be physically transported to all the applications in the integration architecture. For example, all the messages are transported to all the applications if your integration solution uses the Message Bus using Broadcast-Based Publish/Subscribe pattern. However, the interface between the communication infrastructure and the application enforces filtering according to each application’s subscriptions.
Operational Considerations
Many integration solutions that use Publish/Subscribe have topics or content that is dedicated to messages about the applications’ health. This separation facilitates your ability to monitor various operational parameters and to control the applications in the integration solution.
Related Patterns
For more information about Publish/Subscribe, see other similar patterns:
- Message Bus and Message Broker describe two common integration topologies.
- Observer [Gamma95] provides a mechanism for decoupling dependencies between applications.
- Publisher-Subscriber [Buschmann96] facilitates state synchronization between cooperating components.
- Publish-Subscribe Channel [Hohpe04] provides a way to broadcast events to all the receivers (subscribers) that subscribe to a specific topic.
Resulting Context
Using Pipes and Filters results in the following benefits and liabilities:
Benefits
- Improved reusability. Filters that implement simple transformations typically encapsulate fewer assumptions about the problem they are solving than filters that implement complex transformations. For example, converting a message from one XML encapsulation to another encapsulates fewer assumptions about that conversion than generating a PDF document from an XML message. The simpler filters can be reused in other solutions that require similar transformations.
- Improved performance. A Pipes and Filters solution processes messages as soon as they are received. Typically, filters do not wait for a scheduling component to start processing.
- Reduced coupling. Filters communicate solely through message exchange. They do not share state and are therefore unaware of other filters and sinks that consume their outputs. In addition, filters are unaware of the application that they are working in.
- Improved modifiability. A Pipes and Filters solution can change the filter configuration dynamically. Organizations that use integration solutions that are subject to service level agreements usually monitor the quality of the services they provide on a constant basis. These organizations usually react proactively to offer the agreed-upon levels of service. For example, a Pipes and Filters solution makes it easier for an organization to maintain a service level agreement because a filter can be replaced by another filter that has different resource requirements.
Liabilities
- Increased complexity. Designing filters typically requires expert domain knowledge. It also requires several good examples to generalize from. The challenge of identifying reusable transformations makes filter development an even more difficult endeavor.
- Lowered performance due to communication overhead. Transferring messages between filters incurs communication overhead. This overhead does not contribute directly to the outcome of the transformation; it merely increases the latency.
- Increased complexity due to error handling. Filters have no knowledge of the context that they operate in. For example, a filter that enriches XML messages could run in a financial application, in a telecommunications application, or in an avionics application. Error handling in a Pipes and Filters configuration usually is cumbersome.
- Increased maintainability effort. A Pipes and Filters configuration usually has more components than a monolithic implementation (see Figure 2). Each component adds maintenance effort, system management effort, and opportunities for failure.
- Increased complexity of assessing the state. The Pipes and Filters pattern distributes the state of the computation across several components. The distribution makes querying the state a complex operation.
Testing Considerations
Breaking processing into a sequence of transformations facilitates testing because you can test each component individually.
Related Patterns
For more information about Pipes and Filters, see the following related patterns:
- Implementing Pipes and Filters with BizTalk Server 2004. This pattern uses the Global Bank scenario to show how you can use BizTalk Server 2004 to implement Pipes and Filters.
- Pipes and Filters [Shaw96, Buschmann96, Hohpe03].
- Intercepting Filter [Trowbridge03]. This version of Intercepting Filter discusses the pattern in the context of Web applications built using the Microsoft .NET Framework. Developers can chain filters to implement preprocessing and post-processing tasks such as extracting header information and rewriting URLs.
- In-band and Out-of-band Partitions [Manolescu97]. This pattern remedies the lack of a component that has a global context in Pipes and Filters systems. The out-of-band partition is context-aware; therefore, it can configure the filters and handle errors.
Resulting Context
Using Pipes and Filters with BizTalk Server 2004 results in the following benefits and liabilities:
Benefits
- Filter reuse. BizTalk Server 2004 users can reuse both the pipeline definitions and the set of pipeline filters across different ports. For example, the MIME/SMIME encoder filter is suitable for any application that needs to send MIME or S/MIME messages.
- Amenable for graphical tools. Programming the pipeline involves connecting and configuring filters by dragging components rather than by writing source code.
- Developer specialization. Pipes and Filters fosters the division of labor between different types of users. For example, C# developers build filters by using the Microsoft Small Business Customer Manager Filter SDK. Business users and developers who use BizTalk Server 2004 can assemble them without any programming.
Liabilities
- Restricts the filter types. BizTalk Server 2004 pipelines use filters that have a single input and a single output. This implementation of Pipes and Filters cannot accommodate filters that do not fit within this constraint.
- Overhead cost. BizTalk Server 2004 pipelines are very powerful when there are business rules and other types of processes on the data. However, the business rules and processes on the data are overhead if all that is required is a simple pipe between applications.
Testing Considerations
There are two main test scenarios when you use BizTalk Server 2004 to implement Pipes and Filters. The test scenario that applies to you depends on the customization option that you choose as your implementation strategy:
- Configure a custom pipeline by using the filters that are supplied with BizTalk Server 2004. In this case, you build the custom pipeline and configure the filters by using the Pipeline Designer. You then create a test configuration that uses this custom pipeline in either a receive port or a send port. You can then submit test messages and validate the resulting output.
- Configure a custom pipeline by writing custom filters in C# or Visual Basic .NET. In this case, you can test the pipeline component by creating a test configuration that uses the component in a custom pipeline as described earlier. You can also use Microsoft Visual Studio .NET to review the pipeline component code.
Security Considerations
In addition to security features that are provided by the transports, such as encryption when using HTTPS, BizTalk Server 2004 provides security at the message level. BizTalk Server 2004 can receive decrypted messages and validate digital signatures that are attached to these messages. Similarly, BizTalk Server 2004 can encrypt messages and attach digital signatures to messages before sending them. You can also purchase or develop custom security components as required.
Note The BizTalk Server 2004 host instance runs the send pipelines and the receive pipelines within a specific security context. Therefore, any processing that the pipeline components perform operates within this security context. This security context may impose constraints on the way that the custom component accesses a database. The security context may also impose constraints on the location in the certificate store that the component can access a digital signature from.
Resulting Context
Using a gateway to provide a single point of access to an external resource has the following benefits and liabilities:
Benefits
- Reduced coupling. The gateway encapsulates access to the external resource. Applications that use the resource no longer require information about how to access that external resource.
- Reduced application complexity. Individual applications do not have to implement the communication protocols required to communicate with the external resource. In addition, the gateway can implement some of the error handling that each application would otherwise have to perform.
- Improved integrability. The gateway provides a single point of access for the external resource. This facilitates integration with external resources such as an Enterprise Resource Planning (ERP) system, a Customer Relationship Management (CRM) system, or another similar system.
- Improved security. A single point of access represents a single point of control. You can use this single point of access to implement security policies and to bridge between different security realms. It also allows you to meter access to the external resource and to implement business rules that control access.
- Improved performance through optimization. The gateway provides a logical place to optimize the communication protocol for use with the external resource. Optimization might include batching similar requests or caching results.
Liabilities
- Reduced performance through overhead. The gateway replaces direct communication, adding an intermediate layer. This translates into increased latency compared to direct communication.
- Increased maintainability effort. A gateway extends your integration solution with another component. This translates into additional implementation, configuration, testing, deployment, and management work.
- Dependency of the gateway interface. Designing the gateway requires foresight about the interactions between the applications and the external resource. If you have to change the gateway’s interface in a way that breaks compatibility, you have to change all the applications that access it.
- Reduced availability. All access to the external resource passes through the gateway. From an availability perspective, the gateway represents a single point of failure.
Testing Considerations
Using a gateway improves testability on both sides in the following ways:
- Applications access the external resource solely through the gateway. A mock gateway can receive messages, return predefined responses, and exercise error handling logic. In other words, you can test the system without accessing the external resource.
- Because the external resource receives requests from the gateway, you can test the gateway by relaying requests to the external resource independent of the applications.
Security Considerations
Accessing an external resource through a gateway has the following security implications:
- A single point of access facilitates enforcement of a uniform security policy. However, it also represents a central point of attack.
- A gateway allows bridging between different security realms. For example, a gateway can mix different security context management policies, such as impersonation on one side and consolidation on the other. However, the gateway only provides a place where the mapping between the two can be handled. You must implement the mapping separately.
Operational Considerations
A gateway represents a single point of access and may cause contention among the applications that communicate with the external resource. You should monitor access to the external resource and act proactively when the first signs of contention appear. This single point of access also helps you to meter access to the external resource, to monitor the external resource, and to audit the external resource.
Related Patterns
The Gateway pattern described here relates to the following patterns:
- Implementing Gateway with Host Integration Server 2004 This pattern uses the Global Bank scenario to show how you can use Host Integration Server 2004 to implement Gateway.
- Gateway [Fowler03]. Martin Fowler discusses Gateway in the context of enterprise applications. He also covers the relationship with Façade and Adapter [Gamma95]. Fowler’s Gateway is fine-grained at the object level. However, in the context of integration, Gateway is coarse-grained at the platform level.
- Messaging Gateway [Hohpe04]. Messaging Gateway wraps message-specific method calls, exposes domain-specific methods, and encapsulates access to the messaging system. Hohpe and Woolf also explain how to create composite gateways by using gateway chaining. A composite gateway permits you to use a gateway that encapsulates a single aspect together with other gateways to deal with several aspects.
- Remote Proxy [Buschmann96].Gateway can be regarded as a refinement of the Remote Proxy pattern. Remote Proxy deals with distributed components in the general sense and provides the interprocess communication (IPC) mechanisms for communication with remote objects. Gateway is designed for integration solutions and therefore assumes that the integration infrastructure is available.
- Service Interface [Trowbridge03]. Service Interface exposes functionality as a service and provides an entry point for inbound requests. In effect, the control flows in the opposite direction compared to Gateway.
Resulting Context
The Gateway implementation described here results in the following benefits and liabilities:
Benefits
- Reduced complexity. The gateway encapsulates data and protocol translations required to use the account management system.
- Reduced redevelopment efforts. Business logic that already exists on the mainframe transactions does not have to be redeveloped in the .NET Framework environment.
- Reduced need for retraining. .NET Framework developers do not have to become familiar with CICS or COBOL to use the existing mainframe transactions.
Liabilities
- Increased maintenance effort. Host Integration Server 2004 is an additional system that must be maintained.
- Lack of support for two-phase commit transactions when using .NET Framework client libraries. The .NET Framework client library used in this scenario does not support two-phase commit transactions. Many organizations rely on two-phase commit transactions for day-to-day operations, so this configuration may not suit them. Instead, they would have to use a COM type library that does support two-phase commit transactions.
Tests
To fully test the deployment of TI in this scenario, you must have access to a mainframe computer that is running the proper CICS transactions. However, you can use the TI host-initiated processing capabilities to simulate this access. For instructions on how to configure this simulation, see the Host Integration Server 2004 online documentation at http://www.microsoft.com/biztalk/en/us/host-integration.aspx.
List of Patterns and Pattlets
| Pattern or pattlet |
Problem |
Solution |
Source |
| Entity Aggregation |
How can enterprise data that is redundantly distributed across multiple repositories be effectively maintained by applications? |
Introduce an Entity Aggregation layer that provides a logical representation of the entities at an enterprise level with physical connections that support the access and that update to their respective instances in back-end repositories. |
|
| Process Integration |
How do you coordinate the execution of a long-running business function that spans multiple disparate applications? |
Define a business process model that describes the individual steps that make up the complex business function. Create a separate process manager component that can interpret multiple concurrent instances of this model and that can interact with the existing applications to perform the individual steps of the process. |
|
| Portal Integration |
How can users efficiently perform tasks that require access to information that resides in multiple disparate systems? |
Create a portal application that displays the information that is retrieved from multiple applications in a unified user interface. The user can then perform the required tasks based on the information that appears in this portal. |
|
| Data Integration |
How do you integrate information systems that were not designed to work together? |
Integrate applications at the logical data layer. Use a Shared Database, a File Transfer, or a Maintain Data Copies implementation. |
|
Shared Database
(a kind of data integration) |
How can multiple applications work together to exchange information? |
Have multiple applications store their data in a single database. Define a schema that handles the needs of all the relevant applications. |
Shared Database pattern [Hohpe04]. |
Maintain Data Copies
(a kind of data integration) |
How can multiple applications work together to exchange information? |
Have multiple applications access multiple copies of the same data. Maintain state integrity between copies. |
Maintain Data Copies is the root pattern for twelve patterns (the data movement cluster) that are presented in “Data Patterns” [Teale03]. |
File Transfer
(a kind of data integration) |
How can multiple applications work together to exchange information? |
At regular intervals, make each application produce files that contain the information that the other applications must consume. After a file is created, do not maintain the file. |
File Transfer pattern [Hohpe04]. |
| Functional Integration |
How do you integrate information systems that were not designed to work together? |
Integrate applications at the logical business layer. Use Distributed Object Integration, (proprietary) Message-Oriented Middleware Integration, or Service-Oriented Integration. |
|
| Presentation Integration |
How do you integrate information systems that were not designed to work together? |
Access the application’s functionality through the user interface by simulating a user’s input and by reading data from the screen. |
|
| Message Broker |
How do you integrate applications without enforcing a common interface and also allow each application to initiate interactions with several other applications? |
Extend the integration solution by using Message Broker. A message broker is a physical component that handles the communication between applications. Instead of communicating with each other, applications communicate only with the message broker. An application sends a message to the message broker to give the message broker the logical name of the receivers. The message broker looks up applications that are registered under the logical name and then passes the message to them. |
|
Distributed Object Integration
(a kind of functional integration) |
How do you integrate applications at the logical business layer? |
Develop systems that have object interfaces that can be consumed remotely by other systems. |
Remote Procedure Invocation [Hohpe04]. |
Message-Oriented Middleware Integration
(a kind of functional integration) |
How do you integrate applications at the logical business layer? |
Use proprietary message-oriented middleware to send messages asynchronously. |
Messaging [Hohpe04]. |
| Service-Oriented Integration(a kind of functional integration) |
How do you integrate applications at the logical business layer? |
Use Web services to expose interfaces that can be consumed remotely by other systems. |
|
| Point-to-Point Connection |
How do you ensure that exactly one receiver receives a message? |
Use Point-to-Point Connection to integrate two systems. The sending system must translate the message into a format that the receiving system understands.
When you use point-to-point connections, each system determines the address of all the other nodes that it communicates with. |
|
| Broker |
How can you structure a distributed system so that application developers do not have to concern themselves with the details of remote communication? |
Introduce a broker whose tasks are to locate services, to forward requests, and to return responses to clients. Services register themselves with the broker. Clients access services by making a service request through the broker. |
[Buschmann96]. |
| Direct Broker |
How do you integrate applications without enforcing a common interface, allow each application to initiate interactions with several other applications, and reduce hot spots (performance problems that occur under high loads in specific areas)? |
Extend the integration solution by using a direct broker component that handles the communication between applications. Initially, the application asks the broker to locate the other registered applications based on the logical names of those applications. From this point forward, all communication is made directly between applications. |
|
| Indirect Broker |
How do you integrate applications without enforcing a common interface, but allow each application to initiate interactions with several others? |
Extend the integration solution by using an indirect broker component that handles the communication between applications. Instead of communicating directly, applications communicate only with the message broker. An application sends a message to the broker. This message provides the logical name of the receivers. The broker then looks up applications that are registered under the logical name and passes the message to that application. |
|
| Publish/Subscribe |
How can an application in an integration architecture only send messages to the applications that are interested in receiving the messages without knowing the identities of the receivers? |
Extend the communication infrastructure by creating topics or by dynamically inspecting message content. Enable listening applications to subscribe to specific messages. Create a mechanism that sends messages to all interested subscribers. There are three variations of the Publish/Subscribe pattern that you can use to create a mechanism that sends messages to all interested subscribers. The three variations are List-Based Publish/Subscribe, Broadcast-Based Publish/Subscribe, and Content-Based Publish/Subscribe. |
|
| Message Bus |
As an integration solution grows, how can you lower the cost of adding or removing applications? |
Connect all applications through a logical component known as a message bus. A message bus specializes in transporting messages between applications. A message bus contains three key elements: a set of agreed-upon message schemas; a set of common command messages [Hohpe04], and a shared infrastructure for sending bus messages to recipients. |
|
| Pipes and Filters |
How do you implement a sequence of transformations so that you can combine and reuse them independently? |
Implement the transformations by using a sequence of filter components, where each filter component receives an input message, applies a simple transformation, and sends the transformed message to the next component. Conduct the messages through pipes [McIlroy64] that connect filter outputs and inputs, and that buffer the communication between the filters. |
|
| Gateway |
How can you make the applications of an integration solution access an external system without introducing many-to-one coupling between the applications and the external system? |
Add a Gateway component that abstracts the access to the external resource. The gateway presents a single interface to the integrated applications while hiding the external resource interface. In addition, the gateway encapsulates any protocol translation that may be necessary to communicate with the external resource. |
|
Filed under:
Architecture,
Design,
Patterns,
Reference,
Web,
Web Services Tagged:
.NET,
Analysis,
Architecture,
Automation,
Benefits,
BI,
BizTalk,
BPA,
BPEL,
BPMS,
BRMS,
Business Process,
Design,
HLD,
Internet,
LLD,
Messages,
OO,
OOA,
Process,
Questions,
Risks,
SOA,
Tradeoffs,
Web,
WOA,
WWW 
