Hi Johannes,
Try breaking up this email into 1-2 questions at a time. It's very hard
to read:)
Just a few points to help:
1) To be doc-literal, import the necessary XSDs. Don't import another
WSDL and assume you'll inherit all the schemas used in that WSDL.
2) Try to avoid using wsdlmerge. I've seen that after using wsdl2java,
the wsdl it generates which combines all schemas inline doesn't always
update the schema namespaces properly. So I've always deployed my
original wsdls instead of the one wsdl2java outputs.
3) The "No WS-RP schema found" can safely be ignored. It's probably
because your service has WSRP properties but no .wsrmd file, which is
not required.
4) If a generated capability method doesn't have parameters when it is
expected to, it might be due to your wsdl not being doc-literal. The
message input might not be defined correctly. Since you didn't include
your schemas (i.e. sas:GetCapabilities), I can't tell if you're defining
them correctly.
5) A capability only needs to implement AbstractWsResourceCapability if
it is providing the get/set methods for your custom resource properties.
6) A SubscriptionManager resource manages a single subscription. So if
you call Subscribe 5 times, you will have 5 instances of
SubscriptionManager.
-Vinh
-----Original Message-----
From: Allen George [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 13, 2008 8:49 AM
To: [email protected]
Subject: Re: generating sources for service using quite complex schema
Hi Johannes,
I'm not as expert as many on this list, but I thought I'd take a stab at
answering some of your questions anyways.
Looking through your SAS.wsdl, I was curious why you did a <wsdl:import>
of the WSRF/WSN wsdls. At least when I created my (much simpler)
WS-Resource I did not have to do that.
Another point: I noticed that you've split your schema definition for
the same namespace into two parts as follows:
<xsd:schema elementFormDefault="qualified"
targetNamespace="http://www.opengis.net/sas/1.0.0";>
<xsd:include schemaLocation="OGC-SAS-1_0_0-sasAll.xsd"/>
<xsd:include
schemaLocation="OGC-SAS-1_0_0-sasCapabilities.xsd"/>
<xsd:include schemaLocation="OGC-SAS-1_0_0-sasCommon.xsd"/>
<xsd:include
schemaLocation="OGC-SAS-1_0_0-sasDescribeSensor.xsd"/>
<xsd:include
schemaLocation="OGC-SAS-1_0_0-sasMessageSchema.xsd"/>
</xsd:schema>
<xsd:schema elementFormDefault="qualified"
targetNamespace="http://www.opengis.net/sas/1.0.0";>
<xsd:element name="SasResourceProperties">
<xsd:complexType>
<xsd:sequence>
<xsd:element
ref="wsrf-rp:QueryExpressionDialect" minOccurs="0"
maxOccurs="unbounded"/>
<xsd:element ref="wsn-b:FixedTopicSet"/>
<xsd:element ref="wsn-t:TopicSet"
minOccurs="0"/>
<xsd:element ref="wsn-t:TopicExpression"
minOccurs="0" maxOccurs="unbounded"/>
<xsd:element ref="wsn-t:TopicExpressionDialect"
minOccurs="0"
maxOccurs="unbounded"/>
<xsd:element ref="muws1:ResourceId"/>
<xsd:element ref="muws1:ManageabilityCapability"
minOccurs="0"
maxOccurs="unbounded"/>
<!-- ??? -->
<xsd:element ref="muws2:Caption" minOccurs="0"
maxOccurs="unbounded"/>
<!-- ??? -->
<xsd:element ref="muws2:Description"
minOccurs="0" maxOccurs="unbounded"/>
<!-- ??? -->
<xsd:element ref="muws2:Version" minOccurs="0"/>
<!-- ??? -->
<xsd:element ref="muws2:OperationalStatus"/>
<!-- ??? -->
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:complexType name="ServiceExceptionType">
<xsd:complexContent>
<xsd:extension base="wsrf-bf:BaseFaultType">
<xsd:choice>
<xsd:element ref="ows:ExceptionReport"/>
<xsd:element ref="ows:Exception"/>
</xsd:choice>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="ServiceException"
type="sas:ServiceExceptionType"/>
</xsd:schema>
I am not sure how a parser will interpret this, but my understanding was
that each <xsd:schema></xsd:schema> pair is separate from the other. Was
there a reason you did not include the imports and message definitions
in one <xsd:schema> pair? Also, I assume that all the imported documents
are defined in the http://www.opengis.net/sas/1.0.0 namespace or have no
namespace?
C:\muse-test\wsdl>wsdl2java.bat -j2ee mini -wsdl SASallinone.wsdl
-output test -verbose
WARNING: [ID = 'NoWSRPSchema'] No WS-RP schema found
I'm not quite sure, but this may be because you don't have
ResourceMetadataDescriptor document attached to your SAS portType as
well as a reference to wsrf-rp:ResourceProperties reference. Perhaps
someone can correct me on this?
(MyCapability2) package net.opengis.www.sas._1.0.0; import
org.apache.muse.core.AbstractCapability; import org.w3c.dom.Element;
public class MyCapability extends AbstractCapability implements
IMyCapability { public Element getCapabilities() throws
Exception { //TODO implement getCapabilities throw
new RuntimeException("Unimplemented Method: getCapabilities"); }
public Element describeSensor(Element SensorID) throws Exception {
//TODO implement describeSensor throw new
RuntimeException("Unimplemented Method: describeSensor"); } }
I cannot see the element definition for sas:GetCapabilities in either of
the WSDLs... What does it look like?
There are several questions that I have
* concerning the generated sources:
o The getCapabilities method (in MyCapability2) should expect
some XML input - do you have any idea why the generated
method only has a return parameter? Is that due to the fact
that I used doc/literal?
No - I don't think it's because it's doc/lit. All my WSDLs use doc/lit
and they have input parameters for the methods. I am curious if the
element definition is being found properly.<br>
o The describeSensor method (in MyCapability2) looks ok - if
the SensorID Element is actually the complete
DescribeSensor
request XML document which would be send by a client in the
SOAP body. Looking at the registerPublisher method, it
seems
like wsdl2java removes the top-level XML fragment from the
request (in this case the RegisterPublisher XML element)
and
lists all elements contained in that element instead (even
converting them if they are of simple type).
What does the sas:DescribeSensor element look like? Is SensorID a
complex type? (Note that you can write your own Java classes to
represent this type and define a custom serializer in muse.xml to
convert to/from the xml wire format; this would allow you to use a Java
type as a method parameter)
o Neither of the capability classes extends
AbstractWsResourceCapability - is that due to the fact that I did not
extend the resource type with my own elements (i.e., it just lists
elements from WSN, WSRF and MUWS)?
The capabilities look fine. I've not seen any generated capability
extend AbstractWsResourceCapability...
o The registerPublisher method (in MyCapability1) takes the
elements contained in a usual RegisterPublisher request,
i.e. as they are listed in the schema from OASIS, as
parameters. As I said earlier I would like to make use of
the extension mechanism for that operation. Do I therefore
have to modify the schema before generating source code or
is there some way to retrieve the pure request body via
muse?
Were you planning on extending it using the <xsd:extension>system?
* in general:
o According to the SubscriptionManager.wsdl that is contained
in the generated folders (WebContent/WEB-INF/classes/wsdl)
there will be one subscription manager that will be
referenced in all Subscribe request responses. So will each
subscription reference the same manager?
Could you clarify this point? My understanding is that when subscribing,
you set the producer EPR to the EPR of the resource that you're
subscribing to. That said, all subscribe operations are handled by the
same subscription manager under Muse's hood. Any renew, destroy request
etc. will contain a subscription reference that (using reference
parameters) will identify the exact subscription you want to perform
these operations on...
I hope this helps a bit at least.
Cheers,
Allen
---------------------------------------------------------------------
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]
