Patent Application
20120159424
Distributed computing applications are often constructed to include a collection of different technologies and services that form building blocks of the applications. Examples of distributed applications are legion and can include enterprise applications such as line of business or LOB, billing systems, customer relationship management or CRM, enterprise resource planning or ERP, business intelligence, human resource management, manufacturing, and inventory control applications. Distributed applications are typically distributed across tiers in a computer network and can include composites of components built using disparate technologies, which can include both familiar and emerging technologies. Some applications run in a cloud computing environment, others run on the premises of the entity or user, and others span these environments. Further, the environment may change as an application evolves.
One desirable characteristic of a distributed application is its ability to scale, or cost effectively change with the enterprise. Existing application models do not aim to support the development of scalable distributed applications. Typical component models are designed for desktop applications and are tier and technology specific. A distributed application is typically comprised of a set of distinct components, spread across tiers, which interact to perform work. While the components are virtualized, the relationship between the components is not. A physical wiring of components during runtime interaction is typically statically determined or otherwise hard-coded in this framework, which can place limits on the ways in which the application can be scaled or even on the application's overall ability to scale. While working with such models, many developers try to avoid writing stateful components because they are difficult to scale, but in making this choice the developer sacrifices benefits of other approaches, such as the natural expression of application logic.
This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.
The present disclosure is directed to an application manifest of a distributed application constructed according to an application model in an application framework. The application model includes an application being constructed from one or more modules each including one or more components. The manifest describes components and composites of components of the distributed application in a technology agnostic manner and defines the scalability of the composites of components. In some examples, the manifest includes the metadata of each component, and each component can define its own metadata that becomes part of the distributed application. The manifest further defines external services and defines applications consumed by the distributed application and artifacts. Cross cutting concerns for the distributed application such as metering, throttling, billing can also be described.
The accompanying drawings are included to provide a further understanding of embodiments and are incorporated in and constitute a part of this specification. The drawings illustrate embodiments and together with the description serve to explain principles of embodiments. Other embodiments and many of the intended advantages of embodiments will be readily appreciated as they become better understood by reference to the following detailed description. The elements of the drawings are not necessarily to scale relative to each other. Like reference numerals designate corresponding similar parts.
In the following Detailed Description, reference is made to the accompanying drawings, which form a part hereof, and in which is shown by way of illustration specific embodiments in which the invention may be practiced. It is to be understood that other embodiments may be utilized and structural or logical changes may be made without departing from the scope of the present invention. The following detailed description, therefore, is not to be taken in a limiting sense, and the scope of the present invention is defined by the appended claims. It is to be understood that features of the various exemplary embodiments described herein may be combined with each other, unless specifically noted otherwise.
The exemplary computer system includes a computing device, such as computing device 100. In a basic configuration, computing device 100 typically includes a processor system having one or more processing units, i.e., processors 102, and memory 104. Depending on the configuration and type of computing device, memory 104 may be volatile (such as random access memory (RAM)), non-volatile (such as read only memory (ROM), flash memory, etc.), or some combination of the two. This basic configuration is illustrated in
Computing device 100 can also have additional features or functionality. For example, computing device 100 may also include additional storage (removable and/or non-removable) including, but not limited to, magnetic or optical disks or solid state memory, or flash storage devices such as removable storage 108 and non-removable storage 110. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any suitable method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Memory 104, removable storage 108 and non-removable storage 110 are all examples of computer storage media. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile discs (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, universal serial bus (USB) flash drive, flash memory card, or other flash storage devices, or any other medium that can be used to store the desired information and that can be accessed by computing device 100. Any such computer storage media may be part of computing device 100.
Computing device 100 includes one or more communication connections 114 that allow computing device 100 to communicate with other computers/applications 115. An example communication connection can be an Ethernet interface. In some examples, the computing device can also have one or more additional processors or specialized processors (not shown) to perform processing functions offloaded from the processor 102. Computing device 100 may also include input device(s) 112, such as keyboard, pointing device (e.g., mouse), pen, voice input device, touch input device, etc. Computing device 100 may also include output device(s) 111, such as a display, speakers, printer, or the like.
The computing device 100 can be configured to run an operating system software program and one or more software applications, which make up a system platform. In one example, the computing device 100 includes a software component referred to as a managed, or runtime, environment. The managed environment can be included as part of the operating system or can be included later as a software download. Typically, the managed environment includes pre-coded solutions to common programming problems to aid software developers to create applications, such as software programs, to run in the managed environment.
A component, such as component 206a, is a unit of technology encapsulation, extensibility, and composition. The component 206a encapsulates a certain technology. Technologies can include, for example, a web application technologies or application programming interfaces for building connected, service-oriented applications. More than one component type can be developed for a given technology. For example, the application 202 could include a web application component and a service component in the web tier, a code component, a cache component, and a workflow component in the worker tier, and various storage components (such as tables or queues) an SQL database component in the storage tier. The component 206a can include artifacts and define the metadata at runtime.
Imports and exports are the mechanism by which the components 206a-206n are stitched together to form the application 202. This stitching may be described at the design stage or can be dynamic in that available exports can be discovered, imported, and used at runtime. In either case, the stitching is a logical expression of a component relationship; the procurement of proxies and the resolution of physical addresses to get two component instances communicating is brokered at runtime.
In the schema 200, one or more components can be organized as a module 204a-204n. A module is a tier-specific unit of hosting for a logical grouping of components that share execution characteristics. Components grouped together within a module can run within the same application domain. For example, two or more components 206a-206n can be co-located if they abide by the same partitioning scheme. In a partitioned module, each part is independent of the others and hence receives its own application domain (within which the set of co-partitioned components constituting that part will run). The components 206a-206n within a module, such as module 204a, can communicate via direct method invocations. Across modules 204a-204n, components communicate by sending messages. A module type can correspond to the capability of the host. For example, a stateless component, such as a web role, can be hosted in a stateless module. Execution environments for modules include web and worker roles for stateless components and a fabric role for stateful components.
In one example of an application model, the scalable application 202 can include the techniques of cloning, replication, and partitioning. Different techniques may apply to different parts of the application 202, which may change over time as the application grows. For example, cloning is a relatively straightforward technique, but it is exclusively suited for stateless components. Replication is an effective technique for stateful components, but it can be complex and limited. For example, the amount of state can grow during the life of the application 202 such as in the form of user sessions or cached data that are replicated across machines, or a row-locking scheme in a shared store that becomes the bottleneck to the performance of the application 202. In order to address the issue of growing state, a developer may choose to partition the component 206a, which at times can involve a costly and difficult re-architecture of the application 202.
In order to avoid a costly re-architecture, the application 202 is initially designed in a distributed application framework to support partitioning. Design patterns and use of a distributed composition runtime can make intra-component wiring immune to otherwise invasive changes such as sharding, or horizontal partitioning of a database, and component partitioning. Partitioning is made available in the application 202 and activated at as desired. The application 202 can be readily designed to map the partitions to machines as well. Additionally, the developer can retain flexibility about whether a component 206a or the entire application 202 runs on premise or in a cloud computing environment. As the costs of infrastructure change over time, the architecture of the application 202 can naturally evolve to take advantage of the relative cost changes.
Architects, developers, and information technology personnel can all benefit from using a single, consistent application model that is used to describe the application 202. The application model can span tiers and technologies, embrace both stateless and stateful components, and offer an ability to readily control partitioning and cloning throughout the lifetime of the application 202. At runtime, the distributed application framework provides the connections between the components 206a-206n of the application 202, described logically in the model of the application.
The distributed application framework provides developers and enterprises the ability to cost-effectively build, run, and evolve the distributed application 202. Both stateful and stateless components can be developed using familiar technologies, emerging technologies, and custom paradigms for specific domains. The components 206a-206n can be stitched together either statically or dynamically to form the application 202. Cloning, replication, and partitioning are supported within the application 202, as is the ability to make architectural tradeoffs such as among consistency, availability, and tolerance of “partitions” (such as describe in Brewster's CAP Conjecture).
During runtime, the distributed application framework can monitor the application 202 to diagnose and repair issues as well as meter the use of the components 206a-206n. The distributed application framework can elastically allocate and reclaim resources to support a fluctuating demand. Further, the distributed application framework provides for the ability to later partition the application 202, co-locate partitioned components 206a-206n, change a mapping of partitions to a physical infrastructure, as well a shard a database without costly re-architecture.
In one example, an application fabric available under the trade designation of AppFabric can run on premise, such as a server operating system available under the trade designation of Windows Server, and in a cloud environment having a cloud computing or cloud services operating system available under the trade designation Windows Azure, all available from Microsoft, Inc., allowing entire applications (or components within them) to be deployed to either environment. Web roles, workflow, and the like can be built using Windows Communication Foundation (WCF) and Windows Work Flow (WF) available from Microsoft, Inc.
A distributed application manifest provides a description, or definition, of the components 206a-206n, the composites of components, and their relationship to each other within the distributed application 202 in a technology and format agnostic manner. The manifest is a serialized form of the distributed application 202 and captures the entire structure of the application.
The manifest 300 can be used to create a visualization of the distributed application in a development tool such as an integrated development environment available under the trade designation of Visual Studio from Microsoft, Inc., of Redmond, Wash. The deployment infrastructure can make use of the manifest 300 to determine how to configure a node in a host farm and which components to co-locate. Additionally, a management experience can allow configuration of component metadata and scale properties prior to and after deployment of the distributed application.
In one example, the manifest is format agnostic and can be serialized in a variety of formats, which can include scripting languages such as extensible markup language (XML), extensible application markup language (XAML), JavaScript object notation (JSON), or binary JSON (BSON) and many others now know or yet to be created. The following example distributed application manifest is serialized in JSON:
The manifest 300 includes a module definition and information on instances, partitions, and replicas. For example, a stateless module definition can include an instance count that control the number of module instances and describes the scalability and high availability (HA) characteristics of a stateless module. A stateful module definition can include an instance count, a partition policy, and a replica count. Again, the instance count controls the number of module instances and thus the scalability. The partition policy defines the number of partitions assigned to a given module instance. The replica count controls the HA and determines the number of replicas of each partition. For example, a stateless module definition can specify three stateless module instances. A stateful module definition can define three stateful module instances, where each stateful module can have four partitions, and each partition can have two replicas.
Although specific embodiments have been illustrated and described herein, it will be appreciated by those of ordinary skill in the art that a variety of alternate and/or equivalent implementations may be substituted for the specific embodiments shown and described without departing from the scope of the present invention. This application is intended to cover any adaptations or variations of the specific embodiments discussed herein. Therefore, it is intended that this invention be limited only by the claims and the equivalents thereof.
