Service-Oriented Architecture

A further abstraction on top of the client-server architecture is the service-oriented paradigm.

This is a model that organizes the information in a server into services. These services can be discovered, interacted with, and used with known semantics. This means that the services have a defined behavior that will always produce the same result, given the same

preconditions.

This paradigm is the foundation of the most highly successful Internet systems, such as SOAP, REST, COBRA, RPC, Web Services, and so on.

A way to illustrate this is to relate it to a real-world example. Suppose that you have a package that needs to be delivered to another company quickly. The first thing you will probably do is call a courier company, arrange a pickup of the package, and then pay for the service. The key concept is that you know what is going to happen. There is an implicit set of behaviors that the courier company will be following. On any day, given the same

package to be delivered, the courier company will do exactly the same thing—deliver it to its destination, on time. This service has known semantics with defined behavior that produces predictable results.

An interesting part of this is that you are interacting with two different people at the courier company: the person who answered the phone and took your request and the

delivery driver who collected your package. You also used, although unknowingly, a third person who dealt with the financial transaction. Each of these people provide a subservice that, when combined, results in the primary service offering of the courier company.

Some of these subservices are also generic; they could be used interchangeably by many

different types of companies. The processing of financial transactions is something that is done pretty much the same way in every company. Similarly, the function of taking phone calls for picking something up at one location and dropping it off at another could also be applied to taxi companies.

For all this to work, everything must adhere to a set of rules and conventions that are outlined in the sections that follow.

2.11.2.1. Formal Contract

For a service to be considered a service, it must follow a formal description of both its exposed functionality and how it behaves. For example, the courier company driver wears the company uniform, drives the company vehicle, and greets the customers in a pleasant manner. He will also drive between locations quickly and safely, and deliver the packages intact. Any violation of these rules would break the contract that the customer has with the courier company. Most courier companies therefore also require customers to agree to this formal contract before picking up their packages.

A side effect of having a formal contract is that it becomes easy for one instance of a service to be replaced by another instance of the service. This is possible only if the two instances of the service both expose the same functionality and behavior. For example, if the financial person left the company, it should be easy to find a replacement who knows the same accounting rules.

In Bluetooth low energy, these formal contracts are captured in service specifications that are formally adopted by the Bluetooth SIG. These specifications also have test specifications that ensure that the behavior of an implementation is valid.

2.11.2.2. Loose Coupling

In object-oriented software, each individual component of the system is meant to be designed as a separate object with no side effects. Those interactions that do occur between

components can then be explicitly defined and tested.

By reducing the dependancies to a minimum, each service implementation can be

changed without risk that unexpected side effects are either introduced or lost. Taking this to its logical conclusion, there should be a separation between the formal contract and its

implementation. This then allows the implementation to be changed at will, as long as the formal contract is not broken and is unchanged.

For example, it is possible to add more drivers to the courier company, changing the implementation from a single driver doing everything to many drivers collecting packages from a small area of a city, bringing them back to a central warehouse, and then sending them back out, possibly with a different driver. From the customer’s point of view, the

service is identical, packages are collected and delivered as required, but the implementation is completely different. And this was possible without changing the financial or order-taking services.

2.11.2.3. Abstraction

Service abstraction is an import design rule because of the consequences if this rule is not followed. If there were no abstraction and a client had full knowledge of how a given service

was implemented, that client might start to use that service in a way that constrains how the service can evolve.

It is common knowledge that more information is good. However, in the context of a service-oriented architecture, the less knowledge that a client has about how a service is provided, the better it is. With too much knowledge, the client might obstruct the reuse or redesign of the service because the client is implicitly linked to the specific implementation.

If the service implementation changes, the client might break.

To ensure that this rule is followed, only the absolute minimum of state must be exposed by the service. Also, only the external manifestation of the service behavior should be

specified.

2.11.2.4. Reusability

The concept of reusability is a design goal that was one of the promises of object-oriented methodologies for many years. However, reusability is really the ability for a service to be designed so that it could be applied to multiple different applications. Without careful thought, it is always easier to design a service that only does one job. With good design, services can be designed to be independent of the actual process that is used. This means that the service can then be reused in another application, quickly and easily.

