"WCF Technology Insider" translation 6:1th Part _ 2nd Chapter _ Service-oriented: overview, quick definition ...

"WCF Technology Insider" translation 6:1th Part _ 2nd Chapter _ Service Oriented: Overview, quick definition Service-oriented, understanding message

Overview

The internet is flooded with service-oriented (so) conversations, and most of the conversations are abstractly described as service-oriented. We'll have a different approach to this chapter. The following chapter pages, we will stand on the demand point of view of service-oriented. More specifically, we'll look at the general message application and what it takes to make them work. Through this process, we will explore several concepts that understand service-oriented needs. The last few paragraphs of this chapter will give a more formal definition of service-oriented, and will discuss why service-oriented in today's world is important for distributed computing.

If you ask 10 service-oriented experts to define service-oriented, you may get 10 different answers. If you ask them again a few years later, you may get another set of different answers. This is not surprising, as object-oriented (OO) and component-driven development become mainstream, many developers are not sure how they should adapt or consider their process design presentation to conform to the new architecture model. Understanding OO and component architectures requires a fundamental shift in the mindset of application systems design. This process is sometimes very painful, but the rewards are really strong design, better code reuse, advanced application functions, easy debugging and short time marketization. My view is that moving from a build-driven design to a service-oriented design, like a transition from process-oriented to object-oriented, requires a fundamental shift in thought. The good news is that the benefit of service-oriented design is the ability to provide richer communication patterns, loosely coupled applications, improved system functionality, and commitment to true application interoperability. Because of the excessive use of interoperability terminology, these instructions are meant to avoid confusion. In this book, interoperability refers to the ability of the system to change the hardware, operating system, or platform without affecting the participants in other distributed scenarios.

Service-oriented, regardless of the confusion now associated with its definition, is not a new concept. It was born in the era of mainframe domination and has recently been accepted in middleware. Recent interoperability initiatives and rich communication patterns have renewed object-oriented interest and are making service-oriented mainstream. It can be imagined that with the wider implementation of service-oriented services, its definition will be increasingly refined.

Quick definition of service-oriented

To put it simply, service-oriented is an architectural style in which distributed application components are loosely coupled through message and contract. Service-oriented applications describe the messages used in their interactions through contracts. These contracts must use a language description and the format can be simply understood by other applications, thus reducing the dependencies that the component implementation brings.

Note that I did not mention the vendor or the technology when describing service-oriented concepts. So this is a concept that transcends the boundaries of vendors and technology, and to a large extent object-oriented also crosses these boundaries. It was very confusing at the time the concept of OO was first formed, and I suspect that service-oriented would have a similar situation. So I'm going to start by using a few examples to illustrate the concept of service-oriented and avoid defining some abstract concepts with other abstract concepts.

Understanding Messages

In service-oriented applications, messages are the basic unit of communication. Therefore, service-oriented applications are often referred to as message application systems. At some point, every service-oriented application will send or receive messages. This can help you understand service-oriented messages much like the letters you receive in your email system. In the mail system, a letter is an abstract entity: It can contain any type of information, can exist in different forms and sizes, and can correlate anything. Similarly, a service-oriented message is an abstract entity: it can contain almost any data, can be encoded in many different ways, and can be associated with virtual things, even other messages. Some of the message's properties have been widely accepted. For example, a letter can be sent by someone, mailed to someone, and may be delivered by someone (more likely in a moment). Similarly, a service-oriented message can be sent by a computer, sent to another computer, and may be delivered by another computer. Considering some nerds who like merely theory, I must clarify that entities that interact with service-oriented messages do not necessarily have to be computers. In theory, they can be homing pigeons, Labrador Retrievers or Lion Tigers. In any case, these entities that interact with service-oriented messages are called participants in the message, and in this book a message participant can be a process on a computer.

"Address": http://www.cnblogs.com/frank_xl/