Lecture 15 - Technical Details

Book Author: Nicolai M. Josuttis
Chapter Fifteen: Technical Details

IT-Slideshares http://it-slideshares.blogspot.com/

15.1 Services and States
 Often descriptions of SOA claim that services should (ideally) be
stateless.
 However, what is meant by “stateless” or “stateful” in the context of
services can be a source of confusion with reason.
 There is always some state involved , even with stateless services.
 The key questions are where and how long this state is kept.
 Whether a service is stateful is a matter of perspective.
 Services may be stateless from a business point of view and stateful from a
technical point of view, and vice versa.
 This section looks closely at the issue of “state” in the context of
services, clarifying the terminology and discussing different
approaches used in practice.

15.1.1 Stateless Services
 Conceptually, a stateless service is a service that does not maintain any state between different service
calls.
 After the service call is over, all local variables and objects that have been created temporarily to run the service
are thrown away.
 The service is stateless when all the data of the service instance (process or thread) that performs the
call is thrown away after the call.
 According to this definition, even a stateless service can change state. However, it is only the state of
the backend or frontend that gets modified. (Example in Figure 15.1).

 In this example it is obvious that no service state is involved.

15.1.1 Stateless Services (Cont)
 Let’s look at another stateless service that does internally keep a state.
 you have a service that modifies an address on two different backends.
 A loosely coupled implementation of the service using compensation instead of
transaction contexts
 Consider the following pseudocode :
string changeAddress (newAddress)
{
oldAddress = backend_1.getAddress( );
status = backend_1.changeAddress(newAddress);
if (status == failure) {
return "couldn't modify address in backend 1";
}
status = backend_2.changeAddress(newAddress);
// compensation: restore old address to keep consistency
status = backend_1.changeAddress(oldAddress);
fatalError(...);
}
return "couldn't modify address in backend 2";
}
return "OK";
}

 As pseudocode  This service has a state , and at the end , the state of the associated
backends might be modified (See Figure 15.2)
 The service as a whole is stateless, however, because at the end of the call you can
throw away all the internal data. A second call of this service could run using a totally
different service instance.

15.1.2 Stateful Services
 What ‘s a stateful service
 A stateful service is a service that maintains state over multiple service calls.
 The typical example of a stateful service is a shopping cart. (Figure 15.3)

 What makes things complicated is that having the state of your shopping cart as part of your
service is not the only possible solution.
 In fact, there are three possible ways to implement a shopping cart:
 Keep the state in a service.
 Keep the state in the backend.
 Keep the state in the frontend/consumer.
 Probably the most intuitive way to implement a shopping cart is to keep the state in a stateful
service (see Figure 15.3)
 You are establishing a session and stored information in cookie or as a part of your URLs.

15.1.2 Stateful Services (Cont)
 Another way of implementing the shopping cart application. The second solution is
to keep the state in the backend.
 You need a way to identify the user’s shopping cart (or session) in the backend.
 As in the previous example , the backend might create a session ID, which the service
transfers to the consumer, where it can again be stored as a cookie or as part of the URLs.
 …
 Both solutions need some way to locate the correct session. With stateful services this is a
task of the ESB, and when the state is kept in the backend it is a task of the backend.
 The third solution is to store the state in the frontend or consumer.
 The service returns the complete state , not just a session ID, to the consumer.
 The state is stored as a cookie or as part of the URLs.
 When another item is added to the shopping cart, the consumer sends the whole state to
the service.
 Because the complete state is stored in the client, the service can be stateless, and
again, the backend doesn’t know anything about the shopping cart until the user
orders the items or makes the shopping cart persistent for later use.

15.1.2 Stateful Services (Cont)
 All three options (Summarized in Table 15.1 ) have different advantages and
drawbacks :

 Putting the state in the frontend/consumer means that the services can be stateless
and the backend is not involved. However , you can’t change the frontend while the
session is running.
 Putting the state in stateful services requires more resource in the service layer and
some way to route service request requests to the same service instance. However ,
you can change frontends , and the backend is not involved.
 Putting the state in the backend allows you to use stateless services , and the
