Unlike any of other bindings, where an http server is used for
listening to the ports, for the ms binding, a service is started from
a console (e.g. > php myservice.php). Once the service is started, it
will keep trying to get message from the queue, and it can be
terminated by pressing <Ctrl> + <C>.

"Reply to" information is provided by the client using the
'scaCallbackQueue' user property or the JMSReplyTo header, in other
words the name of the reply-to-queue should be found in the message's
header. And the client can change its reply-to-queue at any time by
calling setReplyQueue method.


However, according to the spec, the "reply to" information does not
contain any information about the message provider (e.g. host,
port ...). so I have to assume the reply-to queue is in the same
broker of the service queue.

At moment, my solution is implemented in a synchronous manner. A
reference is expecting the response immediately after a request being
sent.  I think we have many options to achieve asynchronous
communication, but I am not sure how users want it be done, that is
one of the points we need to discuss more about. Currently a client or
a reference can tell the proxy not to expect response by calling
setWaitResponseTimeout(-1) to a negative value.

Answer to the last question is no, you can not receive messages from
service implementation. Actually I don't see why you need to, as that
would cause problems if later you want to expose it as soap or another

Finally, I singed CLA a few days ago and I am happy to join you as a


On Jul 5, 6:41 pm, "Simon Laws" <[EMAIL PROTECTED]> wrote:
> On 7/5/07, Jack Zai <[EMAIL PROTECTED]> wrote:
> > Hi,
> > I am developing a JMS binding and would like to discuss some of the
> > work i've done. basically, a message service listens to a queue at
> > some JMS message provider e.g. ActiveMQ or IBM Websphere MQ. And a
> > client or a reference can invoke the service's method by sending
> > message to its destination queue, and receive the response from a call
> > back queue, which can be provided at runtime by the client.
> > I found there is an existing specification for SCA JMS Binding [1]
> > from OSOA. This spec describes stuff like when receiving a request
> > which method should be invoked, and how the data/parameters are packed
> > into a JMS Message. I've already implemented section 1.5 and section
> > 1.7.2 of that spec, and have some thoughts about the conversations
> > (section 1.7.3), but not yet implemented.
> > In addition, my solution requires another pecl extension SAM [2] for
> > connecting to the message providers. The reason of choosing SAM is
> > because that SAM provides one API for different messaging
> > infrastructures, and also provides a generic extension mechanism which
> > makes it easy to add new support. Currently SAM only supports XMS[3]
> > for IBM products and MQTT, but I've also developed a new Stomp support
> > for Active MQ, which will be included to the next release of SAM very
> > shortly.
> > If anyone is interested in the JMS binding or have any questions,
> > please join the discussion here.
> > Jack Zai
> > [1] SCA JMS Binding V1.00 (PDF)
> >http://www.osoa.org/download/attachments/35/SCA_AssemblyModel_V100.pd...
> > [2] SAM - Simple Asynchronous Messaging for PHP (http://pecl.php.net/
> > package/sam)
> > [3] XMS -
> >http://www.ibm.com/developerworks/websphere/library/techarticles/0509...
> > Hey Jack, that sounds really cool. A couple of questions.
> - How does a service listen to message queues. I.e. is there really a
> listener or do you rely on user events before going and reading input
> queues?
> - Does the service take notice of the "reply to" information that can appear
> in messages?
> - How does a reference generate "reply to" information
> - What does it mean to have a reference defined with a ms binding. Does it
> mean calls through that reference will be synchronous, asynchronous or do I
> get to choose.
> - Is there a way I can programmatically receive messages from within a
> service implementation.
> It would be really good to get a look at the code. I'm not sure what the
> process is for getting it from you. Have you signed a project Contributor
> License Agreement (CLA) to indicate that you are free to give us the code
> and are happy for us to use it?
> If you have we could transfer it via the files section of the group but I
> notice that it's set at the moment so that only managers can upload files.
> We could do that via email and have one of the maintainers patch the code
> into the branch for all to see. But what does everyone think about how we
> should handle contributions like this. Should we have a separate place where
> people can put contributions (like the file section of the google group)?
> Regards
> Simon- Hide quoted text -
> - Show quoted text -

You received this message because you are subscribed to the Google Groups 
"phpsoa" group.
To post to this group, send email to phpsoa@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 

Reply via email to