On 6 Jul, 13:28, Jack Zai <[EMAIL PROTECTED]> wrote:
> 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.
>
> $service->setReplyQueue("queue://OrderResponse")
>
> 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
> service.
>
> Finally, I singed CLA a few days ago and I am happy to join you as a
> contributor.
>
> Jack
>
> 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 -


Thanks for the reply Jack. I'll need to see the code to help me parse
your responses:-)

I've turned on group member rights for uploading files so you can
upload you message service binding here.  If you create a PECL bug for
this new feature (marking it as Caroline suggested) then you can
reference the uploaded file. That will help us track changes we make
to PHP SCA based on your new binding. Once you've uploaded it we can
start to take a look at it and give you some feedback.

In order to run this new binding do we also need changes to SAM?

Regards

Simon


--~--~---------~--~----~------------~-------~--~----~
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 
http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to