The document discusses the goals and frameworks for designing distributed applications, emphasizing the need for a clear understanding of both functional and operational requirements. It outlines the perspectives necessary for application architecture, including business, application, information, and technology views, along with service-oriented architecture principles. Additionally, it covers the conceptual, logical, and physical aspects of application architecture to ensure efficient development and integration of business processes.

1. Microsoft’s View of The Application Architecture Mehmet Nuri ÇANKAYA

2. Goals of Distributed Application DesignDesigning a distributed application involves making decisions about its logical andphysical architecture and the technologies and infrastructure used to implement itsfunctionality. To make these decisions effectively, you must have a sound understandingof the business processes that the application will perform (its functionalrequirements), and the levels of scalability, availability, security, and maintainabilityrequired (its nonfunctional, or operational, requirements).

3. Goals of Distributed Application DesignYour goal is to design an application that:Solves the business problem it is designed to address.

4. Addresses security considerations from the start, taking into consideration theappropriate authentication mechanisms, authorization logic, and secure communication.

5. Provides high performance and is optimized for common operations acrossdeployment patterns.

6. Is available and resilient, and can be deployed in redundant, high-availabilitydata centers.

7. Scales to meet the expected demands, and supports a large number of activitiesand users with minimal use of resources.

8. Is manageable, allowing operators to deploy, monitor, and troubleshoot theapplication as appropriate for the scenario.

9. Is maintainable. Each piece of functionality should have a predictable locationand design taking into account diverse application sizes, teams with varyingskill sets, and changing business and technical requirements.

10. Works in various application scenarios and deployment patterns.Services and Service IntegrationAs the Internet and its related technologies grow, and organizations seek tointegrate their systems across departmental and organizational boundaries, aservices-based approach to building solutions has evolved.Service-Oriented Architecture is an approach to organizing information technology in which data, logic, and infrastructure resources are accessed by routing messages between network interfacesBasic value proposition is to provide consistent, stable interfaces in front of diverse or volatile implementationsEstablish context for information exchange across organizationsEncapsulate complexity within organizationsEnable context-sensitive information processing

11. ServicesMessage1Message2ServiceLogicStateContracts

12. Service-Oriented ArchitectureClients and AgentsProcess ServicesActivity ServicesInfrastructure ServicesEntity Services

13. “Web Services” and “SOA”Adopting web services means using one or two in an applicationCommitting to an SOA meansEmbracing the interchange schema as the canonical representationUsing a robust set common infrastructure services to satisfy operational requirementsIdentifying and acquiring a portfolio of services that support your business use cases

14. Services  ObjectsDifferent deployment modelServices are hosted, rather than forward-deployedEncapsulation at the interface, rather than the implementationOpportunity for interception and pipeline processingOpportunity for context- and content-sensitive routingIntegration by DesignAll platforms can consume contracts and messagesOpportunity to develop common entity model with marketplace partners

15. Services and Service IntegrationCourier ServiceCredit Card AuthorizationServiceOrder Business LogicOrder App UIProvide Sale InformationAuthorize SaleConfirm AutorizationArrange DeliveryConfirm DeliveryConfirm

16. Business PerspectiveThe business perspective describes how a business works. It includes broad business strategies along with plans for moving the organization from its current state to an envisaged future state. It will typically include the following: The enterprise's high-level objectives and goals. The business processes carried out by the entire enterprise, or a significant portion of the enterprise. The business functions performed. Major organizational structures. The relationships between these elements.

17. Application PerspectiveThe application perspective defines the enterprise’s application portfolio and is application-centered. This view will typically include: Descriptions of automated services that support the business processes. Descriptions of the interaction and interdependencies (interfaces) of the organization’s application systems. Plans for developing new applications and revising old applications based on the enterprises objectives, goals, and evolving technology platforms. The application perspective may represent cross-organization services, information, and functionality, linking users of different skills and job functions in order to achieve common business objectives.

18. Information PerspectiveThe information perspective describes what the organization needs to know to run its business processes and operations. It includes: Standard data models. Data management policies. Descriptions of the patterns of information production and consumption in the organization. The information perspective also describes how data is bound into the work flow, including structured data stores such as databases, and unstructured data stores such as documents, spreadsheets, and presentations that exist throughout the organization.

19. Technology PerspectiveThe technology perspective lays out the hardware and software supporting the organization. It includes, but is not limited to: Desktop and server hardware. Operating systems. Network connectivity components. Printers. Modems. The technology perspective provides a logical, vendor-independent description of infrastructure and system components that are necessary to support the application and information perspectives. It defines the set of technology standards and services needed to execute the business mission.

20. Application and Technology ArchitectureThe functional requirements of a software system describe the business value that the software delivers. For a weather service, a functional requirement might be stated as "given a well-formed message A as input, the service will return a message B correct for the time span and geographic location represented in message A."An application architecture is the architecture of any automated services that support and implement such functional requirements, including the interfaces to the business and other applications. It describes the structure of an application and how that structure implements the functional requirements of the organization. Whilst there should ideally be one application architecture in an organization, in practice there are typically many different application architectures.The operational requirements of a software system define the reliability, manageability, performance, security, and interoperability requirements of the software (to list just a few). Common examples might be that the service is only available to authorized subscribers, and that the service be functioning properly 99.999 percent of the time. A technology architecture is the architecture of the hardware and software infrastructure that supports the organization and implements the operational (or non functional) requirements, particularly the application and information architectures of the organization. It describes the structure and inter-relationships of the technologies used, and how those technologies support the operational requirements of the organization

21. Application and Technology Architecture

22. Conceptual, Logical, and Physical Views