Laravel5.2 blog practical video tutorial resource recommendation

Laravel is a simple and elegant PHP Web development framework (PHP Web Framework). It can free you from messy codes like noodles; it can help you build a perfect network APP, and every line of code can be concise and expressive. Therefore, we have collected "Laravel5.2 Blog Practical Video Tutorial", which is a set of Laravel5.2 practical development tutorials focusing on project actual combat, which is a true introduction to mastery. I hope it can help everyone learn the Laravel framework better.

Course playback address: http://www.php.cn/course/283.html

The teacher’s teaching style:

The lectures are friendly and natural, unpretentious, not pretentious, nor deliberately exaggerated, but talk eloquently and carefully, and the relationship between teachers and students is In an atmosphere of equality, collaboration, and harmony, silent emotional exchanges are carried out, and the desire and exploration of knowledge are integrated into simple and real teaching situations. Students gain knowledge through quiet thinking and silent approval

The more difficult point in this video is HTTP middleware:

-- What is middleware?
1. Why middleware is needed

Computer technology is developing rapidly. From the perspective of hardware technology, the CPU speed is getting higher and higher, and the processing power is getting stronger and stronger; from the perspective of software technology, the scale of application programs is constantly expanding, especially the emergence of the Internet and WWW, which makes the application range of computers wider and many applications The program needs to run on heterogeneous platforms in a network environment. All this puts forward new demands for a new generation of software development. In this distributed heterogeneous environment, there are usually multiple hardware system platforms (such as PCs, workstations, minicomputers, etc.), and a variety of system software (such as different operating systems, databases, etc.) on these hardware platforms. Language compiler, etc.), as well as a variety of user interfaces with different styles. These hardware system platforms may also use different network protocols and network architectures to connect. How to integrate these systems and develop new applications is a very real and difficult problem.

2 What is middleware

In order to solve the problem of distributed heterogeneity, people have proposed the concept of middleware. Middleware is a common service located between the platform (hardware and operating system) and the application, as shown in Figure 1. These services have standard program interfaces and protocols. For different operating systems and hardware platforms, they can have multiple implementations that conform to interface and protocol specifications.

It may be difficult to give a strict definition of middleware, but middleware should have the following characteristics:

Meet the needs of a large number of applications
Run on a variety of hardware and OS platforms
Support Distributed computing, providing transparent application or service interaction across networks, hardware and OS platforms
Supports standard protocols
Supports standard interfaces

Since standard interfaces are important for portability and standard protocols Given the importance of interoperability, middleware has become a major part of many standardization efforts. For application software development, middleware is far more important than operating systems and network services. The program interface provided by middleware defines a relatively stable high-level application environment. No matter how the underlying computer hardware and system software are updated, as long as the middleware is Upgrade and update, and keep the middleware's external interface definition unchanged, the application software requires almost no modification, thus protecting the company's significant investment in application software development and maintenance.

3. Classification of main middleware

Middleware covers a very wide range, and a variety of distinctive middleware products have emerged for different application needs. But so far, there is no more precise definition of middleware. Therefore, the classification of middleware will be different from different perspectives or levels. Since middleware needs to shield heterogeneous operating systems and network protocols in a distributed environment, it must be able to provide communication services in a distributed environment. We call this communication service a platform. Based on different purposes and implementation mechanisms, we divide the platform into the following main categories:

Remote Procedure Call
Message-Oriented Middleware (Message-Oriented Middleware)
Object Request Brokers (Object Request Brokers)

They can provide different forms of communication services upwards, including synchronization, queuing, subscription publishing, broadcast, etc. On top of these basic communication platforms, various frameworks can be built. Provide services in different fields for applications, such as transaction processing monitor, distributed data access, object transaction manager OTM, etc. The platform shields the differences between heterogeneous platforms for upper-layer applications, and the framework on it defines the system structure, standard service components, etc. of applications in the corresponding fields. Users only need to tell the framework the events they are concerned about, and then provide processing for these events. code. When an event occurs, the framework calls the user's code. User code does not need to call the framework, and user programs do not need to care about the framework structure, execution flow, calls to system-level APIs, etc., all of which are completed by the framework. Therefore, applications developed based on middleware have good scalability, easy management, high availability and portability.

The following is a brief introduction to several major types of middleware.

1. Remote procedure call

Remote procedure call is a widely used distributed application processing method. An application uses RPC to "remotely" execute a process that is located in a different address space and has the same effect as executing a local call. In fact, an RPC application is divided into two parts: server and client. The server provides one or more remote procedures; the client makes remote calls to the server. The server and client can be located on the same computer, or on different computers, or even run on different operating systems. They communicate through the network. Corresponding stubs and runtime support provide data conversion and communication services, thereby shielding different operating systems and network protocols. Here RPC communication is synchronous. Threads can be used to make asynchronous calls.

