Service orientation : 無料・フリー素材/写真
Service orientation / dgray_xplane
| ライセンス | クリエイティブ・コモンズ 表示-改変禁止 2.1 |
|---|---|
| 説明 | Early computer programs were written as sets of instructions, like recipes: First do this, then that, if the user does this, then do this; otherwise, do that, and so on. This worked just fine for simple programs. But software tends to get more complex over time. When programs reached about a million lines of code, they hit a complexity ceiling and started to break. And as software and systems were connected with other systems, the number of dependencies and interconnections increased to the point where the tangled web of interdependent functions was impossible to modify or adjust in one place without breaking something somewhere else.In the 1960s, computer researchers started to code modular, reusable building blocks instead of procedural instructions. Computer pioneer Alan Kay named the approach, calling it object-oriented programming:“I thought of objects being like biological cells… only able to communicate with messages,” he later explained.Object orientation allowed programmers to design software as a system of interacting objects instead of a list of instructions. They could modify a single object without worrying about complex interdependencies. Each object could be seen as an independent machine with its own roles and responsibilities within a larger system.Object-oriented programming was primarily used inside large enterprises, and not so much for interactions between companies. But the advent of the internet added another layer of challenge and complexity – as well as opportunity. Suddenly it was feasible for software to exchange information not only within the business, but between a business and its partners, suppliers and customers.The next phase in programming’s evolution, service orientation, emerged to solve this problem. It delivered a way for software objects to interconnect with each other over the internet, at a massive scale.Software services are very similar to software objects. They are modular functional units that can operate independently and interact with other services using an agreed-upon set of common standards. The big move forward comes from the way that they interact with the larger world. In service orientation, technologists have now agreed to a set of standards that allow any service to interact with any other service, over the web, regardless of the service’s underlying technology.Services can be made available over the web or any other network. They can be made available to the general public, or to a defined set of authorized users. The power of a service-oriented architecture is that each service can learn, adapt and coevolve without wreaking havoc on the overall system, just like species coevolve in a biological community.Three principles for the core of service-oriented design: service contracts, composability, and loose coupling.Service contracts:A service contract is a simple description of the service, including what the service provider needs from customers, what it will do for them, and any rules about how the service provider and customer will interact. Like any business contract, it represents an agreement.Business examples abound. The contract doesn’t need to be specified in writing as long as both parties understand the agreement. For example the service contract of a fast-food restaurant is different than a sit-down restaurant. The agreement is that customers will stand in line and order by number in exchange for faster service. If you sit down at a table in a fast-food restaurant and wait for a server to come and take your order, you will be waiting a long time. The reason fast-food works is that providers and customers both understand the promise of the service and agree to work together in a certain way.A service contract specifies what the provider will do, but it doesn’t specify how the work will be done.The advantage of this is that a service can hide its internal complexity, and even change the way it operates, as long as it continues to keep the promise of its contract. This is important because it allows the service to independently evolve and improve its operations without affecting customers or other services. A service can be as complex as it likes internally, so long as it provides a simple contract describing what it does and how it will interact with its customers.Most services have some kind of complexity that is invisible to customers. For example the kitchen and dishwashers in a restaurant are not usually visible to diners, and most stores have areas such as storerooms and shipping/receiving docks that are not obvious to customers. The iOS operating system that powers iPhones and iPads hides a lot of internal complexity. There are no files or folders. There are only apps that you access to do things. Amazon customers don’t have to know anything about Amazon’s warehouses or distribution systems. They just order on the website and sign for the package when it arrives.The reason to hide complexity is that it makes a service easier to understand and use. Since customers see only the things they can act on, make decisions about or buy, they can make better, faster choices.Composability:Most services are combinations of other services. For example, any kind of food service, from a vending machine to a five-star restaurant, must provide a few core services: it must be able to take orders. It must be able to take payments. It must be able to store and deliver it to customers. Every food service must make decisions about how it will do each of these things, and how it will combine these services with other services to deliver value to customers. Common standards make services more useful by making them connectable and composable, so they can be easily combined into larger services.For example, consider a restaurant with a bar and a kitchen. When they use a common ordering system they can work together more effectively. Wait staff can easily access both the bar and kitchen services, and the total charge can show up on one bill. This means the larger service works better, and it’s more convenient for the customer. At the same time, the bar and kitchen services are separate in the sense that they are not dependent on each other – they can exchange information, but each can also operate independently of the other. If the bar shuts down people can still order food, and vice versa.Loose coupling:Loose coupling simply means that services agree to use a set of common set of rules about how to connect. So as long as a service follows the rules, it can update, change or modify itself without having to worry about the impact on other services in the system.Web pages, for example, are loosely coupled, because one web page can link to another without knowing anything about the other page, beyond its address and the rules for connection, which in this case is HTTP, the protocol common to all web pages.The opposite of loose coupling is tight coupling, where elements on both sides must be designed to complement and fit one another. For example, most mobile phone companies have a unique interface for attaching the charger to the phone. There’s really no benefit to customers in this. The primary reason is so they can sell more chargers. This is why you have a drawer full of perfectly-good chargers that are useless to you or anyone else. But there can be good reasons for tight coupling. Things that are designed to work closely together can deliver better performance, more efficiently. For example, most of the components of your car are tightly coupled, because each part is designed to fit smoothly and integrate with every other part. You can’t take a door, or an engine, out of a Honda and attach it to a Ford, at least, not easily.But your car is loosely coupled with many other elements in the road-and-car system, and for good reason. For example, when you pull into a gas station to fill up your tank, you don’t have to worry about whether the pump nozzle will fit, because there is a standard for that. If you need to put air in your tires, you don’t have to worry about whether the air hose will fit your tires, because there is a standard for that. Cars are tightly coupled internally but loosely coupled with the overall system that they operate in.Service-oriented architecture works in the same way. Internally, a service can be as complex as it wants to be, just like your car. But when it needs to interoperate with the larger system, it follows a common set of rules.Standards can be proprietary and closed, such as Apple’s iOS, Microsoft Windows, and Facebook’s application development platform, which are provided and managed by a single company; or they can be open, like HTTP and TCP/IP, which govern web interactions, and the electrical sockets in your home. Open standards are defined and managed by technical communities, or sometimes they just evolve naturally over time, like the standard for the width of cars and roads, which can be traced back to the width or Roman roads, which was determined by the width of the two horses it took to pull a Roman chariot.Regardless of whether the standards are open or closed, it is the number of people and businesses that have adopted them that make them valuable. The more that have adopted the standard, the more valuable it is.Service contracts make services simple, modular, understandable and easy to access, like building blocks. Composability makes services combinable and connectable. Loose coupling is the standardized interfaces and connections that make it all work. |
| 撮影日 | 2012-02-12 17:01:50 |
| 撮影者 | dgray_xplane |
| タグ | |
| 撮影地 |