You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@tuscany.apache.org by Nishant Joshi <ni...@gmail.com> on 2008/01/23 11:57:49 UTC
Problem with stateless (and stateful) Callback Service
Hi All,
I have successfully created and tested stateless callback service with
webapp with Tuscany-1.0.
Now have a problem with Tuscnay-1.1-RC3......
My stateless service was deployed in Tomcat as a war(Tomcat was running on
8080)....
Now my problem is as below, i got following error on client side when i try
to run my client(stateless callback)....
-------------------------------------------------------------------------------------------------------------
Exception in thread "main" *org.osoa.sca.ServiceRuntimeException*: *
org.apache.tuscany.sca.host.http.ServletMappingException*: *
java.net.BindException*: Address already in use: bind
at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(*
SCADomain.java:264*)
at org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(*
SCADomain.java:69*)
at com.example.ConversationalClientStatefulImpl.main(*
ConversationalClientStatefulImpl.java:261*)
Caused by: *org.apache.tuscany.sca.host.http.ServletMappingException*: *
java.net.BindException*: Address already in use: bind
at org.apache.tuscany.sca.http.jetty.JettyServer.addServletMapping(*
JettyServer.java:207*)
at org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceProvider.start(*
Axis2ServiceProvider.java:237*)
at org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceBindingProvider.start
(*Axis2ServiceBindingProvider.java:91*)
at org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.start(*
CompositeActivatorImpl.java:484*)
at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.<init>(*
DefaultSCADomain.java:189*)
at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(*
SCADomain.java:230*)
... 2 more
Caused by: *java.net.BindException*: Address already in use: bind
at sun.nio.ch.Net.bind(*Native Method*)
at sun.nio.ch.ServerSocketChannelImpl.bind(*ServerSocketChannelImpl.java:119
*)
at sun.nio.ch.ServerSocketAdaptor.bind(*ServerSocketAdaptor.java:59*)
at org.mortbay.jetty.nio.SelectChannelConnector.open(*
SelectChannelConnector.java:209*)
at org.mortbay.jetty.AbstractConnector.doStart(*AbstractConnector.java:252*)
at org.mortbay.jetty.nio.SelectChannelConnector.doStart(*
SelectChannelConnector.java:294*)
at org.mortbay.component.AbstractLifeCycle.start(*AbstractLifeCycle.java:40*
)
at org.mortbay.jetty.Server.doStart(*Server.java:221*)
at org.mortbay.component.AbstractLifeCycle.start(*AbstractLifeCycle.java:40*
)
at org.apache.tuscany.sca.http.jetty.JettyServer.addServletMapping(*
JettyServer.java:200*)
... 7 more
-------------------------------------------------------------------------------------------------------------
Interesting thing is same client(stateless calbback) was running fine with
1.0 incubating jars....
I m using following jars on client side (from 1.1-RC3)....
tuscany-sca-manifest.jar, tuscnay-host-embedded-1.1-incubating.jar,
tuscany-sca-api-1.1-incubating.jar.
I have also created stateful callback service but i hang on my stateless
callback service which was working fine with 1.0 and now creating problem
with 1.1-RC3...
Here for test when i try to run stateful callback client result was
same........
cany anybody help in this.....?
--
Thanks
Nishant Joshi
Re: Problem with stateless (and stateful) Callback Service
Posted by Simon Nash <na...@apache.org>.
Simon Nash wrote:
> Simon Laws wrote:
>> On Jan 23, 2008 11:23 AM, Simon Laws <si...@googlemail.com> wrote:
>>
>>> snip...
>>>
>>>> I have successfully created and tested stateless callback service with
>>>> webapp with Tuscany-1.0.
>>>> Now have a problem with Tuscnay-1.1-RC3......
>>>> My stateless service was deployed in Tomcat as a war(Tomcat was running
>>>> on
>>>> 8080)....
>>>> Now my problem is as below, i got following error on client side when i
>>>> try
>>>> to run my client(stateless callback)....
>>>>
>>>>
>>>> -------------------------------------------------------------------------------------------------------------
>>>>
>>>>
>>>
>>> Hi Nishant
>>>
>>> Can you say something more about the composites you are running and how
>>> you are running them, for example, from the text above it appears
>>> that you
>>> are running a client and a server.
>>>
>>> server = Tomcat on port 8080
>>> composite
>>> component - a component providing a service that will callback
>>> to the
>>> caller
>>>
>>> client = Java application?
>>> composite
>>> component - a component that will talk to the server service and
>>> also
>>> provide a callback service
>>>
>>> I assume you are running both of these on the same machine.
>>>
>>> Assuming that all of this is true and looking at the error trace I would
>>> guess that what is happening is that the SCA runtime is trying to
>>> bring the
>>> client callback service up on Jetty on port 8080, The same port that
>>> Tomcat
>>> is already running on.
>>>
>>> You could confirm this by starting Tomcat on a different port to see
>>> what
>>> happens.
>>>
>>> If this is the case then you could switch to the Node implementation
>>> will
>>> will choose a free port so that this clash doesn't happen. Having
>>> said this
>>> I seem to remember seeing a post about callback binding
>>> configuration. I'll
>>> see if I can find it as it might provide a more straightforward
>>> solution.
>>>
>>> Regards
>>>
>>> Simon
>>>
>>
>> Hi Nishant
>>
>> Firstly did you get past your Net bind exception?
>>
>> As a follow up to this. I've been trying a scenario that is similar to
>> the
>> one you describe and experienced the same kind of problem. I tried first
>> with the default app container that we ship with 1.1 which is Jetty. When
>> this failed I went in and fully specified the URIs on the callback
>> bindings
>> as well as the forward bindings. This still failed with Jetty on the
>> client
>> side. However when I changed over to Tomcat on the client side it
>> worked OK
>> and I see a forward message passing from client to the service running
>> as a
>> webapp in Tomcat which in turn results in a callback passing back to the
>> client.
>>
>> So another thing to try is host-tomcat in place of host-jetty for the
>> client
>> application. The service is still deployed as a webapp in Tomcat.
>>
>> Let me know how you get on.
>>
>> Also it would be useful to have your scenario as a test case for future
>> release. Would you consider contributing it?
>>
>> Regards
>>
>> Simon
>>
> Sorry, I missed this the first time around. Can you post more specific
> details of the scenario (yours, not Nishant's) that fails with 1.1?
> Is it based on one of the existing samples or itests?
>
> Simon
>
I have been trying to recreate the symptoms described by Nishant and
SimonL, but I have not been successful.
My service is packaged in a webapp deployed in Tomcat. My client is
a J2SE client with an embedded web container for the callback. Both
client and server are running in the same machine.
With the host.embedded API in the client, the client fails to start
because port 8080 is in use. This happens with either Jetty or
Tomcat as the embedded client web container.
With the node API in the client, the forward and callback calls are
made OK. This happens with either Jetty or Tomcat as the embedded
client web container.
In all cases, everything is working as I would expect.
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
Re: Problem with stateless (and stateful) Callback Service
Posted by Simon Nash <na...@apache.org>.
Simon Laws wrote:
> On Jan 23, 2008 11:23 AM, Simon Laws <si...@googlemail.com> wrote:
>
>> snip...
>>
>>> I have successfully created and tested stateless callback service with
>>> webapp with Tuscany-1.0.
>>> Now have a problem with Tuscnay-1.1-RC3......
>>> My stateless service was deployed in Tomcat as a war(Tomcat was running
>>> on
>>> 8080)....
>>> Now my problem is as below, i got following error on client side when i
>>> try
>>> to run my client(stateless callback)....
>>>
>>>
>>> -------------------------------------------------------------------------------------------------------------
>>>
>>
>> Hi Nishant
>>
>> Can you say something more about the composites you are running and how
>> you are running them, for example, from the text above it appears that you
>> are running a client and a server.
>>
>> server = Tomcat on port 8080
>> composite
>> component - a component providing a service that will callback to the
>> caller
>>
>> client = Java application?
>> composite
>> component - a component that will talk to the server service and also
>> provide a callback service
>>
>> I assume you are running both of these on the same machine.
>>
>> Assuming that all of this is true and looking at the error trace I would
>> guess that what is happening is that the SCA runtime is trying to bring the
>> client callback service up on Jetty on port 8080, The same port that Tomcat
>> is already running on.
>>
>> You could confirm this by starting Tomcat on a different port to see what
>> happens.
>>
>> If this is the case then you could switch to the Node implementation will
>> will choose a free port so that this clash doesn't happen. Having said this
>> I seem to remember seeing a post about callback binding configuration. I'll
>> see if I can find it as it might provide a more straightforward solution.
>>
>> Regards
>>
>> Simon
>>
>
> Hi Nishant
>
> Firstly did you get past your Net bind exception?
>
> As a follow up to this. I've been trying a scenario that is similar to the
> one you describe and experienced the same kind of problem. I tried first
> with the default app container that we ship with 1.1 which is Jetty. When
> this failed I went in and fully specified the URIs on the callback bindings
> as well as the forward bindings. This still failed with Jetty on the client
> side. However when I changed over to Tomcat on the client side it worked OK
> and I see a forward message passing from client to the service running as a
> webapp in Tomcat which in turn results in a callback passing back to the
> client.
>
> So another thing to try is host-tomcat in place of host-jetty for the client
> application. The service is still deployed as a webapp in Tomcat.
>
> Let me know how you get on.
>
> Also it would be useful to have your scenario as a test case for future
> release. Would you consider contributing it?
>
> Regards
>
> Simon
>
Sorry, I missed this the first time around. Can you post more specific
details of the scenario (yours, not Nishant's) that fails with 1.1?
Is it based on one of the existing samples or itests?
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
Re: Problem with stateless (and stateful) Callback Service
Posted by Simon Laws <si...@googlemail.com>.
On Jan 23, 2008 11:23 AM, Simon Laws <si...@googlemail.com> wrote:
> snip...
>
> >
> > I have successfully created and tested stateless callback service with
> > webapp with Tuscany-1.0.
> > Now have a problem with Tuscnay-1.1-RC3......
> > My stateless service was deployed in Tomcat as a war(Tomcat was running
> > on
> > 8080)....
> > Now my problem is as below, i got following error on client side when i
> > try
> > to run my client(stateless callback)....
> >
> >
> > -------------------------------------------------------------------------------------------------------------
> >
>
>
> Hi Nishant
>
> Can you say something more about the composites you are running and how
> you are running them, for example, from the text above it appears that you
> are running a client and a server.
>
> server = Tomcat on port 8080
> composite
> component - a component providing a service that will callback to the
> caller
>
> client = Java application?
> composite
> component - a component that will talk to the server service and also
> provide a callback service
>
> I assume you are running both of these on the same machine.
>
> Assuming that all of this is true and looking at the error trace I would
> guess that what is happening is that the SCA runtime is trying to bring the
> client callback service up on Jetty on port 8080, The same port that Tomcat
> is already running on.
>
> You could confirm this by starting Tomcat on a different port to see what
> happens.
>
> If this is the case then you could switch to the Node implementation will
> will choose a free port so that this clash doesn't happen. Having said this
> I seem to remember seeing a post about callback binding configuration. I'll
> see if I can find it as it might provide a more straightforward solution.
>
> Regards
>
> Simon
>
Hi Nishant
Firstly did you get past your Net bind exception?
As a follow up to this. I've been trying a scenario that is similar to the
one you describe and experienced the same kind of problem. I tried first
with the default app container that we ship with 1.1 which is Jetty. When
this failed I went in and fully specified the URIs on the callback bindings
as well as the forward bindings. This still failed with Jetty on the client
side. However when I changed over to Tomcat on the client side it worked OK
and I see a forward message passing from client to the service running as a
webapp in Tomcat which in turn results in a callback passing back to the
client.
So another thing to try is host-tomcat in place of host-jetty for the client
application. The service is still deployed as a webapp in Tomcat.
Let me know how you get on.
Also it would be useful to have your scenario as a test case for future
release. Would you consider contributing it?
Regards
Simon
Re: Conversation and Message exchange patterns
Posted by Simon Laws <si...@googlemail.com>.
Hi
Comments in line.
Regards
Simon
On Mon, Mar 17, 2008 at 5:50 PM, James, Steven <st...@logica.com>
wrote:
> Hi Simon,
>
> You are correct in that the standard is a domain standard. In this
> standard we have defined a Layer which is meant to provide
> an abstraction over a transport and wire format. In addition this layer
> supports security and the exchange patterns. It seams that what SCA can
> provide to an implementation is the transport and wire format capabilities,
> in addition to deployment which is not covered by our standard. Therefore, I
> can imagine a service that provides this standard layer using callbacks etc
> to help implement the more complex exchange patterns our real domain
> services will then use this layer. This allows our standard to leverage
> existing standards which provides added value.
Sounds good.
>
>
> With regard to the number of responses this would be the number of
> required responses required for an observation for instance it could require
> 3 or 4 progress messages. We will first be looking at this in Java. For the
> C++ version how big is the runtime and has anyone ever tied embedding it?
The C++ implementation is not very large and it's built on the basis of
using extensions to a core library to provide required function such as
binding and implementation types so you can use just the bits you need. The
C++ implementation is behind the Java implementation at the moment in terms
of features and functions as the community interest seems to be in the Java
camp at the moment. I'm not aware that anyone has embedded it.
>
> I believe that the best way forward is two start to put something basic
> together and start to identify more concretely if there are any issues and
> how we work around them. I will base this on the code you have provided
> aiming first to implement the progress pattern.
>
+1
>
> One more question, when a service is defined does Tuscany provide a
> service definition (Interface contract) regardless of the way the service is
> exposed? i.e. does a HTTP service produce a WSDL file describing the
> service.
Service interfaces in Tuscany SCA can currently be described using either
Java or WSDL. The web services binding will generate a WSDL description for
a service on demand. You can access this by adding ?wsdl to the end of the
service URL. Other bindings will generate service descriptions in other
forms, for example, the JSONRPC binding will generate and SMD file if you
add ?smd to the end of the service URL.
I don't believe the HTTP binding will generate a service description as it
expects that the service interfaces is already know. GET, POST, PUT etc.
However you could get a WSDL description, if one were required, by adding a
web service binding alongside the http binding for the same service and then
use the ?wsdl extension.
>
> Best regards,
>
> Steve.
>
> ________________________________
>
> From: Simon Laws [mailto:simonslaws@googlemail.com]
> Sent: Mon 17/03/2008 16:00
> To: tuscany-user@ws.apache.org
> Subject: Re: Conversation and Message exchange patterns
>
>
>
> Hi Steve
>
> Some more comments in line
>
> Regards
>
> Simon
>
> [1] http://www.mail-archive.com/tuscany-user@ws.apache.org/msg02651.html
> [2]
>
> http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/simple-callback/
>
> On Fri, Mar 14, 2008 at 3:04 PM, James, Steven <st...@logica.com>
> wrote:
>
> > Hi
> >
> > First of may I say that I have been extremely impressed with the support
> > on this forum.
> >
> > Simon, you are correct with the overview of the pattern except that the
> > number of progress messages returned would be configurable.
>
>
> Ok, so there needs to be a service parameter that specifies how many
> callbacks should be made.
>
>
> > I am analysing the use of SCA in the ground segment of a space system.
> > This is to be based on standards being developed.
>
>
> I assume you mean a standard being developed in your application space
> rather than an SCA standard.
>
> These standards require that certain message exchange patterns between a
> > consumer and producer be provided. We will not be using web services so
> we
> > would extend the transport bindings to either use CORBA or TCP/IP
> > communication.
>
>
> Ok there is some more interest in a socket binding here[1]. If you have a
> particular protocol to implement you may need to build an extension along
> the lines of binding.myownprotocol. Or if you are interested in CORBA a
> binding.corba would be good.
>
>
> > The information model for communication is defined in the standard, we
> > will just provide an encoding as the standard does not cover this. I
> have
> > assumed that we can do this within the binding mechanism?
>
>
> We have a databinding extension mechanism that I expect could be used
> here.
> For example, we currently support such databindings as, JAXB, JSON, SDO
> etc
> so you can see that databindings deal with the shape of the data as passed
> across the service interface boundary and across the wire.
>
>
> >
> > With regard to BPEL we would not be interested in this at least for the
> > moment. Main languages used are Java and C++. Both the consumer and
> > provider at least for the time being will all be on the ground although
> they
> > will like be distributed depends on the deployment.
>
>
> OK. are you starting in java or are you starting in C++ or both?
>
>
> >
> > I guess what I am trying to understand is if I can use conversations to
> do
> > this and if so, can you extend the conversation dynamically, as the
> number
> > of our responses are variable, or do we need to develop a new service
> that
> > handles this and then our core services use this. For instance we could
> do
> > this by callbacks over the transport. But I want to get a feel for the
> > extent of work we will need to do or if we just start from scratch. The
> MEP
> > is one of 5 but this is the most complicated to provide hence my
> interest in
> > this.
>
>
> I'm not clear what you mean by "the number of our responses are variable".
> Is that the number of callbacks that have to be made are variable or the
> number of targets that the response must go to or something else?
>
> Generally conversational semantics are designed for the case where
> multiple
> calls to a service must be correlated. In your particular case it seems
> that
> using SCA callback semantics would be sufficient. I.e. A sends a message
> to
> B and then B sends one or more callbacks.
>
> For example, with callbacks we could defined the following interfaces.
>
> Firstly an interface for the service that provides a @OneWay asynchronous
> operation and describes the callback interface that it will use.
>
> @Callback(MyServiceCallback.class)
> public interface MyService {
>
> @OneWay
> void doRequest(String arg);
> }
>
> Then the callback interface that the client will use.
>
> public interface MyServiceCallback {
>
> void doCallback(String result);
> }
>
> The components could then be assembled using something like
>
> <composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
> targetNamespace="http://simplecallback <http://simplecallback/> "
> xmlns:cb="http://simplecallback <http://simplecallback/> "
> name="simplecallback">
>
> <component name="MyClientComponent">
> <implementation.java class="simplecallback.MyClientImpl"/>
> <reference name="myService" target="MyServiceComponent"/>
> </component>
>
> <component name="MyServiceComponent">
> <implementation.java class="simplecallback.MyServiceImpl"/>
> </component>
>
> </composite>
>
> I took these interfaces from samples/simple-callback [2] (Although I
> tweaked
> the method names here for effect :-) so you can see how the
> implementations
> would use these interfaces by looking there.
>
> If this looks like the right kind of thing then we can discuss this in
> more
> detail, for example, we could talk about how callbacks are correlated and
> how the number of callbacks could be configured, etc
>
> If this doesn't fit what you've been thinking let's discuss.
>
>
> >
> > Regards,
> >
> > Steve.
> >
> > ________________________________
> >
> > From: Simon Laws [mailto:simonslaws@googlemail.com]
> > Sent: Thu 13/03/2008 23:00
> > To: tuscany-user@ws.apache.org
> > Subject: Re: Conversation and Message exchange patterns
> >
> >
> >
> > Yep, I believe it's right that Tuscany's implementation.bpel doesn't
> > support
> > callback, conversation etc.
> >
> > Can you say a litte more about what you mean about achieving the same
> > using
> > pure web services. If the services are written outside of the context of
> > the
> > Tuscany runtime them it is up the the service implementation to provide
> > some
> > callback and/or conversation protocol. If you mean is it possible to
> > callback to a web service that is outside the tuscany runtime
> environment
> > then that may work by explicitly setting the callback binding details
> but
> > I'd have to test if. If nothing else you could specify a remote
> reference
> > with a web services binding and use that as the callback target from
> > within
> > you service code. Sorry this is not a very precise answer. Maybe you
> could
> > say a little more about your scenario
> >
> > Regards
> >
> > Simon
> >
> > On Thu, Mar 13, 2008 at 7:59 PM, Jean-Jacques Dubray <jd...@gmail.com>
> > wrote:
> >
> > > Simon:
> > >
> > > my understanding is that it cannot be done with BPEL yet.
> > >
> > > Do you know if this can be achieved with pure Web Services (regardless
> > of
> > > whether they have been written in Java or not).
> > >
> > > JJ-
> > >
> > > On Thu, Mar 13, 2008 at 12:05 PM, Simon Laws <
> simonslaws@googlemail.com>
> > > wrote:
> > >
> > > > On Wed, Mar 12, 2008 at 3:35 PM, James, Steven <
> > steven.james@logica.com>
> > > > wrote:
> > > >
> > > > > We are investigating using SCA and are trying to understand if SCA
> > > could
> > > > > support complex Message exchange patterns (MEP's). What I mean by
> > MEP
> > > is
> > > > > similar to those defined by WSDL 2.0 i.e. In-out Out-Only etc.
> > > > >
> > > > > I have been looking at the conversation capabilities of SCA and am
> > > > > starting to think we could create our message patterns using this
> > > > mechanism.
> > > > > The types of pattern we are intrested in are for instance the
> > ability
> > > to
> > > > > make a request and then get a configurable number of progress
> > updates.
> > > > Is
> > > > > this possible using conversations? in addition is there any
> language
> > > or
> > > > > transport constraints to this?
> > > > >
> > > > > Best regards,
> > > > >
> > > > > Steve.
> > > > >
> > > > >
> > > > > This e-mail and any attachment is for authorised use by the
> intended
> > > > > recipient(s) only. It may contain proprietary material,
> confidential
> > > > > information and/or be subject to legal privilege. It should not be
> > > > copied,
> > > > > disclosed to, retained or used by, any other party. If you are not
> > an
> > > > > intended recipient then please promptly delete this e-mail and any
> > > > > attachment and all copies and inform the sender. Thank you.
> > > > >
> > > > >
> > > > >
> > > > >
> > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > > > >
> > > > Hi Steve
> > > >
> > > > Welcome to Tuscany!
> > > >
> > > > Let me make sure I have your scenario correct then we can work up
> some
> > > > sample interface together for how to make it work. So IIUC you have
> > > > service
> > > > A and service B and they call each other as follows:
> > > >
> > > > A calls B.doSomething asynchronously
> > > > B calls A.progressReport
> > > > B calls A.progressReport
> > > > B calls A.progressReport
> > > >
> > > > The progress reports stops after a set number have been delivered?
> > > >
> > > > On the "language or transport constraints to this" point. The
> general
> > > > support for conversations, callbacks etc is good for Java over the
> SCA
> > > and
> > > > WebServices bindings. I don't think other languages/transports have
> > been
> > > > addressed but I'm sure someone will jump in and correct me.
> > > >
> > > > Regards
> > > >
> > > > Simon
> > > >
> > >
> > >
> > >
> > > --
> > > Jean-Jacques Dubray
> > > 425-445-4467
> > >
> >
> >
> >
> >
> > This e-mail and any attachment is for authorised use by the intended
> > recipient(s) only. It may contain proprietary material, confidential
> > information and/or be subject to legal privilege. It should not be
> copied,
> > disclosed to, retained or used by, any other party. If you are not an
> > intended recipient then please promptly delete this e-mail and any
> > attachment and all copies and inform the sender. Thank you.
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> >
>
>
>
>
> This e-mail and any attachment is for authorised use by the intended
> recipient(s) only. It may contain proprietary material, confidential
> information and/or be subject to legal privilege. It should not be copied,
> disclosed to, retained or used by, any other party. If you are not an
> intended recipient then please promptly delete this e-mail and any
> attachment and all copies and inform the sender. Thank you.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
RE: Conversation and Message exchange patterns
Posted by "James, Steven" <st...@logica.com>.
Hi Simon,
You are correct in that the standard is a domain standard. In this standard we have defined a Layer which is meant to provide
an abstraction over a transport and wire format. In addition this layer supports security and the exchange patterns. It seams that what SCA can provide to an implementation is the transport and wire format capabilities, in addition to deployment which is not covered by our standard. Therefore, I can imagine a service that provides this standard layer using callbacks etc to help implement the more complex exchange patterns our real domain services will then use this layer. This allows our standard to leverage existing standards which provides added value.
With regard to the number of responses this would be the number of required responses required for an observation for instance it could require 3 or 4 progress messages. We will first be looking at this in Java. For the C++ version how big is the runtime and has anyone ever tied embedding it?
I believe that the best way forward is two start to put something basic together and start to identify more concretely if there are any issues and how we work around them. I will base this on the code you have provided aiming first to implement the progress pattern.
One more question, when a service is defined does Tuscany provide a service definition (Interface contract) regardless of the way the service is exposed? i.e. does a HTTP service produce a WSDL file describing the service.
Best regards,
Steve.
________________________________
From: Simon Laws [mailto:simonslaws@googlemail.com]
Sent: Mon 17/03/2008 16:00
To: tuscany-user@ws.apache.org
Subject: Re: Conversation and Message exchange patterns
Hi Steve
Some more comments in line
Regards
Simon
[1] http://www.mail-archive.com/tuscany-user@ws.apache.org/msg02651.html
[2]
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/simple-callback/
On Fri, Mar 14, 2008 at 3:04 PM, James, Steven <st...@logica.com>
wrote:
> Hi
>
> First of may I say that I have been extremely impressed with the support
> on this forum.
>
> Simon, you are correct with the overview of the pattern except that the
> number of progress messages returned would be configurable.
Ok, so there needs to be a service parameter that specifies how many
callbacks should be made.
> I am analysing the use of SCA in the ground segment of a space system.
> This is to be based on standards being developed.
I assume you mean a standard being developed in your application space
rather than an SCA standard.
These standards require that certain message exchange patterns between a
> consumer and producer be provided. We will not be using web services so we
> would extend the transport bindings to either use CORBA or TCP/IP
> communication.
Ok there is some more interest in a socket binding here[1]. If you have a
particular protocol to implement you may need to build an extension along
the lines of binding.myownprotocol. Or if you are interested in CORBA a
binding.corba would be good.
> The information model for communication is defined in the standard, we
> will just provide an encoding as the standard does not cover this. I have
> assumed that we can do this within the binding mechanism?
We have a databinding extension mechanism that I expect could be used here.
For example, we currently support such databindings as, JAXB, JSON, SDO etc
so you can see that databindings deal with the shape of the data as passed
across the service interface boundary and across the wire.
>
> With regard to BPEL we would not be interested in this at least for the
> moment. Main languages used are Java and C++. Both the consumer and
> provider at least for the time being will all be on the ground although they
> will like be distributed depends on the deployment.
OK. are you starting in java or are you starting in C++ or both?
>
> I guess what I am trying to understand is if I can use conversations to do
> this and if so, can you extend the conversation dynamically, as the number
> of our responses are variable, or do we need to develop a new service that
> handles this and then our core services use this. For instance we could do
> this by callbacks over the transport. But I want to get a feel for the
> extent of work we will need to do or if we just start from scratch. The MEP
> is one of 5 but this is the most complicated to provide hence my interest in
> this.
I'm not clear what you mean by "the number of our responses are variable".
Is that the number of callbacks that have to be made are variable or the
number of targets that the response must go to or something else?
Generally conversational semantics are designed for the case where multiple
calls to a service must be correlated. In your particular case it seems that
using SCA callback semantics would be sufficient. I.e. A sends a message to
B and then B sends one or more callbacks.
For example, with callbacks we could defined the following interfaces.
Firstly an interface for the service that provides a @OneWay asynchronous
operation and describes the callback interface that it will use.
@Callback(MyServiceCallback.class)
public interface MyService {
@OneWay
void doRequest(String arg);
}
Then the callback interface that the client will use.
public interface MyServiceCallback {
void doCallback(String result);
}
The components could then be assembled using something like
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
targetNamespace="http://simplecallback <http://simplecallback/> "
xmlns:cb="http://simplecallback <http://simplecallback/> "
name="simplecallback">
<component name="MyClientComponent">
<implementation.java class="simplecallback.MyClientImpl"/>
<reference name="myService" target="MyServiceComponent"/>
</component>
<component name="MyServiceComponent">
<implementation.java class="simplecallback.MyServiceImpl"/>
</component>
</composite>
I took these interfaces from samples/simple-callback [2] (Although I tweaked
the method names here for effect :-) so you can see how the implementations
would use these interfaces by looking there.
If this looks like the right kind of thing then we can discuss this in more
detail, for example, we could talk about how callbacks are correlated and
how the number of callbacks could be configured, etc
If this doesn't fit what you've been thinking let's discuss.
>
> Regards,
>
> Steve.
>
> ________________________________
>
> From: Simon Laws [mailto:simonslaws@googlemail.com]
> Sent: Thu 13/03/2008 23:00
> To: tuscany-user@ws.apache.org
> Subject: Re: Conversation and Message exchange patterns
>
>
>
> Yep, I believe it's right that Tuscany's implementation.bpel doesn't
> support
> callback, conversation etc.
>
> Can you say a litte more about what you mean about achieving the same
> using
> pure web services. If the services are written outside of the context of
> the
> Tuscany runtime them it is up the the service implementation to provide
> some
> callback and/or conversation protocol. If you mean is it possible to
> callback to a web service that is outside the tuscany runtime environment
> then that may work by explicitly setting the callback binding details but
> I'd have to test if. If nothing else you could specify a remote reference
> with a web services binding and use that as the callback target from
> within
> you service code. Sorry this is not a very precise answer. Maybe you could
> say a little more about your scenario
>
> Regards
>
> Simon
>
> On Thu, Mar 13, 2008 at 7:59 PM, Jean-Jacques Dubray <jd...@gmail.com>
> wrote:
>
> > Simon:
> >
> > my understanding is that it cannot be done with BPEL yet.
> >
> > Do you know if this can be achieved with pure Web Services (regardless
> of
> > whether they have been written in Java or not).
> >
> > JJ-
> >
> > On Thu, Mar 13, 2008 at 12:05 PM, Simon Laws <si...@googlemail.com>
> > wrote:
> >
> > > On Wed, Mar 12, 2008 at 3:35 PM, James, Steven <
> steven.james@logica.com>
> > > wrote:
> > >
> > > > We are investigating using SCA and are trying to understand if SCA
> > could
> > > > support complex Message exchange patterns (MEP's). What I mean by
> MEP
> > is
> > > > similar to those defined by WSDL 2.0 i.e. In-out Out-Only etc.
> > > >
> > > > I have been looking at the conversation capabilities of SCA and am
> > > > starting to think we could create our message patterns using this
> > > mechanism.
> > > > The types of pattern we are intrested in are for instance the
> ability
> > to
> > > > make a request and then get a configurable number of progress
> updates.
> > > Is
> > > > this possible using conversations? in addition is there any language
> > or
> > > > transport constraints to this?
> > > >
> > > > Best regards,
> > > >
> > > > Steve.
> > > >
> > > >
> > > > This e-mail and any attachment is for authorised use by the intended
> > > > recipient(s) only. It may contain proprietary material, confidential
> > > > information and/or be subject to legal privilege. It should not be
> > > copied,
> > > > disclosed to, retained or used by, any other party. If you are not
> an
> > > > intended recipient then please promptly delete this e-mail and any
> > > > attachment and all copies and inform the sender. Thank you.
> > > >
> > > >
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > > >
> > > Hi Steve
> > >
> > > Welcome to Tuscany!
> > >
> > > Let me make sure I have your scenario correct then we can work up some
> > > sample interface together for how to make it work. So IIUC you have
> > > service
> > > A and service B and they call each other as follows:
> > >
> > > A calls B.doSomething asynchronously
> > > B calls A.progressReport
> > > B calls A.progressReport
> > > B calls A.progressReport
> > >
> > > The progress reports stops after a set number have been delivered?
> > >
> > > On the "language or transport constraints to this" point. The general
> > > support for conversations, callbacks etc is good for Java over the SCA
> > and
> > > WebServices bindings. I don't think other languages/transports have
> been
> > > addressed but I'm sure someone will jump in and correct me.
> > >
> > > Regards
> > >
> > > Simon
> > >
> >
> >
> >
> > --
> > Jean-Jacques Dubray
> > 425-445-4467
> >
>
>
>
>
> This e-mail and any attachment is for authorised use by the intended
> recipient(s) only. It may contain proprietary material, confidential
> information and/or be subject to legal privilege. It should not be copied,
> disclosed to, retained or used by, any other party. If you are not an
> intended recipient then please promptly delete this e-mail and any
> attachment and all copies and inform the sender. Thank you.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
Re: Conversation and Message exchange patterns
Posted by Simon Laws <si...@googlemail.com>.
Hi Steve
Some more comments in line
Regards
Simon
[1] http://www.mail-archive.com/tuscany-user@ws.apache.org/msg02651.html
[2]
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/simple-callback/
On Fri, Mar 14, 2008 at 3:04 PM, James, Steven <st...@logica.com>
wrote:
> Hi
>
> First of may I say that I have been extremely impressed with the support
> on this forum.
>
> Simon, you are correct with the overview of the pattern except that the
> number of progress messages returned would be configurable.
Ok, so there needs to be a service parameter that specifies how many
callbacks should be made.
> I am analysing the use of SCA in the ground segment of a space system.
> This is to be based on standards being developed.
I assume you mean a standard being developed in your application space
rather than an SCA standard.
These standards require that certain message exchange patterns between a
> consumer and producer be provided. We will not be using web services so we
> would extend the transport bindings to either use CORBA or TCP/IP
> communication.
Ok there is some more interest in a socket binding here[1]. If you have a
particular protocol to implement you may need to build an extension along
the lines of binding.myownprotocol. Or if you are interested in CORBA a
binding.corba would be good.
> The information model for communication is defined in the standard, we
> will just provide an encoding as the standard does not cover this. I have
> assumed that we can do this within the binding mechanism?
We have a databinding extension mechanism that I expect could be used here.
For example, we currently support such databindings as, JAXB, JSON, SDO etc
so you can see that databindings deal with the shape of the data as passed
across the service interface boundary and across the wire.
>
> With regard to BPEL we would not be interested in this at least for the
> moment. Main languages used are Java and C++. Both the consumer and
> provider at least for the time being will all be on the ground although they
> will like be distributed depends on the deployment.
OK. are you starting in java or are you starting in C++ or both?
>
> I guess what I am trying to understand is if I can use conversations to do
> this and if so, can you extend the conversation dynamically, as the number
> of our responses are variable, or do we need to develop a new service that
> handles this and then our core services use this. For instance we could do
> this by callbacks over the transport. But I want to get a feel for the
> extent of work we will need to do or if we just start from scratch. The MEP
> is one of 5 but this is the most complicated to provide hence my interest in
> this.
I'm not clear what you mean by "the number of our responses are variable".
Is that the number of callbacks that have to be made are variable or the
number of targets that the response must go to or something else?
Generally conversational semantics are designed for the case where multiple
calls to a service must be correlated. In your particular case it seems that
using SCA callback semantics would be sufficient. I.e. A sends a message to
B and then B sends one or more callbacks.
For example, with callbacks we could defined the following interfaces.
Firstly an interface for the service that provides a @OneWay asynchronous
operation and describes the callback interface that it will use.
@Callback(MyServiceCallback.class)
public interface MyService {
@OneWay
void doRequest(String arg);
}
Then the callback interface that the client will use.
public interface MyServiceCallback {
void doCallback(String result);
}
The components could then be assembled using something like
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
targetNamespace="http://simplecallback"
xmlns:cb="http://simplecallback"
name="simplecallback">
<component name="MyClientComponent">
<implementation.java class="simplecallback.MyClientImpl"/>
<reference name="myService" target="MyServiceComponent"/>
</component>
<component name="MyServiceComponent">
<implementation.java class="simplecallback.MyServiceImpl"/>
</component>
</composite>
I took these interfaces from samples/simple-callback [2] (Although I tweaked
the method names here for effect :-) so you can see how the implementations
would use these interfaces by looking there.
If this looks like the right kind of thing then we can discuss this in more
detail, for example, we could talk about how callbacks are correlated and
how the number of callbacks could be configured, etc
If this doesn't fit what you've been thinking let's discuss.
>
> Regards,
>
> Steve.
>
> ________________________________
>
> From: Simon Laws [mailto:simonslaws@googlemail.com]
> Sent: Thu 13/03/2008 23:00
> To: tuscany-user@ws.apache.org
> Subject: Re: Conversation and Message exchange patterns
>
>
>
> Yep, I believe it's right that Tuscany's implementation.bpel doesn't
> support
> callback, conversation etc.
>
> Can you say a litte more about what you mean about achieving the same
> using
> pure web services. If the services are written outside of the context of
> the
> Tuscany runtime them it is up the the service implementation to provide
> some
> callback and/or conversation protocol. If you mean is it possible to
> callback to a web service that is outside the tuscany runtime environment
> then that may work by explicitly setting the callback binding details but
> I'd have to test if. If nothing else you could specify a remote reference
> with a web services binding and use that as the callback target from
> within
> you service code. Sorry this is not a very precise answer. Maybe you could
> say a little more about your scenario
>
> Regards
>
> Simon
>
> On Thu, Mar 13, 2008 at 7:59 PM, Jean-Jacques Dubray <jd...@gmail.com>
> wrote:
>
> > Simon:
> >
> > my understanding is that it cannot be done with BPEL yet.
> >
> > Do you know if this can be achieved with pure Web Services (regardless
> of
> > whether they have been written in Java or not).
> >
> > JJ-
> >
> > On Thu, Mar 13, 2008 at 12:05 PM, Simon Laws <si...@googlemail.com>
> > wrote:
> >
> > > On Wed, Mar 12, 2008 at 3:35 PM, James, Steven <
> steven.james@logica.com>
> > > wrote:
> > >
> > > > We are investigating using SCA and are trying to understand if SCA
> > could
> > > > support complex Message exchange patterns (MEP's). What I mean by
> MEP
> > is
> > > > similar to those defined by WSDL 2.0 i.e. In-out Out-Only etc.
> > > >
> > > > I have been looking at the conversation capabilities of SCA and am
> > > > starting to think we could create our message patterns using this
> > > mechanism.
> > > > The types of pattern we are intrested in are for instance the
> ability
> > to
> > > > make a request and then get a configurable number of progress
> updates.
> > > Is
> > > > this possible using conversations? in addition is there any language
> > or
> > > > transport constraints to this?
> > > >
> > > > Best regards,
> > > >
> > > > Steve.
> > > >
> > > >
> > > > This e-mail and any attachment is for authorised use by the intended
> > > > recipient(s) only. It may contain proprietary material, confidential
> > > > information and/or be subject to legal privilege. It should not be
> > > copied,
> > > > disclosed to, retained or used by, any other party. If you are not
> an
> > > > intended recipient then please promptly delete this e-mail and any
> > > > attachment and all copies and inform the sender. Thank you.
> > > >
> > > >
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > > >
> > > Hi Steve
> > >
> > > Welcome to Tuscany!
> > >
> > > Let me make sure I have your scenario correct then we can work up some
> > > sample interface together for how to make it work. So IIUC you have
> > > service
> > > A and service B and they call each other as follows:
> > >
> > > A calls B.doSomething asynchronously
> > > B calls A.progressReport
> > > B calls A.progressReport
> > > B calls A.progressReport
> > >
> > > The progress reports stops after a set number have been delivered?
> > >
> > > On the "language or transport constraints to this" point. The general
> > > support for conversations, callbacks etc is good for Java over the SCA
> > and
> > > WebServices bindings. I don't think other languages/transports have
> been
> > > addressed but I'm sure someone will jump in and correct me.
> > >
> > > Regards
> > >
> > > Simon
> > >
> >
> >
> >
> > --
> > Jean-Jacques Dubray
> > 425-445-4467
> >
>
>
>
>
> This e-mail and any attachment is for authorised use by the intended
> recipient(s) only. It may contain proprietary material, confidential
> information and/or be subject to legal privilege. It should not be copied,
> disclosed to, retained or used by, any other party. If you are not an
> intended recipient then please promptly delete this e-mail and any
> attachment and all copies and inform the sender. Thank you.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
RE: Conversation and Message exchange patterns
Posted by "James, Steven" <st...@logica.com>.
Hi
First of may I say that I have been extremely impressed with the support on this forum.
Simon, you are correct with the overview of the pattern except that the number of progress messages returned would be configurable.
I am analysing the use of SCA in the ground segment of a space system. This is to be based on standards being developed. These standards require that certain message exchange patterns between a consumer and producer be provided. We will not be using web services so we would extend the transport bindings to either use CORBA or TCP/IP communication. The information model for communication is defined in the standard, we will just provide an encoding as the standard does not cover this. I have assumed that we can do this within the binding mechanism?
With regard to BPEL we would not be interested in this at least for the moment. Main languages used are Java and C++. Both the consumer and provider at least for the time being will all be on the ground although they will like be distributed depends on the deployment.
I guess what I am trying to understand is if I can use conversations to do this and if so, can you extend the conversation dynamically, as the number of our responses are variable, or do we need to develop a new service that handles this and then our core services use this. For instance we could do this by callbacks over the transport. But I want to get a feel for the extent of work we will need to do or if we just start from scratch. The MEP is one of 5 but this is the most complicated to provide hence my interest in this.
Regards,
Steve.
________________________________
From: Simon Laws [mailto:simonslaws@googlemail.com]
Sent: Thu 13/03/2008 23:00
To: tuscany-user@ws.apache.org
Subject: Re: Conversation and Message exchange patterns
Yep, I believe it's right that Tuscany's implementation.bpel doesn't support
callback, conversation etc.
Can you say a litte more about what you mean about achieving the same using
pure web services. If the services are written outside of the context of the
Tuscany runtime them it is up the the service implementation to provide some
callback and/or conversation protocol. If you mean is it possible to
callback to a web service that is outside the tuscany runtime environment
then that may work by explicitly setting the callback binding details but
I'd have to test if. If nothing else you could specify a remote reference
with a web services binding and use that as the callback target from within
you service code. Sorry this is not a very precise answer. Maybe you could
say a little more about your scenario
Regards
Simon
On Thu, Mar 13, 2008 at 7:59 PM, Jean-Jacques Dubray <jd...@gmail.com>
wrote:
> Simon:
>
> my understanding is that it cannot be done with BPEL yet.
>
> Do you know if this can be achieved with pure Web Services (regardless of
> whether they have been written in Java or not).
>
> JJ-
>
> On Thu, Mar 13, 2008 at 12:05 PM, Simon Laws <si...@googlemail.com>
> wrote:
>
> > On Wed, Mar 12, 2008 at 3:35 PM, James, Steven <st...@logica.com>
> > wrote:
> >
> > > We are investigating using SCA and are trying to understand if SCA
> could
> > > support complex Message exchange patterns (MEP's). What I mean by MEP
> is
> > > similar to those defined by WSDL 2.0 i.e. In-out Out-Only etc.
> > >
> > > I have been looking at the conversation capabilities of SCA and am
> > > starting to think we could create our message patterns using this
> > mechanism.
> > > The types of pattern we are intrested in are for instance the ability
> to
> > > make a request and then get a configurable number of progress updates.
> > Is
> > > this possible using conversations? in addition is there any language
> or
> > > transport constraints to this?
> > >
> > > Best regards,
> > >
> > > Steve.
> > >
> > >
> > > This e-mail and any attachment is for authorised use by the intended
> > > recipient(s) only. It may contain proprietary material, confidential
> > > information and/or be subject to legal privilege. It should not be
> > copied,
> > > disclosed to, retained or used by, any other party. If you are not an
> > > intended recipient then please promptly delete this e-mail and any
> > > attachment and all copies and inform the sender. Thank you.
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > >
> > Hi Steve
> >
> > Welcome to Tuscany!
> >
> > Let me make sure I have your scenario correct then we can work up some
> > sample interface together for how to make it work. So IIUC you have
> > service
> > A and service B and they call each other as follows:
> >
> > A calls B.doSomething asynchronously
> > B calls A.progressReport
> > B calls A.progressReport
> > B calls A.progressReport
> >
> > The progress reports stops after a set number have been delivered?
> >
> > On the "language or transport constraints to this" point. The general
> > support for conversations, callbacks etc is good for Java over the SCA
> and
> > WebServices bindings. I don't think other languages/transports have been
> > addressed but I'm sure someone will jump in and correct me.
> >
> > Regards
> >
> > Simon
> >
>
>
>
> --
> Jean-Jacques Dubray
> 425-445-4467
>
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
Re: Conversation and Message exchange patterns
Posted by Simon Laws <si...@googlemail.com>.
Yep, I believe it's right that Tuscany's implementation.bpel doesn't support
callback, conversation etc.
Can you say a litte more about what you mean about achieving the same using
pure web services. If the services are written outside of the context of the
Tuscany runtime them it is up the the service implementation to provide some
callback and/or conversation protocol. If you mean is it possible to
callback to a web service that is outside the tuscany runtime environment
then that may work by explicitly setting the callback binding details but
I'd have to test if. If nothing else you could specify a remote reference
with a web services binding and use that as the callback target from within
you service code. Sorry this is not a very precise answer. Maybe you could
say a little more about your scenario
Regards
Simon
On Thu, Mar 13, 2008 at 7:59 PM, Jean-Jacques Dubray <jd...@gmail.com>
wrote:
> Simon:
>
> my understanding is that it cannot be done with BPEL yet.
>
> Do you know if this can be achieved with pure Web Services (regardless of
> whether they have been written in Java or not).
>
> JJ-
>
> On Thu, Mar 13, 2008 at 12:05 PM, Simon Laws <si...@googlemail.com>
> wrote:
>
> > On Wed, Mar 12, 2008 at 3:35 PM, James, Steven <st...@logica.com>
> > wrote:
> >
> > > We are investigating using SCA and are trying to understand if SCA
> could
> > > support complex Message exchange patterns (MEP's). What I mean by MEP
> is
> > > similar to those defined by WSDL 2.0 i.e. In-out Out-Only etc.
> > >
> > > I have been looking at the conversation capabilities of SCA and am
> > > starting to think we could create our message patterns using this
> > mechanism.
> > > The types of pattern we are intrested in are for instance the ability
> to
> > > make a request and then get a configurable number of progress updates.
> > Is
> > > this possible using conversations? in addition is there any language
> or
> > > transport constraints to this?
> > >
> > > Best regards,
> > >
> > > Steve.
> > >
> > >
> > > This e-mail and any attachment is for authorised use by the intended
> > > recipient(s) only. It may contain proprietary material, confidential
> > > information and/or be subject to legal privilege. It should not be
> > copied,
> > > disclosed to, retained or used by, any other party. If you are not an
> > > intended recipient then please promptly delete this e-mail and any
> > > attachment and all copies and inform the sender. Thank you.
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > >
> > Hi Steve
> >
> > Welcome to Tuscany!
> >
> > Let me make sure I have your scenario correct then we can work up some
> > sample interface together for how to make it work. So IIUC you have
> > service
> > A and service B and they call each other as follows:
> >
> > A calls B.doSomething asynchronously
> > B calls A.progressReport
> > B calls A.progressReport
> > B calls A.progressReport
> >
> > The progress reports stops after a set number have been delivered?
> >
> > On the "language or transport constraints to this" point. The general
> > support for conversations, callbacks etc is good for Java over the SCA
> and
> > WebServices bindings. I don't think other languages/transports have been
> > addressed but I'm sure someone will jump in and correct me.
> >
> > Regards
> >
> > Simon
> >
>
>
>
> --
> Jean-Jacques Dubray
> 425-445-4467
>
Re: Conversation and Message exchange patterns
Posted by Jean-Jacques Dubray <jd...@gmail.com>.
Simon:
my understanding is that it cannot be done with BPEL yet.
Do you know if this can be achieved with pure Web Services (regardless of
whether they have been written in Java or not).
JJ-
On Thu, Mar 13, 2008 at 12:05 PM, Simon Laws <si...@googlemail.com>
wrote:
> On Wed, Mar 12, 2008 at 3:35 PM, James, Steven <st...@logica.com>
> wrote:
>
> > We are investigating using SCA and are trying to understand if SCA could
> > support complex Message exchange patterns (MEP's). What I mean by MEP is
> > similar to those defined by WSDL 2.0 i.e. In-out Out-Only etc.
> >
> > I have been looking at the conversation capabilities of SCA and am
> > starting to think we could create our message patterns using this
> mechanism.
> > The types of pattern we are intrested in are for instance the ability to
> > make a request and then get a configurable number of progress updates.
> Is
> > this possible using conversations? in addition is there any language or
> > transport constraints to this?
> >
> > Best regards,
> >
> > Steve.
> >
> >
> > This e-mail and any attachment is for authorised use by the intended
> > recipient(s) only. It may contain proprietary material, confidential
> > information and/or be subject to legal privilege. It should not be
> copied,
> > disclosed to, retained or used by, any other party. If you are not an
> > intended recipient then please promptly delete this e-mail and any
> > attachment and all copies and inform the sender. Thank you.
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> >
> Hi Steve
>
> Welcome to Tuscany!
>
> Let me make sure I have your scenario correct then we can work up some
> sample interface together for how to make it work. So IIUC you have
> service
> A and service B and they call each other as follows:
>
> A calls B.doSomething asynchronously
> B calls A.progressReport
> B calls A.progressReport
> B calls A.progressReport
>
> The progress reports stops after a set number have been delivered?
>
> On the "language or transport constraints to this" point. The general
> support for conversations, callbacks etc is good for Java over the SCA and
> WebServices bindings. I don't think other languages/transports have been
> addressed but I'm sure someone will jump in and correct me.
>
> Regards
>
> Simon
>
--
Jean-Jacques Dubray
425-445-4467
Re: Conversation and Message exchange patterns
Posted by Simon Laws <si...@googlemail.com>.
On Wed, Mar 12, 2008 at 3:35 PM, James, Steven <st...@logica.com>
wrote:
> We are investigating using SCA and are trying to understand if SCA could
> support complex Message exchange patterns (MEP's). What I mean by MEP is
> similar to those defined by WSDL 2.0 i.e. In-out Out-Only etc.
>
> I have been looking at the conversation capabilities of SCA and am
> starting to think we could create our message patterns using this mechanism.
> The types of pattern we are intrested in are for instance the ability to
> make a request and then get a configurable number of progress updates. Is
> this possible using conversations? in addition is there any language or
> transport constraints to this?
>
> Best regards,
>
> Steve.
>
>
> This e-mail and any attachment is for authorised use by the intended
> recipient(s) only. It may contain proprietary material, confidential
> information and/or be subject to legal privilege. It should not be copied,
> disclosed to, retained or used by, any other party. If you are not an
> intended recipient then please promptly delete this e-mail and any
> attachment and all copies and inform the sender. Thank you.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
Hi Steve
Welcome to Tuscany!
Let me make sure I have your scenario correct then we can work up some
sample interface together for how to make it work. So IIUC you have service
A and service B and they call each other as follows:
A calls B.doSomething asynchronously
B calls A.progressReport
B calls A.progressReport
B calls A.progressReport
The progress reports stops after a set number have been delivered?
On the "language or transport constraints to this" point. The general
support for conversations, callbacks etc is good for Java over the SCA and
WebServices bindings. I don't think other languages/transports have been
addressed but I'm sure someone will jump in and correct me.
Regards
Simon
Conversation and Message exchange patterns
Posted by "James, Steven" <st...@logica.com>.
We are investigating using SCA and are trying to understand if SCA could support complex Message exchange patterns (MEP's). What I mean by MEP is similar to those defined by WSDL 2.0 i.e. In-out Out-Only etc.
I have been looking at the conversation capabilities of SCA and am starting to think we could create our message patterns using this mechanism. The types of pattern we are intrested in are for instance the ability to make a request and then get a configurable number of progress updates. Is this possible using conversations? in addition is there any language or transport constraints to this?
Best regards,
Steve.
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
Re: Problem with stateless (and stateful) Callback Service
Posted by Simon Laws <si...@googlemail.com>.
snip...
>
> I have successfully created and tested stateless callback service with
> webapp with Tuscany-1.0.
> Now have a problem with Tuscnay-1.1-RC3......
> My stateless service was deployed in Tomcat as a war(Tomcat was running on
> 8080)....
> Now my problem is as below, i got following error on client side when i
> try
> to run my client(stateless callback)....
>
>
> -------------------------------------------------------------------------------------------------------------
>
Hi Nishant
Can you say something more about the composites you are running and how you
are running them, for example, from the text above it appears that you are
running a client and a server.
server = Tomcat on port 8080
composite
component - a component providing a service that will callback to the
caller
client = Java application?
composite
component - a component that will talk to the server service and also
provide a callback service
I assume you are running both of these on the same machine.
Assuming that all of this is true and looking at the error trace I would
guess that what is happening is that the SCA runtime is trying to bring the
client callback service up on Jetty on port 8080, The same port that Tomcat
is already running on.
You could confirm this by starting Tomcat on a different port to see what
happens.
If this is the case then you could switch to the Node implementation will
will choose a free port so that this clash doesn't happen. Having said this
I seem to remember seeing a post about callback binding configuration. I'll
see if I can find it as it might provide a more straightforward solution.
Regards
Simon