frontend doesn’t have to provide storage, However , the backend is involved in each
session.

15.1.3 Why Stateless Services Are Better
 First of all, with stateless services load balancing and failover for the service
layer are pretty simple.
 The ESB only has to get implemented in such a way that the next best available
service instance (process or thread on some hardware) is used.
 It can even be a thread that other consumers were using earlier (if pooling
mechanisms are implemented).
 The solution scales linearly, and if a service instance dies others can jump in.
 Stateful services, on the other hand, have the drawback that they are bound to
sessions.
 In practice :
 It is often acceptable for a server’s session data to be lost if the server fails.
 If the data is important or even “juristically relevant” for the business, it is always
recommended to use the solid backup strategies of backends.
 If you put such data in stateful services, your service layer (silently) gets the role of a
backend system, which usually leads to confusing architectures (roles and
responsibilities). (View Section 6.4.2 in for more on this topic)

15.1.4 Stateless Services in Practice
 In practice, services may become stateful for very different reasons:
 Shopping cart implementation and process services with multiple-channel support.
 There might be a business requirement to preserve the combined state of multiple service calls
before this state gets further processed or persisted in a backend.
 Bulk services..
 Sometimes a service processes bulk data and/or calls hundreds of other services.
 For example, a CRM service might assign all customers of a certain kind (working for the same
company, having the same existing contract, etc.) a new contract or option.
 Performance.
 Performance can be a very important reason to introduce stateful services.
 One typical example is services that allow you to iterate over lists of results.
 Security.
 Security can be another important reason to switch to stateful services.
 It might be necessary to keep the state of a session inside a service so that you don’t have to identify
the consumer and load its user profile with each service call.
 Because stateful services are also useful, it’s good idea to provide some way of
implementing and dealing with them.
 As stated earlier, stateful services may require more resources, but they don’t prevent
linear scalability.
 Nevertheless, it is still a good idea conceptually to recommend that services should be
stateless.

15.2 Idempotency
 Idempotency is a possible attribute of services (see Section 3.3.5).
 In the context of services, it means that multiple deliveries/processings of identical
service calls cause no problems. For example (Figure 15.4)

 When the service consumer does not get a response, it doesn’t know whether the
service was successful or not.
 To be sure, it might retry the service call, sending the same request again.
 As a result, the service request might arrive at the provider for either the first or the second
time.
 If the service is idempotent, it makes no difference how often the service request
arrives: multiple requests of the same service call have only one effect.

15.2.1 Idempotent Services
 All reading services are idempotent, because it doesn’t matter how often a service
provider performs a request to return data.
 Writing services can be either idempotent or not.
 They are not idempotent when the effect of a service call depends on the existing state of
the backend.
 For instance, in the previous example, the resulting balance of the bank account depends on the
initial balance.
 An example of an idempotent writing service would be a service that sets the address of a
customer by sending all address data.
 Note that you can often avoid having services that are not idempotent.
 For example, we could make our banking service idempotent by modifying its semantics
so that the new value is sent instead of the amount to add. That is, instead of calling:
addToBalance(100)
 we could call:
setBalanceTo(600);
 But from a business point of view , make services idempotent can become complicated.
 In addition, from a business point of view there are some services that are inherently not
idempotent.
 All services that create something new have no state to compare with (unless you know the
state of the factory that creates new resources).
 For example, if you have a service that creates a new bank account, you create it and that’s
it.

15.2.2 Implementing idempotency
 If introducing idempotency is a problem from a business point of view, you need
some technical support for idempotency.
 The general way to implement idempotency is pretty simple.

 As Figure 15.5 , The consumer has to send data in such a way that the provider can see that
two technical request are the same.
 The consumer can send a unique ID with each new request. (This approach isn’t improve performance)
 A consumer can send a flag with a request so that the provider knows whether it is a retry. (Improve
performance…)
 Of course, idempotency doesn’t have to do only with request messages and doesn’t
affect only service providers.
 Note that communications protocols—including, notably, the Web Services