The Bluetooth SIG has responded to this challenge by setting up a working group that has but one job, which is to look out for generic functionality and then abstract the

requirements to enable significant reuse.

2.11.2.5. Statelessness

To be able to scale services for many clients, the servers cannot hold any client state data. A service could be defined that remembers everything the client has told them so that the client doesn’t have to repeat this information on subsequent requests. The problem with this

approach is that this information takes up a lot of memory and relies on this shared state information being in sync on both the client and server. This therefore leads to the server being reliant on the correct functioning of the client; this is a bad assumption.

Therefore, the statelessness design goal removes all the state from the interaction between the client and the server. There will still be some state information stored in the service, but this is always the server’s state and is never the client’s state. This means that any client can then send any request at any time and the server will respond to the same request in exactly the same way, regardless of which client made the request.

2.11.2.6. Composability

All the preceding goals imply that services should be designed to be both small and very simple. But the real world is never that simple. Real-world services are complex. To resolve this apparent conflict, a service-oriented architecture encourages the aggregation of smaller services to enable higher service interfaces.

The aforementioned design goals for services all encourage that they can be combined.

For example, the courier company service was shown to be composed of three separate services. As long as each of these individual services followed the stated goals, these can be combined into a courier company. Similarly, some of these services could be combined to make a taxi company or an executive car service. The implementation might be different—a

delivery van, a family car, or an executive limousine—but the services are essentially the same.

2.11.2.7. Autonomy

For services to be reused and combined, they must be reliable. A service that relies on other components within the system to perform received requests will not be as reliable as a

service that has complete control over everything it does.

An autonomous service can stand alone and perform its task, regardless of what is going on around it. These services can be reused in other applications with very little difficulty. A service that is not autonomous would probably have to bring many other support services;

these additional services might conflict with other services.

For example, the courier company drivers function autonomously, collecting and delivering packages, as they are told to do. They will continue to function autonomously even if there is a major malfunction in the office.

2.11.2.8. Discoverability

Finally, for services to be used, they must be discoverable. This might appear obvious at first glance, but service discoverability is essential for ad hoc networking. Without service

discovery, all services must be statically programmed; a complex, burdensome, and error-prone task.

Typically, these use a separate protocol from the protocol used to interact with the

service. For example, to find the courier company, somebody might have used a phone book or searched on the Internet; they would not just call random telephone numbers and hope that one would be a courier company.

Bluetooth low energy takes a different approach and uses a single protocol for both the discovery of services and interacting with these services. This protocol is called the Attribute Protocol, and service discoverability is described in its profile, the Generic Attribute Profile.

Both of these are described in Chapter 10, Attributes.

Chapter 3. Architecture

That’s been one of my mantras—focus and simplicity. Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple. But it’s worth it in the end because once you get there, you can move mountains.

—Steve Jobs

The architecture for Bluetooth low energy is fundamentally very simple. As shown in Figure 3–1, it is split into three basic parts: controller, host, and applications. The controller is

typically a physical device that can transmit and receive radio signals and understand how these signals can be interpreted as packets with information within them. The host is

typically a software stack that manages how two or more devices communicate with one another and how several different services can be provided at the same time over the radios.

The applications use the software stack, and therefore the controller, to enable a use case.

Figure 3–1. The Bluetooth Architecture

Within the controller, there is both the Physical Layer and Link Layer as well as a Direct Test Mode and the lower layer of the Host Controller Interface. Within the host are three protocols: Logical Link Control and Adaptation Protocol, Attribute Protocol, and the Security Manager Protocol. Also within the host are the Generic Attribute Profile, the Generic Access Profile, and modes.

3.1. Controller

The controller is the bit that most people can identify as the Bluetooth chip or radio. Calling the controller a radio, however, is very simplistic; the controller is composed of both analog and digital parts of the radio frequency components as well as hardware to support the transmission and reception of packets. The controller interfaces with the outside world through an antenna and to the host through the Host Controller Interface.