In the RPC model, as long as the client and server have the corresponding RPC interface and have RPC running support, they can complete the corresponding interoperation without being limited to a specific server. Therefore, RPC provides strong support for client/server distributed computing. At the same time, remote procedure call RPC provides process-based service access. The client and server are directly connected, and there is no intermediary agency to process the request, so it also has certain limitations. For example, RPC usually requires some network details to locate the server; when the client makes a request, the server must be active, etc.

2. Message-oriented middleware

MOM refers to the use of efficient and reliable message passing mechanisms for platform-independent data exchange, and the integration of distributed systems based on data communication. By providing a message passing and message queuing model, it extends inter-process communication in a distributed environment and supports multiple communication protocols, languages, applications, hardware and software platforms. Currently popular MOM middleware products include IBM's MQSeries, BEA's MessageQ, etc. Message passing and queuing technology has the following three

main features:

Communication programs can run at different times. Programs do not talk to each other directly on the network, but indirectly put messages into the message queue. , because there is no direct connection between the programs. So they don't have to run at the same time. The target program does not even need to be running when a message is placed on the appropriate queue; even if the target program is running, it is not meant to process the message immediately.

There are no constraints on the structure of application programs. In complex application scenarios, communication programs can not only have a one-to-one relationship, but also one-to-many and many-to-one methods, or even a combination of the above methods. The construction of multiple communication methods does not increase the complexity of the application.

The program is isolated from network complexity

The program puts messages into the message queue or takes messages out of the message queue for communication, and all activities associated with this, such as maintaining the message queue, maintaining The relationship between programs and queues, handling network restarts, and moving messages across the network are the tasks of MOM. Programs do not talk directly to other programs, and they do not involve the complexity of network communication.

3. Object Request Agent

With the development of object technology and distributed computing technology, the two combine to form distributed object computing, which has developed into the mainstream direction of today's software technology. At the end of 1990, the object management group OMG launched the object management structure OMA (Object Management Architecture) for the first time. The object request broker (Object Request Broker) is the core component of this model. Its role is to provide a communication framework to transparently deliver object requests in heterogeneous distributed computing environments. The CORBA specification includes all standard interfaces of ORB. CORBA 1.1, launched in 1991, defined the interface description language OMG IDL and the API that supports Client/Server objects to interoperate on specific ORBs. The CORBA 2.0 specification describes the interoperability between ORBs provided by different vendors.

Object Request Broker (ORB) is an object bus, which is at the core of the CORBA specification. It defines the basic mechanism for objects to transparently send requests and receive responses in heterogeneous environments. It is the establishment of client/server between objects. Relational middleware. ORB allows objects to transparently make requests to other objects or receive responses from other objects, which can be located locally or on remote machines. ORB intercepts request calls and is responsible for finding objects that can implement requests, transmitting parameters, calling corresponding methods, returning results, etc. The client object does not know the mechanism for communicating with the server object, activating or storing the server object, nor does it need to know where the server object is located, what language it is implemented in, what operating system is used, or other system components that are not part of the object interface.

It is worth pointing out that the client and server roles are only used to coordinate the interaction between objects. Depending on the corresponding occasion, the object on the ORB can be a client, a server, or even both. When an object makes a request, it is in the client role; when it receives a request, it is in the server role. Most objects play both client and server roles. In addition, because ORB is responsible for the transmission of object requests and server management, there is no direct connection between client and server. Therefore, compared with the simple Client/Server structure supported by RPC, ORB can support more complex structures.

4. Transaction processing monitoring

Transaction processing monitors first appeared on mainframes, providing them with a reliable operating environment that supports large-scale transaction processing. With the development of distributed computing technology, distributed application systems have put forward demands for large-scale transaction processing, such as a large number of key transaction processing in commercial activities. Transaction processing monitoring is between the client and the server and performs transaction management and coordination, load balancing, failure recovery, etc. to improve the overall performance of the system. It can be thought of as the "operating system" for transaction processing applications. Generally speaking, transaction processing monitoring has the following functions:

Process management, including starting the server process, assigning tasks to it, monitoring its execution and balancing the load.
Transaction management ensures the atomicity, consistency, independence and durability of transaction processing under its supervision.
Communication management provides a variety of communication mechanisms between client and server, including request response, session, queuing, subscription publishing and broadcast, etc.
Transaction processing monitoring can provide services for a large number of clients, such as airplane ticketing systems. If the server allocates the resources it needs to each client, the server will be overwhelmed (as shown in Figure 2). But in fact, not all clients need to request services at the same time, and once a client requests a service, it hopes to get a quick response. Transaction processing monitoring provides a set of services on top of the operating system, manages client requests and allocates corresponding service processes to them, so that the server can efficiently provide services to large-scale customers with limited system resources.

The above is the detailed content of Laravel5.2 blog practical video tutorial resource recommendation. For more information, please follow other related articles on the PHP Chinese website!