Re: WSDLLess Deployment Implementation Question
Scott Kurz wrote:
OK, just wanted to make sure I hadn't missed a discussion on how to do
this with dynamic SDOs.
You know, one issue I noticed when looking at this with static SDOs is
the way that SDO makes it hard for you
to programmatically go from static SDO to XSD. Looking at the SDO
source I think it was the code in
org.apache.tuscany.sdo.helper.SchemaBuilder.buildSchema() which was responsible:
throw new IllegalArgumentException("Cannot generate
XSD since SDO Type '" +
dataType.getName() + "' was orginally
generated from XSD. Use original XSD");
[snip]
There may be issues with that method :) but there should be enough
metadata in the SDO type to generate a compatible XSD.
We could also grab the element/type qname from the SDO type, find its
declaration in the XSD files in the scope of the contribution, and
simply use it.
I'd prefer that as it'll be easier for the app developer to get WSDL
pointing back to his original XSD.
--
Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: WSDLLess Deployment Implementation Question
Hi Scott,
There was a discussion around this with the SDO folks and their view point
was that, having generated the static SDO from an XSD, why would one want to
go and generate the XSD again. Ideally the original XSD should be used.
Its been a while since I've been thro this, but I do remember that the
discussion started after I had some trouble in getting back something
equivalent to the original XSD as part of this generation. It was then
decided that we would provide these XSD locations as input arguments these
would be imported during the WSDL generation.
- Venkat
On Feb 5, 2008 8:10 PM, Scott Kurz <[EMAIL PROTECTED]> wrote:
> OK, just wanted to make sure I hadn't missed a discussion on how to do
> this with dynamic SDOs.
>
> You know, one issue I noticed when looking at this with static SDOs is
> the way that SDO makes it hard for you
> to programmatically go from static SDO to XSD. Looking at the SDO
> source I think it was the code in
> org.apache.tuscany.sdo.helper.SchemaBuilder.buildSchema() which was
> responsible:
>
>throw new IllegalArgumentException("Cannot generate
> XSD since SDO Type '" +
>dataType.getName() + "' was orginally
> generated from XSD. Use original XSD");
>
>
>
>
>
> On Feb 5, 2008 3:55 AM, Jean-Sebastien Delfino <[EMAIL PROTECTED]>
> wrote:
> > Scott Kurz wrote:
> > > When you wrote:
> > >
> > > - The generator should use the databinding metadata (including any
> > > knowledge of handwritten XSD representing the business data and
> > > generation capabilities like the SDO XSDGenerator) to generate proper
> > > XSD in the WSDL.
> > >
> > > How were you thinking a particular XSD would be associated with a
> > > generic DataObject on a Java intf?What
> > > metadata would we be using as input here?
> > >
> > [snip]
> >
> > I was thinking about static SDOs.
> >
> > Java method updateCustomer(DataObject anObject) would translate to
> > WSDL operation updateCustomer [ XSD xsd:any ]
> >
> > but Java method updateCustomer(Customer customer) would translate to
> > WSDL operation updateCustomer [ XSD cust:Customer ]
> >
> >
> > --
> > Jean-Sebastien
> >
> > -
> > 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]
>
>
Re: WSDLLess Deployment Implementation Question
On Feb 3, 2008 5:01 PM, Mike Edwards <[EMAIL PROTECTED]> wrote: > Folks, > It is important to remember that when an interface is specified EITHER > as some non-WSDL interface type (eg Java interface) OR where it is > specified as WSDL, the FINAL WSDL that is necessary for a deployed (web) > service may need generating from the original interface definition. In addition to the case where we start with an interface.wsdl but still need to add policy to the final, logical WSDL defining the port...I believe, (if I'm understanding the code correctly), that we have a simpler case here that we don't support today. That's the case where the defines a portType but not a port, so we still need to calculate a port when we see , but we'd like to start from the WSDL (I would assume) rather than starting from the Java. I think the WS binding spec in at least one place implies if you use you do have a port, but I don't see why that would be. Scott - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WSDLLess Deployment Implementation Question
OK, just wanted to make sure I hadn't missed a discussion on how to do
this with dynamic SDOs.
You know, one issue I noticed when looking at this with static SDOs is
the way that SDO makes it hard for you
to programmatically go from static SDO to XSD. Looking at the SDO
source I think it was the code in
org.apache.tuscany.sdo.helper.SchemaBuilder.buildSchema() which was responsible:
throw new IllegalArgumentException("Cannot generate
XSD since SDO Type '" +
dataType.getName() + "' was orginally
generated from XSD. Use original XSD");
On Feb 5, 2008 3:55 AM, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> Scott Kurz wrote:
> > When you wrote:
> >
> > - The generator should use the databinding metadata (including any
> > knowledge of handwritten XSD representing the business data and
> > generation capabilities like the SDO XSDGenerator) to generate proper
> > XSD in the WSDL.
> >
> > How were you thinking a particular XSD would be associated with a
> > generic DataObject on a Java intf?What
> > metadata would we be using as input here?
> >
> [snip]
>
> I was thinking about static SDOs.
>
> Java method updateCustomer(DataObject anObject) would translate to
> WSDL operation updateCustomer [ XSD xsd:any ]
>
> but Java method updateCustomer(Customer customer) would translate to
> WSDL operation updateCustomer [ XSD cust:Customer ]
>
>
> --
> Jean-Sebastien
>
> -
> 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]
Re: WSDLLess Deployment Implementation Question
Scott Kurz wrote: When you wrote: > - The generator should use the databinding metadata (including any knowledge of handwritten XSD representing the business data and generation capabilities like the SDO XSDGenerator) to generate proper XSD in the WSDL. How were you thinking a particular XSD would be associated with a generic DataObject on a Java intf?What metadata would we be using as input here? [snip] I was thinking about static SDOs. Java method updateCustomer(DataObject anObject) would translate to WSDL operation updateCustomer [ XSD xsd:any ] but Java method updateCustomer(Customer customer) would translate to WSDL operation updateCustomer [ XSD cust:Customer ] -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WSDLLess Deployment Implementation Question
Sebastien, When you wrote: - The generator should use the databinding metadata (including any knowledge of handwritten XSD representing the business data and generation capabilities like the SDO XSDGenerator) to generate proper XSD in the WSDL. How were you thinking a particular XSD would be associated with a generic DataObject on a Java intf?What metadata would we be using as input here? I know if we had generated SDOs and an XSD in the archive we could write an algorithm to make a match, but I was thinking along the lines that, in such a case, we have less information in the Java than the WSDL and so therefore the user would perhaps even be required to specify to narrow down the specific schema type(s). But I'm interested to hear your thoughts. Scott - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WSDLLess Deployment Implementation Question
Mike Edwards wrote: Folks, ant elder wrote: On Jan 31, 2008 5:04 PM, Lou Amodeo <[EMAIL PROTECTED]> wrote: Hi, I have a question about the implementation of the "wsdlless" deployment function. The issues I see are occurring in a couple of places within the life-cycle. Namely, deployment, binding start, and service definition. It occurs to me that if the generation of the wsdl occurred early in the process, rather than during the startup of the component, Tuscany could maintain a common code path for contributions with wsdl and contributions w/o wsdl. Today for instance WSDL is processed in the WSBindingProcessor when its present and the Axis2ServiceBinding when its not. I am curious why this is so? Why wouldn't the WSBindingProcessor detect wsdlLess, generate a wsdl definition at that point and the subsuquent flow from there on would be the same? Alternatively, when a contribution is deployed, why not detect a wsdl is missing, generate one, and place it in the contribution. At this point a wsdlElement could also be added and the subsequent startup process would not know the difference? I am not sure if other bindings will adopt a wsdlless approach but I would think a common non-binding specific process would be beneficial. Thanks for your help. I think the issue may be at what point the information required to generate the wsdl becomes available. When is used without the wsdlElement attribute then the wsdl comes from the service or reference interface and if thats not then this is when a wsdl needs to be generated. I'm not sure if the service or reference interface is going to be available anywhere when the WebServiceBindingProcessor resolve method is called. ...ant It is important to remember that when an interface is specified EITHER as some non-WSDL interface type (eg Java interface) OR where it is specified as WSDL, the FINAL WSDL that is necessary for a deployed (web) service may need generating from the original interface definition. The SCA metadata can include Policy information that is likely missing from the original interface definition (eg need for encryption of the messages). This extra SCA metadata needs to be processed before the final WSDL can be generated and may involve things like reading policy sets to determine the correct layout and content of the final WSDL. The final processed version of the WSDL should not be placed back into the contribution in case of any updates to the Domain as a whole (eg someone decides on a change of policy set for the domain as a whole), since that would require recalculation of the generated WSDL (not something we do now, but useful to think ahead). Yours, Mike. Mike, +1 to everything you said. I think it's in line with what I was trying to describe earlier in this thread [1]. I had missed the impact of policies in [1], rephrasing it here to add the policy aspect: - The WSDL4J model should be produced earlier in the composite processing cycle and passed to the binding that will need it, allowing it to add binding specific info (e.g SOAP binding, the service endpoint declaration ... ... and additional configuration determined by the policy sets applied to the binding). [1] http://marc.info/?l=tuscany-dev&m=120199391108418 -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WSDLLess Deployment Implementation Question
Folks, ant elder wrote: On Jan 31, 2008 5:04 PM, Lou Amodeo <[EMAIL PROTECTED]> wrote: Hi, I have a question about the implementation of the "wsdlless" deployment function. The issues I see are occurring in a couple of places within the life-cycle. Namely, deployment, binding start, and service definition. It occurs to me that if the generation of the wsdl occurred early in the process, rather than during the startup of the component, Tuscany could maintain a common code path for contributions with wsdl and contributions w/o wsdl. Today for instance WSDL is processed in the WSBindingProcessor when its present and the Axis2ServiceBinding when its not. I am curious why this is so? Why wouldn't the WSBindingProcessor detect wsdlLess, generate a wsdl definition at that point and the subsuquent flow from there on would be the same? Alternatively, when a contribution is deployed, why not detect a wsdl is missing, generate one, and place it in the contribution. At this point a wsdlElement could also be added and the subsequent startup process would not know the difference? I am not sure if other bindings will adopt a wsdlless approach but I would think a common non-binding specific process would be beneficial. Thanks for your help. I think the issue may be at what point the information required to generate the wsdl becomes available. When is used without the wsdlElement attribute then the wsdl comes from the service or reference interface and if thats not then this is when a wsdl needs to be generated. I'm not sure if the service or reference interface is going to be available anywhere when the WebServiceBindingProcessor resolve method is called. ...ant It is important to remember that when an interface is specified EITHER as some non-WSDL interface type (eg Java interface) OR where it is specified as WSDL, the FINAL WSDL that is necessary for a deployed (web) service may need generating from the original interface definition. The SCA metadata can include Policy information that is likely missing from the original interface definition (eg need for encryption of the messages). This extra SCA metadata needs to be processed before the final WSDL can be generated and may involve things like reading policy sets to determine the correct layout and content of the final WSDL. The final processed version of the WSDL should not be placed back into the contribution in case of any updates to the Domain as a whole (eg someone decides on a change of policy set for the domain as a whole), since that would require recalculation of the generated WSDL (not something we do now, but useful to think ahead). Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WSDLLess Deployment Implementation Question
Simon Laws wrote:
On Jan 31, 2008 5:04 PM, Lou Amodeo <[EMAIL PROTECTED]> wrote:
Hi, I have a question about the implementation of the "wsdlless"
deployment
function.
The issues I see are occurring in a couple of places within the
life-cycle.
Namely, deployment, binding start, and service definition. It occurs to me
that if the generation of the wsdl occurred early in the process, rather
than during the startup of the component, Tuscany could maintain a common
code path for contributions with wsdl and contributions w/o wsdl. Today
for
instance WSDL is processed in the WSBindingProcessor when its present and
the Axis2ServiceBinding when its not. I am curious why this is so? Why
wouldn't the WSBindingProcessor detect wsdlLess, generate a wsdl
definition
at that point and the subsuquent flow from there on would be the same?
Alternatively, when a contribution is deployed, why not detect a wsdl is
missing, generate one, and place it in the contribution. At this point a
wsdlElement could also be added and the subsequent startup process would
not
know the difference? I am not sure if other bindings will adopt a wsdlless
approach but I would think a common non-binding specific process would be
beneficial.
Thanks for your help.
Hi Lou,
Anything we can do to simplify our code path is a good thing IMO.
More specifically I'm attracted by your idea of having the wsdl processing
happen in one place and I think this could work well for the model generated
in memory when a composite is processed. The WSDL interface contract could
be built in the earlier phases of composite processing and the code at the
top of Axis2ServiceBindingProvider
InterfaceContract contract = wsBinding.getBindingInterfaceContract
();
if (contract == null) {
contract = service.getInterfaceContract
().makeUnidirectional(false);
if ((contract instanceof JavaInterfaceContract)) {
contract =
Java2WSDLHelper.createWSDLInterfaceContract((JavaInterfaceContract)contract,
requiresSOAP12(wsBinding));
}
wsBinding.setBindingInterfaceContract(contract);
}
Could be reworked or removed..
Could you say a little more about the alternative you propose,
"Alternatively, when a contribution is deployed, why not detect a wsdl is
missing, generate one, and place it in the contribution. ". What you you
mean by "deployed" here. I'm asking in relation to two other threads that
are ongoing.
In the discussion [1] about reference targets I've been floating the idea of
having a contribution processing phase in the domain that fixes up
contributions before they are deployed to nodes. I had been thinking about
URIs but this WSDL point could be another one of the things that could be
done ahead of time. In that way the Node would always be presented with a
WSDL file in the deployed contribution.
In the discussion [2] about the runtime Java2WSDL processing you suggest
that you want to write the generated WSDL out as a file as an alternative to
providing access to it via ?wsdl. Moving this processing forward would make
this related fix easier. My question here is where should the WSDL file be
written to? I'll ask that back over on the other thread.
Regards
Simon
[1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg27294.html
[2] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg27532.html
I agree with Lou and Simon on the overall approach.
I've expressed concerns with the current WSDL-less support design before
[3] and I think it's broken as it's not considering the SCA interface
and data binding metadata to generate the WSDL+XSD.
Here's what I think should happen:
- A clean interface-model-to-WSDL4J generator should be developed in the
interface-wsdl module.
- The generator should use the databinding metadata (including any
knowledge of handwritten XSD representing the business data and
generation capabilities like the SDO XSDGenerator) to generate proper
XSD in the WSDL.
- The WSDL4J model should be produced earlier in the composite
processing cycle and passed to the binding that will need it, allowing
it to add binding specific info (e.g SOAP binding and the service
endpoint declaration).
- The complete WSDL should be used to configure the underlying WS stack
(Axis2 or other), leading to a single and simpler binding code path.
I don't think it's wise to store the WSDL in the SCA contribution at
deployment time as it can be calculated and storing it is the best way
to get it out of sync with the other artifacts and cause confusion.
[3] https://issues.apache.org/jira/browse/TUSCANY-1556
Here are a few other related JIRAs. I think it's about time to redesign
that WSDL-less support and make it right.
https://issues.apache.org/jira/browse/TUSCANY-1713
https://issues.apache.org/jira/browse/TUSCANY-1648
https://issues.apache.org/jira/browse/TUSCANY-1544
https://issues.apache.org/jira/browse/TUSCANY-1557
--
Jean-Sebastien
-
Re: WSDLLess Deployment Implementation Question
On Jan 31, 2008 5:04 PM, Lou Amodeo <[EMAIL PROTECTED]> wrote: > Hi, I have a question about the implementation of the "wsdlless" > deployment > function. > The issues I see are occurring in a couple of places within the > life-cycle. > Namely, deployment, binding start, and service definition. It occurs to me > that if the generation of the wsdl occurred early in the process, rather > than during the startup of the component, Tuscany could maintain a common > code path for contributions with wsdl and contributions w/o wsdl. Today > for > instance WSDL is processed in the WSBindingProcessor when its present and > the Axis2ServiceBinding when its not. I am curious why this is so? Why > wouldn't the WSBindingProcessor detect wsdlLess, generate a wsdl > definition > at that point and the subsuquent flow from there on would be the same? > Alternatively, when a contribution is deployed, why not detect a wsdl is > missing, generate one, and place it in the contribution. At this point a > wsdlElement could also be added and the subsequent startup process would > not > know the difference? I am not sure if other bindings will adopt a wsdlless > approach but I would think a common non-binding specific process would be > beneficial. > > > Thanks for your help. > I think the issue may be at what point the information required to generate the wsdl becomes available. When is used without the wsdlElement attribute then the wsdl comes from the service or reference interface and if thats not then this is when a wsdl needs to be generated. I'm not sure if the service or reference interface is going to be available anywhere when the WebServiceBindingProcessor resolve method is called. ...ant
Re: WSDLLess Deployment Implementation Question
On Jan 31, 2008 5:04 PM, Lou Amodeo <[EMAIL PROTECTED]> wrote:
> Hi, I have a question about the implementation of the "wsdlless"
> deployment
> function.
> The issues I see are occurring in a couple of places within the
> life-cycle.
> Namely, deployment, binding start, and service definition. It occurs to me
> that if the generation of the wsdl occurred early in the process, rather
> than during the startup of the component, Tuscany could maintain a common
> code path for contributions with wsdl and contributions w/o wsdl. Today
> for
> instance WSDL is processed in the WSBindingProcessor when its present and
> the Axis2ServiceBinding when its not. I am curious why this is so? Why
> wouldn't the WSBindingProcessor detect wsdlLess, generate a wsdl
> definition
> at that point and the subsuquent flow from there on would be the same?
> Alternatively, when a contribution is deployed, why not detect a wsdl is
> missing, generate one, and place it in the contribution. At this point a
> wsdlElement could also be added and the subsequent startup process would
> not
> know the difference? I am not sure if other bindings will adopt a wsdlless
> approach but I would think a common non-binding specific process would be
> beneficial.
>
>
> Thanks for your help.
>
Hi Lou,
Anything we can do to simplify our code path is a good thing IMO.
More specifically I'm attracted by your idea of having the wsdl processing
happen in one place and I think this could work well for the model generated
in memory when a composite is processed. The WSDL interface contract could
be built in the earlier phases of composite processing and the code at the
top of Axis2ServiceBindingProvider
InterfaceContract contract = wsBinding.getBindingInterfaceContract
();
if (contract == null) {
contract = service.getInterfaceContract
().makeUnidirectional(false);
if ((contract instanceof JavaInterfaceContract)) {
contract =
Java2WSDLHelper.createWSDLInterfaceContract((JavaInterfaceContract)contract,
requiresSOAP12(wsBinding));
}
wsBinding.setBindingInterfaceContract(contract);
}
Could be reworked or removed..
Could you say a little more about the alternative you propose,
"Alternatively, when a contribution is deployed, why not detect a wsdl is
missing, generate one, and place it in the contribution. ". What you you
mean by "deployed" here. I'm asking in relation to two other threads that
are ongoing.
In the discussion [1] about reference targets I've been floating the idea of
having a contribution processing phase in the domain that fixes up
contributions before they are deployed to nodes. I had been thinking about
URIs but this WSDL point could be another one of the things that could be
done ahead of time. In that way the Node would always be presented with a
WSDL file in the deployed contribution.
In the discussion [2] about the runtime Java2WSDL processing you suggest
that you want to write the generated WSDL out as a file as an alternative to
providing access to it via ?wsdl. Moving this processing forward would make
this related fix easier. My question here is where should the WSDL file be
written to? I'll ask that back over on the other thread.
Regards
Simon
[1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg27294.html
[2] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg27532.html
