Hi Comments in line.
Regards Simon On Mon, Mar 17, 2008 at 5:50 PM, James, Steven <[EMAIL PROTECTED]> 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:[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] >
