Architecture of autonomous applications

Content on this page

	What is fiefdom?
	Secure Gateway
	Architecture Model
	Emissary
	Verify based on business rules
	Loose coupling with clients
	XML-based Web Services
	Design XML dataset based on usage
	Use a custom object class
	Map object to database
	The XML dataset is never connected to the database.
	Summary

No one is isolated from each other, especially for developers. Software architects, designers, and developers must communicate with each other to succeed. The same applies. In the past, we considered applications as independent (self-contained) applications. Mainframe applications and small-scale PC applications can all they need. They control user interfaces, business logic, and data, without the need to take into account applications or engage external programs.

But now it is no longer like this. The applications we build today usually need to be integrated with existing software, and this trend continues. In addition, more and more applications no longer control the user interface, for two reasons: first, the user interface is designed elsewhere; second, the user interface accesses the application through the Internet.

Obviously, when building and designing applications, we should consider the need for cross-computing platform integration. Fortunately, we have an architecture solution. Service-Oriented Architecture (SOA) regards applications as services that can be discovered and accessed over the Internet, regardless of the platform on which users run and the programming language they use to create users. In other words, the Service provides services that are not related to the platform and language. Web services are just one example.

What is fiefdom?

Services should be completely autonomous applications. But it is not an isolated island because you can enable it to serve you. However, its autonomy is manifested in its full control of its data and its direct access to the data or its objects is denied. The only way to access its resources is to send a message to it to execute the task for you as a request. If it does not like your request method or does not like you, it will refuse to execute the service. No one makes a decision in the name of it.

Microsoft architect Pat Helland was once the first in autonomous applications, but he is no longer the only person in the field. This is a reasonable concept and we will introduce it to you in this column. Pat uses the term fiefdom to describe autonomous applications, which we will also use here.

Fiefdom stores, manages, monitors, and protects its main resource-data. Fiefdom data can be stored in different types of data sources, but in most cases, structured data is stored in relational databases, such as Microsoft SQL Server. Fiefdom never allows anyone or any tool to directly obtain data from outside fiefdom. Fiefdom may allow some people outside it to access its data or even perform operations in the name of these people, but only the fiefdom can be directly accessed.

Fiefdom does not allow external programs to lock any of its data. Therefore, you must consider making fiefdom a snapshot of all data, rather than the actual content. For most actual purposes, the current data only exists in fiefdom. You cannot expect the data received from fiefdom to be the current data, not to mention the data received at that moment. Fiefdom internal transactions may have changed the data in the data source before you receive the snapshot.

Most fiefdom still insist on managing their own transactions. Fiefdom should not allow external programs to control transactions or part of transactions running in fiefdom. However, fiefdom can expose services to manage part of transactions controlled and coordinated by external parties, as long as these transactions are compensatory transactions. Fiefdom independently controls this transaction, but uses it as the service provided to the client, which is the Transaction Coordinator.

One example of a compensation transaction is compliance with the Web service transaction specification. Part 2: business activities (BA) transactions. Such transactions have two different solutions. The standard scheme executes the operations specified by the transaction. The compensation scheme executes another group of operations to delete the effect of completed transactions in fiefdom. The compensation scheme may be called by another fiefdom Transaction Coordinator. When the compensation scheme is called, fiefdom has completed some of its transactions, but later the Coordinator found that other parts of the transaction failed to be executed. In this case, you must eliminate the impact of some of the transactions that fiefdom runs and completes, even if it cannot be rolled back. The lock applied to the record has been released, and other transactions may have changed its status. The compensation plan will eliminate these impacts.

Not all types of transactions are suitable for compensation. Most fiefdom does not (and should not) participate in transactions that do not have a reliable compensation solution.

Back to Top

Secure Gateway

To some extent, the nature of service-oriented determines that service-oriented applications are secure. The only way for an application to execute any task for you is to send a message to it and request to execute a service. Whether the request is executed or rejected depends on the application.

In many cases, an application allows someone to execute one or more services. In these cases, all web services need to do is to delegate jobs to appropriate components and then pass the responses to the client. In other cases, the Web service may need to verify the user's identity to determine whether the user is authorized to execute the service. This can be a simple check on the Active Directory or SQL database at the gateway, or security technology (such as simulation or delegation) can be used at different levels of the application) and role-based security checks. Remember to always pay attention to the risks caused by denial of service attacks, hackers attempting to intrude into the system, and other malicious threats.