protocol HTTP—often are not reliable. In this case idempotency is a common
requirement for better reliability.

15.3 Testing and Debugging
 Distributed processes are a fundamental part of your business.
 Therefore, you must ensure that they behave correctly before you bring them
into production.
 In addition, you must have mechanisms in place to track problems and fix bugs
in the event that problems arise.

15.3.1 Unit Tests
 Services are a natural fit for unit testing.
 For each individual service, it should be relatively easy to implement unit tests.
 Because services should be self-contained, unit tests that test the interfaces will
usually also be self-contained.
 The only problem is providing test data so that the service running in test mode can
be semantically validated.
 For a basic service, you need some way to provide test data for the backend
only, However for more complicated services testing can be more difficult.
 Note that if you generate service code, test code may also be generated. This
minimizes the effort required to write unit tests (See Section 18.1)

15.3.2 Distributed Testing
 Testing composed or process services can become a real problem.
 These services use multiple backends, you need consistent test data distributed over
all the backends.
 In systems with different owners and interests, this can become a nightmare.
 One option is to replace service calls to other systems with local dummy
implementation.
 The unit test will test only some behavior of the service , not its full distributed
behavior.
 For the company , this approach helped for local testing , but it turned out that a lot
of problems were not found until integration tests over all the backends began.
 Another option to consider is introducing the ability to label service calls as
being in test mode.

15.3.3 Correlation IDs
 Scenario :
 In distributed environments, it is very important to be able to monitor
process and data flow so that you can understand system behavior and
analyze bugs.
 Distributing business logic doesn’t make the logic simpler.
 You are not in a single process or on a single system.
 To debug, you need the support of your infrastructure (your infrastructure becomes your
debugger for distributed processes).
 There is a significant difference between local and distributed debugging in terms of
tool support and effort required, especially if heterogeneity comes into play.  This
can be a major drawback of distributed processing.
 It is a vital requirement for your infrastructure (ESB) to be able to :
 Correlate the messages that make up a service call or a complete business process.
 Correlate the data flow outside of the ESB with the data flow inside it.

15.3.3 Correlation IDs (Cont)
 Consequence :
 You usually need to be able to tag the data in different systems and processes with
one or more IDs. Such IDs are called correlation IDs.
 Purpose & Uses Of Correlation IDs :
 Correlation IDs can be used either to correlate all the data and processings that
belong to one service call (including service calls inside that service call), or all the
data and processings that belong to one business process (including all service calls)
 You might end up using as many as four different IDs with each service call:
 A local ID for the message, provided by your infrastructure (tool).
 An ID that correlates a message with all other messages related to the same service call.
 An ID that correlates a message or service with all other messages and service calls related to the
same business process.
 A technical ID to deal with idempotency.
 You should take the semantics of the different IDs into account.
 Your correlation ID policy may evolve as your ESB grows.

15.4 Dealing with Technical Data
 Scenario :
 Besides the business data (“payload”), you need some data to route messages, check
security aspects, trace and monitor messages, and so on.
 How all of this is handled depends on your middleware and ESB technology, but
usually this information is kept in a kind of header (for example, a SOAP header).
 When your SOA landscapes runs, you will inevitably find that you need some
additional data for other or new ways to deal with messages from an infrastructure
point of view.
 You must provide some way to add new technical attributes without breaking
interfaces generated for a service.
 That means binary compatibility is a must.
 It is almost impossible to change the fundamental technical format of a message in a way that
requires all associated systems to recompile and deploy at the same time.
 Approach :
 With this issue, the recommend approach is for your technical header to
include a generic list (such as a key/value list), which might grow over time.

15.5 Data Types
 Another fundamental technical detail you have to decide upon is which data
types and programming paradigms to use to exchange data via services.
 This issue is influenced by concerns about loose coupling.
 The more complex data types and programming models you introduce, the more
tightly coupled the systems will be.
 Harmonizing data types over distributed systems is a common and natural
goal, because it simplifies data sharing.

