Hi Raymond, But what would happen if the JAXB classes would be handled as POJOs? Wouldn't it work anyway? My understanding is that the actual communication would be exchanging XMLs which do not fully comply with a specific schema, but wouldn't the objects get deserialized to proper JAXB classes on server anyway?
Thanks, Radim On 8/8/07, Raymond Feng <[EMAIL PROTECTED]> wrote: > Comments line. > > Thanks, > Raymond > > ----- Original Message ----- > From: "Radim Kolarik" <[EMAIL PROTECTED]> > To: <tuscany-user@ws.apache.org>; <[EMAIL PROTECTED]> > Sent: Wednesday, August 08, 2007 4:16 AM > Subject: Re: Services and WSDL files > > > > Hi Ant, > > > > That is great news! Thanks! > > > > It's just POJOs and possibly JAXB objects as well for now. Is there > > any difference between POJOs and JAXB objects, regarding WSDL type > > definition? > > Yes, there is a big difference :-). The JAXB objects bear metadata (by > annotations) for the XSD definitions and JAXB defines the mapping rules for > Java/XML. In the POJO space, we don't have such a standard. > > > > > Thanks, > > Radim > > > > > > On 8/8/07, ant elder <[EMAIL PROTECTED]> wrote: > >> I'm looking at the on the fly wsdl generation right now. What type of > >> objects are used in your Java interfaces - just POJOs or SDOs or JAXB > >> objects or something else? > >> > >> ...ant > >> > >> On 8/7/07, Radim Kolarik <[EMAIL PROTECTED]> wrote: > >> > > >> > I think we shouldn't mix two things together. > >> > > >> > 1) <interface.wsdl>, which you mentioned now, says that the interface > >> > of a particular service is wsdl interface (not java interface). In > >> > such case, I agree that the wsdl must exist and there is no > >> > anticipation to generate such interface on fly. > >> > > >> > 2) <binding.ws> where we want to expose existing service with > >> > interface written in java, as a web service. In such case the > >> > interface is described by annotated java class. At the moment, it is > >> > necessary to specify wsdl parameter like this: > >> > > >> > wsdlElement=" > >> > http://helloworld#wsdl.port(HelloWorldService/HelloWorldServiceSOAP11port) > >> > " > >> > > >> > which points to an existing WSDL, rather than WSDL being generated on > >> > the fly, from existing java interface. This is by the way how Axis2 > >> > works; the services are described in services.xml file and there is no > >> > need to write WSDL from them separately, it is generated on the fly. > >> > It should be possible to use <binding.ws/> without any parameters, > >> > which would seamlessly expose the service as a web service, without > >> > need to generate WSDL file separately and manually. > >> > > >> > So in ideal situation, .composite file would look like this: > >> > > >> > <composite xmlns="http://www.osoa.org/xmlns/sca/1.0"; > >> > targetNamespace="http://helloworld"; > >> > xmlns:hw="http://helloworld"; > >> > name="helloworldws"> > >> > > >> > <component name="HelloWorldServiceComponent"> > >> > <service name="HelloWorldService"> > >> > <interface.java > >> > interface="helloworld.HelloWorldService"/> > >> > <binding.ws > >> > wsdlElement=" > >> > http://helloworld#wsdl.port(HelloWorldService/HelloWorldServiceSOAP11port) > >> > "/> > >> > </service> > >> > <implementation.java class="helloworld.HelloWorldImpl" /> > >> > </component> > >> > > >> > </composite> > >> > > >> > > >> > Best regards, > >> > Radim > >> > > >> > > >> > > >> > On 8/7/07, shaoguang geng <[EMAIL PROTECTED]> wrote: > >> > > This feature has been inquired seval times. Unfortunately, there is a > >> > wound in SCA1.0's <interface.wsdl> specification. It requires a uri > >> > like > >> > attribute which point to a wsdl infact. It means there should exist a > >> > wsdl > >> > already so that <interface.wsdl> could refer to. > >> > > But how will it make sence, if the service generate wsdl "on fly" > >> > > again. > >> > SCA-WebServiceBinding_V100 does metioned this "on fly" feathre as you > >> > said, > >> > but as my opinion is, it is just a cross work, of no value. > >> > > > >> > > Or SCA's spec might get improved in the near future. > >> > > > >> > > Raymond Feng <[EMAIL PROTECTED]> wrote: Hi, Radim. > >> > > > >> > > I'm not very sure if we already have the support to deploy an SCA > >> > service as > >> > > a web service without WSDL. If not, that's something we want to > >> > > support > >> > for > >> > > sure. > >> > > > >> > > We have a sample to demonstrate the usage of SCA, web service and > >> > > SDO. > >> > It > >> > > seems to be what you are looking for. You can see the sample code at: > >> > > > >> > > > >> > https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/helloworld-ws-sdo > >> > > > >> > > Thanks, > >> > > Raymond > >> > > > >> > > ----- Original Message ----- > >> > > From: "Radim Kolarik" > >> > > To: > >> > > Sent: Wednesday, July 25, 2007 7:38 AM > >> > > Subject: Services and WSDL files > >> > > > >> > > > >> > > > Hi, > >> > > > > >> > > > Is it necessary to supply wsdl file if I want to deploy an SCA > >> > > > service > >> > as > >> > > > a > >> > > > web service? Or can Tuscany generate the file "on the fly"? > >> > > > > >> > > > If I need to supply the file myself, what would be the best way to > >> > > > generate > >> > > > the file? Is it possible to generate the file for SDOs, if they are > >> > > > service > >> > > > parameters or if a service returns an SDO object as its result? > >> > > > > >> > > > Thanks, > >> > > > Radim > >> > > > > >> > > > >> > > > >> > > --------------------------------------------------------------------- > >> > > To unsubscribe, e-mail: [EMAIL PROTECTED] > >> > > For additional commands, e-mail: [EMAIL PROTECTED] > >> > > > >> > > > >> > > > >> > > > >> > > --------------------------------- > >> > > Pinpoint customers who are looking for what you sell. > >> > > >> > --------------------------------------------------------------------- > >> > To unsubscribe, e-mail: [EMAIL PROTECTED] > >> > For additional commands, e-mail: [EMAIL PROTECTED] > >> > > >> > > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
