On 11/02/15 12:19, Brian Candler wrote:
Or should “request order”, “update order”, “cancel order”, “notify order
status” etc all be considered separate “services” in Zato? In that case,
it seems to me there would be a need for a separate workflow engine for
processing the order, since Zato would consider each individual message
finished once it had delivered it.
Hi Brian,
yes, that’s how I’d approach it. Have Zato focus on individual calls,
each implemented as a separate service and all of them contributing to
the higher-level processes.
Question is, how granular the services would be and that would depend on
how re-usable there were.
I’m not familiar with ALA ND1651 and it looks it goes straight into
implementation details without presenting a semi-formal overview of the
process - in particular, I’d really like to understand what sort parties
are being integrated here so I may be off below.
For instance, it would look that Cease should rather be a process rather
than a service.
That process has a start, which means someone initiates a request to
Zato (to a Zato service) that knows who, which systems, to notify that
such and such ALA service needs to cease. Some of the systems will be
simply notified and some will need to produce responses.
Zato doesn’t come with a workflow engine but I expect it will grow one
within 2-3 releases.
Right now it sounds you’d definitely want to make use of asynchronous
messaging patterns and publish/subscribe:
https://zato.io/docs/progguide/patterns/fan-out-fan-in.html
https://zato.io/docs/progguide/patterns/parallel-exec.html
https://zato.io/docs/progguide/patterns/invoke-retry.html
https://zato.io/docs/pubsub/index.html
All of them work on different levels of your implementation
Let’s say we continue with Cease.
- An acceptCease service is invoked initially
- That service fans out to 3 other services
- One of them may publish a message using pub/sub
- The other two may need to synchronously invoke some other 2 backend
systems
- Once all of them complete, a final callback service gets invoked which
confirms to the initial that the Cease process ended successfully
At all points of the workflow you can, and in fact you should, store the
current state of the process in Redis so should in a catastrophic
situation your whole environment go down, you would be still able to
re-start the process.
Users also employ event-based approach in such situations. Essentially,
you keep a list of events and event handlers - where an event is an
interesting occurrence, such as the Cease business process starting and
https://zato.io/docs/progguide/patterns/async-invoke.htmlhandlers are
services registered for them. The list can be stored in Redis or cached
locally. Now each time an event occurs the list is consulted and
services registered are invoked. After they complete they invoke
services further in the chain so they are all loosely-coupled and the
only thing that binds them all together are the events they react to.
Here async callbacks will come in handy:
https://zato.io/docs/progguide/patterns/async-invoke.html
I’d definitely start with turning the concepts from ALA ND1651 into a
couple of diagrams to visualize how many actors there, what their role
is, and what the interactions between them are. It doesn’t need to be
BPMN right away - a set of simple diagrams like here would do:
https://zato.io/blog/posts/linux-journal-article-agile-esb-soa-rest-and-cloud-integrations-in-python.html
However, I’d use UML activity diagrams to specify actual steps once
actors and major state transitions are understood.
Zato services would follow from activity diagrams in that situations.
Let’s say we end up with a diagram like the one here - activities are
the parts that are closest to the service layer and decisions are simple
Python ifs:
http://www.learnsad.com/UMLACT.html
That’s how I’d translate it into Zato services:
-
Customer sends a request -> Zato service called create_request
-
System confirms the receipt -> create_request produces correct responses
-
Confirm the order - use pub/sub to notify the initial caller that the
order is being processed
-
Dispatch the order - use pub/sub to notify some backend system that an
order needs to be processed
As we can see, it turns out that this diagram doesn’t represent the
whole process - for instance, how is the original caller notified of the
progress? Is it at all? How does it know the processing is done?
All such questions need to be answered by the higher level design though
in your situation it will be quite easy because you already have a
formal spec.
However, Order Management can be surprising from time to time so I
simply wouldn’t jump straight into coding without an analysis phase the
product of which should be design documents.
Whether they are XML, SOAP or JSON is just an implementation detail -
generally, in Zato you work with pure-Python objects, mostly with dicts
or dict-like structures so you typically don’t deal with serialization,
headers and such unless you need to.
Happy to discuss it further if you can suggest a chapter from the spec
you’d like to go through in detail.
