I would approach the prototype with a list of goals that you are trying to achieve.
I have a loose analogy that I use to describe the Broker/IS relationship. The Broker is like a mailman and each subscriber (trigger) is like a mailstop. Once you publish (hand the mail to the mailman) to the broker, the broker makes certain that the message gets to point B. Also, there’s a great guide on Advantage titled “Technical Note: Optimizing Publish/Subscribe Solutions.”
There are many reasons to use the broker. Older Architecture called for Broker/Broker Client Solutions. I am working on a project now where broker clients dial into the VPN to get messages and then disconnects. In this case, you really can’t “publish” the document. It is more efficient to “deliver” the document using pub.publish:deliver. You specify the client id and when the client connects to the broker, it will utilize the getEvent() method to get each message from the broker.
There are other ways to move messages around. With IS, you will probably use the Publish/Subscribe method. As in Maros’s post, you will need to create a publishable document. Then you will publish the document using pub.publish:publish. I like to use the fully qualified namespace (ns) for the document in my flow services, mainly to remind me that it is a publishable document and that I plan to publish this document somewhere in my flows. I always create a map step above my call to pub.publish:publish in the flow service to map the data into my document. The trigger will identify the published document and specify a receiving flow service. The input to the receiving flow service MUST have the published document as an input, AND the name of the document must be the fully qualified namespace name. For example, if you had a purchaseOrder document in your Default package and the interface for the document is Default, then the NS name would be Default:purchaseOrder and this is what the input would be for the receving flow service.
A simple test for the prototype is to have a document with one element named “message”. Make the document publishable. Create the second flow as described above. Invoke pub.flow:debugMessage in the second flow. Map the message element from the published document to the message input of debugMessage. This will write the message to the server log where you can see it.