As part of the security plan, Microsoft has released several security-oriented documents, the most important of which is "building secure ASP.. NET applications. It has been published as a book (Microsoft Press, 2003 ). You can download this document (building secure ASP. net Applications: authentication, authorization, and secure communication) You can also purchase books that contain a large amount of information about how to build deep security for Web-based applications.

Back to Top

Architecture Model

Obviously, fiefdom is an architecture model. Like other models, as a software architect, you should be able to say "I think we should design this application into a fiefdom ", at the same time, people around you should be able to understand what you are talking about immediately. This is one of the strong advantages of patterns; they help you discuss architecture, design at a more abstract level, and use general words for design.

Obviously, not all fiefdom should be structured in the same way. A group of services they provide will affect the types of components they need internally, so any fiefdom will use other modes for Architecture in its internal implementation. For example, most fiefdom uses a mode (such as using a data accessor) to access the database, use a service proxy to access other services, and use a data transmission object to transmit data through each layer, and use the Entity Manager to support entity-level business rules.

Back to Top

Emissary

Some fiefdom also provides a user interface (UI) for its services ). Fiefdom uses an emissary mode-a web form Emissary or a Windows form emissary. Emissary is like a sales agent or a mortgage broker. It can display reference data to users, allowing users to select from valid options, rather than typing information. Emissary also knows many business rules used by fiefdom, so it can help users make requests in a way that is more acceptable to fiefdom.

Emissary can also save the session status for users. A typical example is ASP. net web form, which saves the shopping cart for the user during multiple calls, allows the user to add products to the existing items in the shopping cart, these items are stored in the shopping cart until the purchase process is complete.

However, fiefdom does not trust emissary, even when emissary must be viewed as part of fiefdom. All requests passed through emissary must evaluate their security, integrity, and correctness, just as evaluating requests that are not assisted by emissary at the time of input. This is exactly how insurance companies handle the insurance applications introduced by sales agents. Emissary is used for the interests of clients rather than fiefdom.

In this way, how should we allocate work between fiefdom and Its emissary? In this case, fiefdom must process shared data, which means that write operations must be serialized to protect data integrity. Instead, Emissary can process local read-only copies of reference data and each user's data. Therefore, Emissary can ignore synchronization issues. In the demilitarized zone, Emissary usually processes only one client at a time, while fiefdom usually resides in a protected Intranet and must always be available to all clients.

With web forms, Emissary can actually be expanded. It is quite difficult to expand fiefdom because it processes shared data, and shared data must always be available to all clients.

Therefore, if more work can be assigned to emissary to reduce the fiefdom load, the scalability of the application will be significantly improved. You can achieve this through careful design. Let's take a look at Amazon.com. When you browse their sites and put books and other items into your cart, all work can be done by emissary. You only need to use fiefdom when you click "Submit" for settlement.

To do this, you must carefully design the system: draw the boundaries between fiefdom and emissary, and use performance and extensifier (such as cache objects ). In addition, you must minimize the interaction between emissary and fiefdom by designing the fiefdom service interface.

Back to Top

Verify based on business rules

