2007/12/5, Jean-Sebastien Delfino <[EMAIL PROTECTED]>:
> Jean-Sebastien Delfino wrote:
> > Some answers after researching the spec docs:
> >
> > Raymond Feng wrote:
> >> Hi,
> >>
> >> I think this issue needs to be brought up at the spec level.
> >> Basically, the following have to be clarified:
> >>
> >> 1) What interfaces are qualified to be remotable?
> >> 2) What are the characteristics of the input/output types for
> >> remotable interfaces?
> >
> > Assembly spec: 697
> > "Whether a service of a component implementation is
> > remotable is defined by the interface of the service. In the case of
> > Java this is defined by adding the @Remotable annotation to the Java
> > interface (see Client and Implementation Model Specification for Java).
> > WSDL defined interfaces are always remotable."
> >
> > Java SCA Annotations and APIs spec: 297
> > "Java interfaces generated from a WSDL portType are always remotable."
> >
> > I think that says that JAX-WS generated interfaces should be considered
> > remotable even in the absence of an @Remotable interface.
> >
> > Java SCA Annotations and APIs spec: 1531
> > Complex data types exchanged via remotable service interfaces must be
> > compatible with the marshalling technology used by the service binding.
> > For example, if the service is going to be exposed using the standard
> > web service binding, then the parameters must be Service Data Objects
> > (SDOs) 2.0 [2] or JAXB [3] types.
> > Independent of whether the remotable service is called from outside of
> > the composite that contains it or from another component in the same
> > composite, the data exchange semantics are by-value."
> >
> > This leaves the door open for other data representations supported by
> > other service bindings, e.g. a DOM or a Java Serializable object.
> >
> > The Java SCA Annotations and APIs spec Errata adds this:
> > "The SCA Client and Implementation Model for Java applies the WSDL to
> > Java and Java to WSDL mapping rules as defined by the JAX-WS
> > specification [4] for generating remotable Java interfaces from WSDL
> > portTypes and vice versa.
> > For the purposes of the Java-to-WSDL mapping algorithm, the interface is
> > treated as if it had a @WebService annotation on the class, even if it
> > doesn't, and the org.osoa.OneWay annotation should be treated as a
> > synonym for javax.jws.OneWay. For the WSDL-to-Java, the generated
> > @WebService annotation should imply that the interface is @Remotable.
> > For the mapping from Java types to XML schema types SCA supports both
> > the SDO 2.1 [2] mapping and the JAXB [3] mapping. Having a choice of
> > binding technologies is allowed, as noted in the first paragraph of
> > section 5 of the JSR 181 (version 2) specification, which is referenced
> > by the JAX-WS specification."
> >
> > EJB binding spec: 105
> > "When used with the EJB binding, a service or reference interface must
> > be compatible with a session bean interface, according to the following
> > rules:
> > - The interface offered by a reference MUST be remotable if the remote
> > session bean interface is being accessed, and MUST be local if the local
> > session bean interface is being accessed.
> > - The methods on the session bean MUST be a compatible superset of the
> > methods in the interface used by the reference.
> > - The interface used by a reference MAY NOT contain any methods
> > inherited from EJBObject or EJBLocalObject.
> > - Compatibility for an individual method is defined by the SCA Assembly
> > Model Specification [4], and can be stated simply as compatibility of
> > the signature. That is, the method name, input types, and output types
> > MUST be identical.
> > - The order of the input and output types also MUST be identical."
> >
> > This brings interesting points:
> > - EJB binding does not imply remote, local interfaces are also supported
> > (contrary to the common belief that "binding" implies "remote").
> > - an SCA reference can use a newly defined Java interface (compatible
> > with the session bean interface but not dragging javax.ejb.Remote) with
> > a @Remotable annotation".
> >
> >
> >> 3) What are the semantics of pass-by-value?
> >
> > Assembly spec: 706
> > "Independent of whether the remotable service is called remotely from
> > outside the process where the service runs or from another component
> > running in the same process, the data exchange semantics are by-value.
> > Implementations of remotable services may modify input messages
> > (parameters) during or after an invocation and may modify return
> > messages (results) after the invocation. If a remotable service is
> > called locally or remotely, the SCA container is responsible for making
> > sure that no modification of input messages or post-invocation
> > modifications to return messages are seen by the caller."
> >
> > Does that help answer your questions?
> >
>
> So, based on all the above, I'd like to come up with a reasonable
> implementation of the pass-by-value behavior for in-VM interactions.
>
> By in-VM I mean:
> - a reference is wired to a service
> - both run in the same node
> - the SCA binding is used.
>
> Disclaimer: In-VM can have many different meanings so people not
> comfortable with that definition of "in-VM", valid only withing the
> context of the present email, can call it "in-Foo" if they want :)
>
> Assuming the following remotable business interface:
> @Remotable
> interface StockQuote {
> getQuote(X symbol);
> }
>
> Assuming getQuote(String symbol)
> String is immutable and doesn't need to be copied
>
> Now assuming getQuote(Symbol symbol)
> if Symbol implements commonj.sdo.DataObject
> symbol is copied using the SDO copy util
>
> else if Symbol is a JAXB generated object
> symbol is copied using JAXB XML marshalling [1]
>
> else if Symbol implements java.io.Serializable
> symbol is copied using Java serialization [2]
>
> else if Symbol implements StAX XMLStreamReader
> symbol is copied using StAX streaming
>
> // I'm not going to list all possible databindings but you get
> // the picture...
>
> else // assuming we have a simple JavaBean
> symbol is copied using JAXB XML serialization [3]
This schema is what i needed.
Cheers,
Giorgio.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
