Conversation

May 9, 2012 at 12:27 AM
Edited May 9, 2012 at 12:27 AM

hi there ... well, you're not gonna get rid of me that easy after diving into this :)

i was thinking of expanding the features and wanted your thoughts about this idea since you have more experience in this.

would it be beneficial to create what we would call a conversation which is a number of request replies between one or more parties but belong to a specific group and forced into a logical sequence ?

i.e: 

client :  -----> BEGIN CONV-1 ---> : Server

client :     ----> CONV-1:REQ-1  --- > Server 

client :    <------CONV-1:REQ-1-ACK --- : Server

server process operation ......

client :    <------CONV-1:RES-1 --- : Server

client :     ----> CONV-1:ACK  --- > Server 

client :  ------> END CONV-1 ---> : Server

 

the begin converastion can be started by either sides and closed by the same side that initiated it ... a forced END CONV could be after timeout or no answer for x Time ...

then if we track conversations and persist them, we could then create a sort of CONVERSATION TRANSACTION spanned overtime a across several messages and operations and not for the single message 

a default system default ACK message could be added already ... much like the "delivered" or "read" notifications of emails ...

 

 

Coordinator
May 9, 2012 at 1:04 AM

I don't quiet understand the system you are trying to build. What you describe sound like a system that requires a basic pubsub setup. But can you elaborate a bit more? 

May 9, 2012 at 12:01 PM

a traditional transaction works this way 

Begin Transaction 

      ... Do Work

End Transaction

all in one block of executable code.

what i a proposing is :

if we could group a number of messages happening overtime withing a conversation. say for example , i send an order now. the network is down or the otherparty is not connected ..... for some reason my message is not picked up. then network is re-established after a while and my message is processed, i receive an invoice and i send payment .... think of this happening across few days...  if we use the same principals of a transaction and wrap the whole thing into something we call a conversation. we can then act on it to track a whole process , commit, reverse, cancel , rollback ......... set actions if an event or a condition happens  within a conversation and not while processing the specific message or executing a specific piece of code.

 

the other thing is , it would be nice to have each message sent, answered automatically by an Ack (could be an option) ... it would work as a system delivery receipt just like a certified mail ... now if we add to it a digital signature  which can be verified by a third party, you can take it to the bank ... :). 

again, i'm thinking loud here (against a scenario i will probably need).

 

 

 

 

Coordinator
May 9, 2012 at 2:43 PM
Edited May 9, 2012 at 2:45 PM

Currently, psb does allows you to batch a collection of messages as a single message for a specific topic. Using the Topic.PublishMessages(static method) and Topic#PublishMany(instance method).

It already also has a feature called durable subscription.In which you can create a subscribe and set the flag Durable to true. The Durable function is also described here: http://pservicebus.codeplex.com/wikipage?title=How%20to%20subscribe%20to%20a%20topic&referringTitle=Documentation

Which in turn means whenever a message is sent and the subscriber transports fails to receive the message.The ESB will keep the message for the subscriber by default for 30 days then expires on the 31 days if the subscriber transport is still not available to avoid large backlogs.

The expiration date can be set for each message published, by simply called  the Topic#SetMessageExpiration(instance method), and doing so will override the default that is set by the ESB if it is not present.


As for the rest of the functionality(commit, reverse, cancel, rollback) you describe, it will have to be an API designed outside of ESB Server since the ESB is meant to be decoupled from how your application needs to run or function.I would suggest in this case for now to look at WF, I have a simple( very simple :) ) class that allows you to interact using topic publishs in WF(Workflow) 

The set of things described can be designed and distributed as an Extension to managing messages. I currently also have in the roadmap, to create a service that does message resequencing(which process a group of message that are associated to one another by some group id).

Not sure if it fit your bill of what you want :). And even with that, it does not interfer with your application and simply only order messages based on group.

As for message been Ack automatically, it will not be a feature that would be build into the ESB. But instead it will be a feature that can be provided by an external API since the ESB server is meant to be agnostic of your services/process and should never interact with your process directly except through transports communications.

The closest thing to Ack that I currently have is the Req/Resp API that allows you to mark a class as Request and Response. I am sure you have seen this sample already for a basic example( http://pservicebus.codeplex.com/SourceControl/changeset/view/64929b2b97e4#pServiceBus%202.0.0%2fSamples%2fTestRequestResponse%2fTestRequestResponse%2fProgram.cs )

May 9, 2012 at 3:44 PM

Very close to what i had in mind with the following difference:

what you have pout in place already sends a batch of messages in a topic all at once. the process happens all at once . am i right ?

what i was suggesting is doing the same but over time and exchanging messages separately, processing each separately while keeping all exchanges grouped within a conversation or batch if you wish.

the resequencing feature along with the "group ID" would be probably the solution to what i am suggesting.  the WF class is interesting (could you share it ?) ... as an extension, it could act on a messages of "group id" to roll back, and perform other functions ....  

 

you're right, all this can be added as extensions ... 

do you have guidelines, model or templates  for building extensions ? 

 

Coordinator
May 9, 2012 at 4:16 PM

When you send a batch of messages, it stores it as a collection of that message instance in the TransportMessage and when It is received it is received in the exact order it was sent.

When the client reads the message from their transports(e.x MSMQ), it will be read as a single message instead of multiple seperate messages. It does happen in one process, the messageReceived delegate simply yield each message to the lambda expression used to process message one at a time on the client process.

Once I have the resequencing feature implemented( 2.0.1 upcoming release), You will be able to set header information that will allow the ESB to process the message and order them for the particular group.E.x, When sending 5 messages, you will include a groupID for all of them in the header of the message and then a messageID which will be used by the resequencing service to order the message and send them out in the correct order(ascending order) no matter how they were originally sent.

Read this for reference: http://www.eaipatterns.com/Resequencer.html
The WF class is already part of the API and it is only currently good for just registering/publishing topic message and the rest of the read of message is up to you :)Link to source code here: http://pservicebus.codeplex.com/SourceControl/changeset/view/64929b2b97e4#pServiceBus%202.0.0%2fSrc%2fPServiceBus.Workflow.Activities%2fPublishESBMessage.cs

As this moment, I don't have a specific guideline for building extension. At this moment, It is kinda of free for all :) as long as you follow the naming convention.By using name such as I have done so far in the other API and having reasonable names. 


Such as 

PServiceBus.WindowsPhone (WP7 Client)

PServiceBus.Connector(Request/Response API)

PServiceBus.RemoteProxy( implements http://www.eaipatterns.com/MessagingGateway.html patterns)

I will try to do a write up on what I expect at some point.


Thanks again for the suggestions :)