15.5.1 Fundamental Data types
 Difference of Fundamental data types and common data types
 Fundamental data types are simple and stable , so no versioning is provided for them.
 For these types , code generators and adapters have native behavior and implementation.
 Common data types might change over time, so versioning is required.
 These fundamental data types :
 Strings
 Numeric types (integers, floats, …)
 Booleans
 Some fundamental general business types, such as date/time
 Some fundamental domain-specific types, such as phone numbers for
telecommunications companies and bank numbers for financial domains
 A type to exchange binary data
 Drawback of Fundamental Data types
 Specifying such a type as a fundamental data type would be too risky. (E.g consumer’s
requirements for something like an address type or a bank account type might vary widely
and change over time)
 Agreeing on such a type across all systems often turns out to be pretty complicated.
 If you are able to agree on such a type, you can define it as a “common” data type
that can have different versions.

15.5.2 Reference Semantics
 Enabling reference semantics means that defined values exist that represent
the state “not set”(This has an important impact on service interfaces).
 For example, with reference semantics you can provide an interface with the
following signature:
changeContactData (string customerID, // customer ID
string phoneNumber, // null: no change, empty: delete
string faxNumber, // null: no change, empty: delete
string email); // null: no change, empty: delete
 For all three parameters—phoneNumber, faxNumber, and email—you can pass a string
containing the new value.
 However, passing null means that there is no change, and the existing customer properties
remain valid.
 This is different from passing an empty string, which results in the existing value being
deleted.
 Without reference semantics, you could not specify the difference between “no change” and
“delete.”
 Of course, if you enable reference semantics, the infrastructure protocols and
programming languages you use must support it.

15.5.3 Higher Data Types
 You should be able to create new types based on your fundamental data types.
 In principle, Providing the ability to define data types, as is possible in
structured programming languages. That means:
 You should be able to compose structures and records containing multiple attributes
or members of different types.
 You should be able to define lists/arrays of a specific data type.
 You might think about being able to define type aliases (typedefs).
 You might also think about value constraints such as specific value ranges for
numeric values or formats for strings.
 …
 Be very careful with anything else.
 When defining your fundamental data types , you have to find the right
balance between powerfulness , complexity , and portability.

15.6 Error Handling
 You need some way to deal with errors because unfortunately, things can go wrong
 Services that return something ( such as those using the request/response message exchange
pattern) should not only have a return type but also one or more types for errors and exceptions.
 With Web Services, for example, you can specify fault messages that serve this purpose.
 You should consider introducing a common type for all services.*
 This has the advantage that it is possible to deal with exceptions in a generic way.
 The common error or exception type should, of course, provide enough information that
individual error handling still is possible.
 It should contain an individual errorID and a key/value list for specific details.

 Table 15.2 gives an example of the attributes a generic exception type might have

15.7 Summary
 There are several valid reasons for introducing stateful services. Note, however, that there
are different ways to deal with state, depending on the view. Dealing with state can be
pretty complicated and confusing.
 Prefer stateless services, but use stateful services if necessary. Note that stateful services
need more resources but usually do not prevent linear scalability.
 The way state is handled should be transparent to service consumers.
 Try to make your services idempotent. If this is not possible, think about a common way
(policy) to deal with services that are not idempotent.
 Support unit tests for services. Note, however, that for non-basic services unit testing can
become very complicated, because of the task of providing consistent distributed test
data.
 Distribution looks great when everything runs smoothly, but when problems occur it can
become a nightmare. It’s important to provide support for debugging and monitoring.
 Use correlation IDs, and use a string data type for these IDs.
 Provide the ability to extend message headers later without breaking the binary
compatibility of interfaces (via key and value lists).
 Be careful when defining the fundamental data types and programming models for your
service infrastructure (ESB). I recommend using common structured data types
 Consider defining a common exception type that is used by all services. This allows you
to deal with errors in a generic way.

Lecture 15 - Technical Details

More Related Content

Similar to Lecture 15 - Technical Details (20)

More from phanleson (20)

Lecture 15 - Technical Details

Editor's Notes