There is a very interesting thread (Command Server Gotcha) in this forum that revolves around the Quality of Service (QoS) of a message based Service.  In this case, the Service is provided by the IBM MQ Command Server.  Services are requested via PCF command messages being placed into a queue (SYSTEM.ADMIN.COMMAND.QUEUE).  Replies are sent to the "Reply To" queue specified in the message.  

There is no formal specification for this "Service" in the IBM Knowledge Center (KC).  The KC does recommend using non-persistent messages to invoke the Service.  The reply messages generated by the Service are also non-persistent.  To me, this indicates a fairly "low" QoS:

• Maybe the Service will receive the request (or maybe not).
• If the Service receives your request, it will produce one or more reply messages.
• The Requestor will not know, in advance, the number of response messages.  
• Maybe the Reply messages will be delivered (or maybe not).  
• Maybe the Request was executed successfully (or maybe not).  

None of these actions is guaranteed.  The Service is designed to potentially discard Reply messages and encourages disposable Request messages.  The Service invocation is asynchronous, so the Service Requester is never assured of knowing the result of the invocation.  This is what I mean by a low QoS. 

That thread talked about "Defensive" programming, but the recommendations are really about understanding and programming for the specified QoS.  So, how do we document this QoS?

API Connect (APIC) is designed to handle HTTP based Service requests (HTTP or SOAP).  In other words, APIC is designed to only be able to handle synchronous Services.  Where are we supposed to put the asynchronous Service specifications?  If not in APIC, then where?  

The ironic part of this discussion is that the Cloud based Microservices community has been trying to minimize the problems with a network of tightly-coupled synchronous RPC calls (e.g. HTTP/SOAP).  The current design is to create "Circuit Breakers" and "Bulkheads" to minimize the consequences of API failures.  At the very cutting edge of Microservices design, folks are beginning to talk about asynchronous communications as the NEXT BIG THING.  

The messaging community hasn't been very tightly integrated with the Service (now API) management community.  Perhaps it's time start?   

Regards,

Glen Brumbaugh

IBM Champion (Cloud)

Glen,

I can't resist putting in my two pennies worth since there is a lot of deja vu (or should that be "Back to the Future" ?) re. your comments.

Your particular points re. the issue with the Command Server (exposed by T.Rob with his usual thoroughness) of course apply in general to Async Messaging and have been true forever. But in ANY Request/Reply model - even Sync ones inside 2 PC protocols have failure windows in which the client does not know if the request has been received, or received and executed, or received, executed and a reply sent on its way which hasn't yet made it to the client. 2 PC will guarantee atomicity but that doesn't help the client who is facing a "blank" screen and is wondering what has happened to his/her request.

I could go on and talk about the various efforts over the decades since MQ came out to define and support compensating transactions in an Async world but I'll stop here in case I am missing the points you are making. 

Dermot,

I think that we are probably in complete agreement.  As you said, the challenges involved with using an asynchronous process have been known for a long time and are only slightly more complicated than those of a synchronous process.  Users of synchronous Web Services, for example, must also handle the lack of response (timeout) condition.  Any service, synchronous or asynchronous, can have the same possible outcomes:

1. Successful return with complete data
2. Successful return with incomplete data
3. Unsuccessful return.
4. Incomplete return.
5. No return  

"Success" is a combination of both receiving a response (transport level success) and of the provided return code(s) and data (functional processing success).  Most of our Service Management tooling only looks at the first point and specifies the availability and responsiveness for that first result. 

Have you had any experience with messaging based services that were, perhaps, more extensively documented?  In my own personal experience, I haven't experienced this level of documentation nor have I seen it supported in a tool. That doesn't mean that it doesn't exist, just that I haven't experienced it.  From my own experience, it's been assumed that the programmer understood these things and handled them appropriately.  However, the programmer needs some help/documentation/tooling to fully understand conditions #2 and #4.   

As the industry merry-go-round comes around again to software interactions  (now known as APIs, 20 years before that known as Services, 20 years before that known as Components), we still don't seem to be an farther along in actually "managing" these interactions.  It seems to me that we're actually making progress on is software location and security.  These two are important components in managing the software, but not all that is required.   

Regards,

Glen Brumbaugh

IBM Champion (Cloud)