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:[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > 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 <[EMAIL PROTECTED]> > 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 <[EMAIL PROTECTED]> > > wrote: > > > > > On Wed, Mar 12, 2008 at 3:35 PM, James, Steven < > [EMAIL PROTECTED]> > > > 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: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
