Microsoft Mimarisi

4,074 views

Published on

Bu sunumda Microsoft'un mimari konusundaki genel bakış açısı içeriğine erişebilirsiniz. Bu sunum içeriği ingilizcedir.

Published in: Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
4,074
On SlideShare
0
From Embeds
0
Number of Embeds
3,328
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Microsoft Mimarisi

  1. 1. Microsoft’s View of The Application Architecture <br />Mehmet Nuri ÇANKAYA<br />
  2. 2. Goals of Distributed Application Design<br />Designing a distributed application involves making decisions about its logical andphysical architecture and the technologies and infrastructure used to implement itsfunctionality. <br />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).<br />
  3. 3. Goals of Distributed Application Design<br />Your goal is to design an application that:<br /><ul><li>Solves the business problem it is designed to address.
  4. 4. Addresses security considerations from the start, taking into consideration theappropriate authentication mechanisms, authorization logic, and secure communication.
  5. 5. Provides high performance and is optimized for common operations acrossdeployment patterns.
  6. 6. Is available and resilient, and can be deployed in redundant, high-availabilitydata centers.
  7. 7. Scales to meet the expected demands, and supports a large number of activitiesand users with minimal use of resources.
  8. 8. Is manageable, allowing operators to deploy, monitor, and troubleshoot theapplication as appropriate for the scenario.
  9. 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. 10. Works in various application scenarios and deployment patterns.</li></li></ul><li>Services and Service Integration<br />As 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.<br />Service-Oriented Architecture is an approach to organizing information technology in which data, logic, and infrastructure resources are accessed by routing messages between network interfaces<br />Basic value proposition is to provide consistent, stable interfaces in front of diverse or volatile implementations<br />Establish context for information exchange across organizations<br />Encapsulate complexity within organizations<br />Enable context-sensitive information processing<br />
  11. 11. Services<br />Message1<br />Message2<br />Service<br />Logic<br />State<br />Contracts<br />
  12. 12. Service-Oriented Architecture<br />Clients and Agents<br />Process Services<br />Activity Services<br />Infrastructure Services<br />Entity Services<br />
  13. 13. “Web Services” and “SOA”<br />Adopting web services means using one or two in an application<br />Committing to an SOA means<br />Embracing the interchange schema as the canonical representation<br />Using a robust set common infrastructure services to satisfy operational requirements<br />Identifying and acquiring a portfolio of services that support your business use cases<br />
  14. 14. Services  Objects<br />Different deployment model<br />Services are hosted, rather than forward-deployed<br />Encapsulation at the interface, rather than the implementation<br />Opportunity for interception and pipeline processing<br />Opportunity for context- and content-sensitive routing<br />Integration by Design<br />All platforms can consume contracts and messages<br />Opportunity to develop common entity model with marketplace partners<br />
  15. 15. Services and Service Integration<br />Courier Service<br />Credit Card Authorization<br />Service<br />Order Business <br />Logic<br />Order App UI<br />Provide Sale <br />Information<br />Authorize Sale<br />Confirm Autorization<br />Arrange Delivery<br />Confirm Delivery<br />Confirm<br />
  16. 16. Business Perspective<br />The 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: <br />The enterprise's high-level objectives and goals. <br />The business processes carried out by the entire enterprise, or a significant portion of the enterprise. <br />The business functions performed. <br />Major organizational structures. <br />The relationships between these elements. <br />
  17. 17. Application Perspective<br />The application perspective defines the enterprise’s application portfolio and is application-centered. This view will typically include: <br />Descriptions of automated services that support the business processes. <br />Descriptions of the interaction and interdependencies (interfaces) of the organization’s application systems. <br />Plans for developing new applications and revising old applications based on the enterprises objectives, goals, and evolving technology platforms. <br />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.<br />
  18. 18. Information Perspective<br />The information perspective describes what the organization needs to know to run its business processes and operations. It includes: <br />Standard data models. <br />Data management policies. <br />Descriptions of the patterns of information production and consumption in the organization. <br />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. <br />
  19. 19. Technology Perspective<br />The technology perspective lays out the hardware and software supporting the organization. It includes, but is not limited to: <br />Desktop and server hardware. <br />Operating systems. <br />Network connectivity components. <br />Printers. <br />Modems. <br />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. <br />
  20. 20. Application and Technology Architecture<br />The 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."<br />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.<br />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. <br />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<br />
  21. 21. Application and Technology Architecture<br />
  22. 22. Conceptual, Logical, and Physical Views <br />
  23. 23. Conceptual, Logical, and Physical Views <br />
  24. 24. Application Architecture – Conceptual View<br />The conceptual view is used to define the business requirements and the business users' view of the application to generate a business model. Conceptual modeling techniques, such as use case analysis, activity diagrams, process design, and business entity modeling, help to build a description of the key business processes and the data they use, in way that emphasizes business objectives and requirements, and is free of implementation technology.<br />
  25. 25. Application Architecture – Logical View<br />Architects create application models that are logical views of the business model as they determine how to meet business objectives and requirements. The application models represent the logical view of the architecture for an application. <br />Architects here are concerned with the overall structure of the application. They decide on the mapping of data management and process steps, they design the interactions between parts of the model in terms of logical messages and sequences, and they determine what data and state should be held by the model. <br />
  26. 26. Application Architecture – Pysical View<br />Each of the elements in the application model requires mapping to elements of real technologies. In this way application models are realized as implementation models. Part of this task is undertaken during conventional development when programmers write detailed business logic as code, but much of the implementation activities are properly classed as framework completion-a technique for development where much of the infrastructure of distributed applications and data management is handled by sophisticated frameworks that are extended by custom application logic and declarative control structures. Framework completion shields developers from the intricacies of, for instance, asynchronous message handling, and allows developers with modest skills to make effective contributions to the project. <br />
  27. 27. Views of Application Architecture<br />

×