Home
bla bla framework bla bla platform bla bla SOA
This framework has a number of unique features aimed at resolving real world problems:
- Expressive domain model language. We have semantic types, inheritance, metadata support, validation etc
- Multi-values as a way to better support versioning and data federation. Changing field type is no longer a backward-incompatible change.
- Projections as a structured way of defining both implementation and invocation contracts for operations
- Federation layer automatically providing reach graph APIs on top of domain-specific services
And of course a usual set of features:
- Language agnostic schema and operation interface definitions
- Pluggable wire protocols
- full CRUD support plus custom actions
- Bulk operations with partial failures support
- REST-like HTTP interface
- Asynchronous client bindings
- ... and much more!
Following sections give a high level picture of system design.
Typical deployment consists of a u number of domain-specific services deployed in a cloud, each providing it's own API. On top of them there is a Federator service which stitches individual services together to provide graph-like API.
Clients can consume services directly, like Client A, or they can talk to the federation layer, like Client B. They can also chose to use federator as a library and configure it to only see a selected subset of services, like Client C does.
Key point here is that services don't have to talk to each other in order to provide rich APIs, they focus on their own business and provide only minimal information about external relations in the form of IDs, URNs or any other link format.
Clients such as GUI can get access to the whole graph of objects provided by all of the services thanks to the Federator, which knows how to traverse the links between different kinds of objects. This knowledge is based on the individual services API declarations.
Service development consists of the following steps:
- Authoring service schema. Schema describes domain model objects and relationships between them
- Compiling schema and generating data transfer object classes
- Authoring interface definitions for supported operations
- Generating implementation stubs
- Implementing the stubs
Clients generate DTOs from schema and client bindings from IDL for their target language.
With federation in the picture everything stays the same, federator merely looks like another service which adds nothing to the schema (because it's the sum of all federated services schemas) but produces a lot of new, deep operations.