Some requests sent to fiefdom require data storage or deletion. If the request itself is not carefully verified based on the security policy and its data is not verified according to the business rules, fiefdom should not accept such requests. This is why business rules and policy rules belong to fiefdom (defined by Pat Helland) and are located in services (defined by SOA.

Back to Top

Loose coupling with clients

Fiefdom is loosely coupled with its client. Before a client sends a message to fiefdom to establish a connection, there is no connection between the client and fiefdom. Fiefdom processes the message and sends a response to the client. A response can be the result of a request or a denial of service execution. In any case, as long as the fiefdom response is complete, the connection between the client and fiefdom is disconnected, just like HTTP message exchange. Like HTTP, there are multiple ways to maintain connections throughout the session, but it is usually limited to only one complete message cycle.

Loose coupling is good for scalability. It allows any client to connect to the system and use system resources for the least time. The Design of loose coupling and one-time management of Microsoft Transaction Processing Service (MTS) is the same as that of the so-called. NET Enterprise Services incorporated into COM + component services.

Back to Top

XML-based Web Services

One concept behind SOA is location transparency, and the other is unrelated to the computing platform and programming language. Web services are ideal for satisfying these basic concepts. Because the Web Service is known as its url, its actual location can be changed (as long as the service provider still points to this location ).

Because the Web Service has nothing to do with the underlying platform and programming language, it only requires the client to understand soap, XML and the transport protocol used. The transmission protocol is usually HTTP, but it can also be SMTP or any standard Internet transmission protocol.

Some people think that any fiefdom written in the Microsoft. Net target language should disclose its data and functions through Web Services. It does not need to expose these web services to the outside world; their only direct client type can be emissary, which is well known by fiefdom.

Fiefdom should be built on the concept of loose coupling between fiefdom and its client. Fiefdom should use stateless service components, rather than a set of State objects. The form of data transmission and operation should be the same as the form in which it receives data and transmits it to the client, that is, the XML Stream form. Microsoft. NET Framework helps with this because it provides a complete XML-based API to transmit data through fiefdom and publish data to the client.

These APIs are composed of XML datasets of ADO. net. The data access function of ADO. Net can easily extract data from any number of database tables and fill XML data sets with data. You can easily transfer content such as datasets between multiple components to users, or even cross-process and machine boundaries. In addition, because data contained in a dataset can be considered as easy-to-use XML documents, it is very convenient to use it for XML Web Service response. Finally, even if the dataset contains XML, you do not need to use the XML syntax to access or operate the data. To access attributes, you can use common object-oriented syntax, such as trainerdata. Trainers (3). lastname.

Sometimes we hear some arguments about the use of XML data sets to represent business entities: "We don't want to disclose the database structure to the client ." In fact, in most cases, it is unwise to make the database structure affect the structure of the XML dataset. The structure of the dataset should be specified if it is used independently. You can easily define the structure of a dataset without any connection to the database structure. It is very likely that you define all the datasets of the application before designing the database.

Back to Top

Design XML dataset based on usage

As an example, you should consider the "view the coming Schedule" Use Case of the competition application. We have created this application in the previous books and articles. The purpose of this case is to display the list of upcoming schedules. Data must contain dates, tracks, cities, and countries.

Figure 1XML Dataset

After knowing the data required for this case, we can design an XML dataset for it. Figure 1 shows the ideal design for this type of dataset. We can see that the dataset only contains one table. The racedaytable table contains all the data required by the use case. In addition to the racedayid column, each column in the table has a corresponding column displayed to the client, as shown in 2. (The racedayid column in this data table is used to allow users to select a match date to be displayed, and then display the detailed match information for the day on another page .)

Figure 2Competition details

Let's take a look at where the data comes from. 3 (it shows a part of the database model of the Application). To create one and only one dataset table required for the use case, you must access four database tables.

Figure 3Four database tables

If you are interested, let's look at a stored procedure that can move data from four database tables to one dataset table. It uses an SQL SELECT statement and only performs round-trip interaction with the database, as shown in the following code:

CREATE PROCEDURE GetFutureRacedays AS    SELECT RacingProgramId As RaceDayId, Date, TrackName As               RaceTrackName, CityName, CountryName    FROM RacingPrograms As RP    JOIN RaceTracks As RT ON (RP.RaceTrackId = RT.RaceTrackId)    JOIN Cities As Ci ON (RT.CityId = Ci.CityId)    JOIN Countries As Co ON (Ci.CountryCode = Co.CountryCode)    WHERE Date > GetDate()    ORDER BY RacingProgramId

From this example, we can see that the structure of the dataset is completely different from that of the database. This is because the dataset is designed according to the needs of a single case, while the database is designed using formal rules, which helps prevent exceptions when using data.

Back to Top

Use a custom object class

Let's take a look at how to design objects if developers do not want to disclose the database structure to the client. They can choose to design stateful objects that represent the so-called "Domain Model" according to a common design pattern. Of course, the domain model represents objects in the real domain. In our competition application, domain models can include categories such as horses, trainers, horse cyclists, and competitions.

In addition, the actual data source of the domain data can also be a database. This is where most structured data is stored. Obviously, the database model is similar to the domain, so it is a domain model.

This is why the entity class set that consists mainly of custom object classes in an application is so consistent with the table set that represents the same domain in the database. This is why many developers underestimate the value of the actual data model opposite to the class model.

Ideally, the consistency between the domain-like model and the relevant domain model should not be so close; databases should be properly standardized. Standardizing entity classes in memory in the same way usually generates a large amount of code that is not actually needed. This also increases Code complexity and slows down operations.

Back to Top

Map object to database

Why do entity classes in the memory tend to be standardized as database tables? This is mainly because it is often used to map objects in memory and related table policies to each other. Since few exceptions occur, it is recommended that the authors who use the memory-Based Domain Model perform an approximate one-to-one ing between memory-based classes and database tables.

Figure 4 provides a simplified instance of the client's problems in this case. Except for keys and collection classes, they are almost copies of database tables. It is self-evident that it uses multiple SQL select statements to fill these four entity objects. Obviously, it takes more time to perform four round-trip interactions with the database than one round-trip. The advantage is that the client is less dependent on the database.

Figure 4Ing result

It should be clear that exposing an XML dataset to a client application is not equivalent to making the client dependent on the database. In fact, the opposite is true! However, you must understand XML datasets to make full use of them. When defining their XSD scheme, you should focus on their use; there is no need to consider the structure of the database.

This is particularly important in service-oriented applications. A service-oriented application publicly returns a programming interface for an XML Stream or XML document to the client. At least for service-oriented applications that expose Web Services. The structure of XML documents is controlled by its XSD scheme, and the same is true for XML datasets (they are actually XML documents ).

Back to Top

The XML dataset is never connected to the database.

Some developers may not know that the XML dataset is never connected to the database. It cannot connect to the database. To move data between an XML dataset and a database, a certain type of proxy is required to map the dataset table to a relational table. ADO. NET provides such objects, which have different characteristics for different database products. It is called a data adapter and is only used to move data between a dataset and a data source. The dataset itself does not know any information about the database and the content of SQL statements that fill the dataset with data or move the data to the data source.

Why is this so confusing? Why do so many people believe that using datasets means relying on databases? The reason may be that an XML dataset is used as a substitute for an old record set for traditional ado, Remote Data Object (rdo), and data access object (DAO. In all these models, record sets are directly connected to data sources (such as relational databases ). The only exception is the ADO record set, which can disconnect from the database and then connect again.

The XML dataset is completely different from the old record set. They aim to retain and transmit data snapshots, which are completely independent of any database from which data may be extracted and ignored.

Back to Top

Summary

Next time we will start to introduce a software development project and consider its architecture as fiefdom. If your application wants to expose the user interface (as most applications do), you should consider its architecture as a set of emissary. Emissary should try to do his work without fiefdom unless it is a last resort. For example, they should cache reference data and keep the session state without using fiefdom. Applications built in this way are more scalable than applications that use server resources (such as shared data) to the maximum extent.

This policy helps you design fiefdom to use stateless components. This is very useful for improving scalability and simplicity. However, you should use stateful components only when you have. In most applications, you should consider using the ADO. Net XML dataset as a data transmitter. The database can be used perfectly with the data adapter. They work transparently across processes and machine boundaries and are fully XML-based. They are designed for data binding, which is in many cases the preferred way to display data to users in web forms or Windows Forms.

If you want to learn more about Pat Helland's fiefdom and emissary architecture patterns, listen to architecture network broadcast: autonomous computing: fiefdoms and emissaries.

Send your questions and comments about the design patternMmpatt@microsoft.com.

Sten sundbglad and per sundbgladJointly launch sundbglad & sundbglad ADB-arkitektur in Sweden. The company's main business goal is. NET development, specifically the architecture and design. They wroteDesigning for scalability with Microsoft Windows DNA(Microsoft Press, 2000) andDesign Patterns for scalable MicrosoftNet Applications(Sundbglad & sundbglad, 2002 ). For more information about Sten and per, visit the http://www.2xSundblad.com. You can useStens@2xSundblad.comAndPers@2xSundblad.comContact them.

Go to the original English page