Database Reference
In-Depth Information
tion store
in Oracle terms), we will have a chain of defer-awake records that are equal to
the number of asynchronous invocations. Moving further, we can defer the information at
any stage of the long running process for legal or compensative activities. This type of
storage is compulsory for all task-orchestrated services and is usually provided centrally
by an orchestration platform.
This fact makes all task orchestrated services far less autonomic than other service mod-
els. Surely, you can implement individual partial state deferral for every task-orchestrated
service (task service hosted within an orchestration platform), making them ultimately
autonomous. In that case, we truly admire the grandiosity of your project's budget, not to
mention the infrastructure and support.
Asynchronous services are not the only ones that need to maintain their state. A poorly
designed synchronous service with a lot of global variables, excessive looping or branch-
ing logic, and a lot of calls to underlying storage resources will consume a lot of memory
and CPU. There is no remedy for this scenario that is provided by the SOA technology
platform; you can only rebuild it from scratch. You could technically turn this service into
an asynchronous process and set the queues as transport means; however, that's not what
consumers expect, and the level of potential reuse drops considerably. Only services with
predictable state management will have predictable behavior and scale well when neces-
sary.
This principle addresses the same benefits as autonomy but has negative impact on the
autonomy itself.
Service discoverability
Despite its obvious meaning, this is arguably the most-neglected principle. The main reas-
on for such negligence is the misunderstanding of service governance boundaries. For
some, governance starts after the service deployment process in production. Although it's
been said many times before, we would like to repeat it again—governance starts long be-
fore the first line of code is written. You must plan for the following:
• Which service trace records will be left in your audit/trace log under the different
logging settings
• How service activities will be perceived by different operational policies
• How a service could be dynamically invoked by different consumers and control-
lers
Search WWH ::
Custom Search