Adapters

Search…
Adapters
Using XOOM Symbio adapters to translate between service/application, messaging, and storage state.
Use XOOM Symbio adapters to translate object state within a service or application to serialized states that are suitable for network-based messaging and long-term database storage. To explain the details within this topic we refer to the following components.
Type
Description
StateAdapter<S,RS>
The interface defining the behaviors of an adapter for application and serialized states.
DefaultTextStateAdapter
The default StateAdapter used when no type-specific adapter is registered with the StateAdapterProvider.
StateAdapterProvider
The registry and provider of StateAdapter instances by state type, as well as adapter behaviors using type lookups.
State<T>
The abstract base type that supports binary, object, and text serialization states.
BinaryState
The concrete type that supports State<byte[]>.
ObjectState
The concrete type that supports State<Object>.
TextState
The concrete type that supports State<String>.
EntryAdapter<S,E>
The interface defining the behaviors of an adapter for application sources and serialized entries.
DefaultTextEntryAdapter
The default EntryAdapter used when no type-specific adapter is registered with the EntryAdapterProvider.
EntryAdapterProvider
The registry and provider of EntryAdapter instances by source type, as well as adapter behaviors using type lookups.
Entry<T>
The interface that defines a serialized state persisted to a Journal<T>. A journal entry may be a serialized Source<T> concrete implementation such as those defined in XOOM Lattice: Command, DomainEvent, and ProcessMessage, and others.
BaseEntry<T>
The abstract base type that supports entry binary, object, and text serialization.
BinaryEntry
The concrete type that supports Entry<byte[]>.
ObjectEntry
The concrete type that supports Entry<Object>.
TextEntry
The concrete type that supports Entry<String>.
NullEntry
The concrete type that implements the Null Object pattern for Entry<byte[]>, Entry<Object>, and Entry<String>.
Using Adapters
There are a few ways to use adapters. You may use the default adapters or implement your own. The use of the default adapters may be good enough to get your service or application up and running quickly. As time passes and your DomainEvent and/or Command types change, you will need to replace the defaults with your own implementations.
Default Adapters
The XOOM Symbio tooling provides default StateAdapter and EntryAdapter types for both State and Entry. These default adapters will be used automatically when the service or application has not registered a custom adapter for a given state or source type. This means that you do not need to register these default adapters with the StateAdapterProvider or the EntryAdapterProvider.
The current default adapters are the DefaultTextStateAdapter and the DefaultTextEntryAdapter. Because these are default adapters you will not need to import them into your main code, although the import statements are shown here for clarity.
1
import io.vlingo.xoom.symbio.DefaultTextEntryAdapter;
2
import io.vlingo.xoom.symbio.DefaultTextStateAdapter;
Copied!
Both of these serialize from service and application object state to JSON text where the State and Entry types are TextState and TextEntry, respectively. They also deserialize from TextState and TextEntry back to service and application object state.
If you use a different text format other than JSON, or if you use binary, you must provide your own custom adapters. We may provide other default adapter types in the future depending on demand.
Implementing Custom Type Adapters
The following is an example of the implementation of a StateAdapter.
1
import io.vlingo.xoom.common.serialization.JsonSerialization;
2
import io.vlingo.xoom.symbio.Metadata;
3
import io.vlingo.xoom.symbio.State;
4
import io.vlingo.xoom.symbio.State.TextState;
5
import io.vlingo.xoom.symbio.StateAdapter;
6
​
7
public class ProductStateAdapter implements StateAdapter<ProductState,State<String>> {
8
  @Override public int typeVersion() { return 1; }
9
​
10
  @Override
11
  public Product fromRawState(final State<String> raw) {
12
    return JsonSerialization.deserialized(raw.data, ProductState.class);
13
  }
14
​
15
  @Override
16
  public <ST> ST fromRawState(final State<String> raw, final Class<ST> stateType) {
17
    return JsonSerialization.deserialized(raw.data, stateType);
18
  }
19
​
20
  @Override
21
  public State<String> toRawState(final ProductState state, final int stateVersion) {
22
    return toRawState(state.id, state, stateVersion, Metadata.nullMetadata());
23
  }
24
​
25
  @Override
26
  public State<String> toRawState(final String id, final ProductState state, final int stateVersion, final Metadata metadata) {
27
    final String serialization = JsonSerialization.serialized(state);
28
    return new TextState(id, ProductState.class, typeVersion(), serialization, stateVersion);
29
  }
30
}
Copied!
This ProductStateAdapter is responsible for adapting from the Product service/application object state to what is called the raw state and back again from raw state to the Product service/application state.
The raw state is suitable for traveling across a network and being persisted into database storage. This is handled by the two methods named toRawState().
The service/application state is, as the name indicates, used as operational state. Adapting from raw state back to service/application state is handled by the two methods named fromRawState().
There is another method, typeVersion(), that provides the current version of the operational state type. This specific implementation indicates version 1.  This version may also be encoded as a SemanticVersion, as is provided with XOOM Common.
The current type version is automatically encoded into the raw state. When adapting back from the raw state to the operational state, you must check the raw state's type version to determine if it must be upgraded to the current operational state type version. This is available via the variable public final int typeVersion in State<T>. (This is an immutable variable and does not require an accessor method.)
Next is an example of an EntryAdapter for the CartInitialized event.
1
public class CartInitializedAdapter implements EntryAdapter<CartInitialized, TextEntry> {
2
  @Override
3
  public CartInitialized fromEntry(final TextEntry entry) {
4
    return JsonSerialization.deserialized(entry.entryData(), CartInitialized.class);
5
  }
6
​
7
  @Override
8
  public TextEntry toEntry(final CartInitialized source, final Metadata metadata) {
9
    final String serialization = JsonSerialization.serialized(source);
10
    return new TextEntry(CartInitialized.class, 1, serialization, metadata);
11
  }
12
​
13
  @Override
14
  public TextEntry toEntry(final CartInitialized source, final String id, final Metadata metadata) {
15
    final String serialization = JsonSerialization.serialized(source);
16
    return new TextEntry(id, CartInitialized.class, 1, serialization, metadata);
17
  }
18
​
19
  @Override
20
  public TextEntry toEntry(final CartInitialized source, final int version, final String id, final Metadata metadata) {
21
    final String serialization = JsonSerialization.serialized(source);
22
    return new TextEntry(id, CartInitialized.class, 1, serialization, version, metadata);
23
  }
24
}
Copied!
The same design guidance applies for EntryAdapter implementations as for StateAdapter.
Registering Custom Type Adapters
Custom type adapters are registered with adapter providers. When the adapter provider is created it is registered with an associated unique identity in the World. The registration is a means to avoid the use of static variables to hold the adapter providers. It also makes it convenient for the various XOOM Symbio storage mechanisms to access the adapters when moving data into and out of the underlying databases.
To register a custom type adapter you first must allocate adapter providers, and then register each custom type adapter with a given adapter provider. The first example demonstrates registering state adapters.
1
World world = World.startWithDefaults("my-service");
2
​
3
StateAdapterProvider stateAdapterProvider =
4
    StateAdapterProvider.instance(world);
5
​
6
stateAdapterProvider.registerAdapter(
7
    ProductState.class, new ProductStateAdapter());
8
​
9
stateAdapterProvider.registerAdapter(
10
    CartState.class, new CartStateAdapter());
Copied!
The second example demonstrates registering entry adapters.
1
World world = World.startWithDefaults("my-service");
2
​
3
EntryAdapterProvider entryAdapterProvider =
4
    EntryAdapterProvider.instance(world);
5
​
6
entryAdapterProvider.registerAdapter(
7
    CartInitialized.class, new CartInitializedEntryAdapter());
8
​
9
entryAdapterProvider.registerAdapter(
10
    ProductPlacedInCart.class, new ProductPlacedInCartEntryAdapter());
Copied!
You should determine which states and sources (e.g. DomainEvent and Command types) must be exchanged across collaborating services and establish their schemas in the XOOM Schemata schema registry.
​
Object Storage
Cluster
Last modified 1yr ago
Copy link
Contents
Using Adapters
Default Adapters
Implementing Custom Type Adapters