axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Maddison, David" <Maddis...@dnb.com>
Subject RE: ?WSDL now uses the new Java2WSDL emitter code
Date Thu, 13 Dec 2001 10:31:40 GMT
>>  One other point on this.  I brought up before the idea that 
>>  a service 
>>  being deployed into Axis should have the ability to specify 
>>  which WSDL 
>>  document will be used as opposed to autogenerated.  That 
>>  way, if a service 
>>  is actually an implementation of an already defined WSDL, 
>>  we don't have to 
>>  go through the trouble of recreating it. 

The same should be of Schema's.  In the future certain schemas will be
standard around markets, and therefore the schema's shouldn't be
autogenerated, but rather imported into the WSDL.

BTW. I love the new emitter for WSDL generation!  Just as an aside I've used
a different method for WSDL generation which seperates all the parts of the
engine.  The way my generation works is as such:

1) The Engine creates a WSDL4J Definition object
2) The engine adds the default namespaces and the Service Namespace to the
Definition
3) The engine adds the outline of the service element to the definition
4) The pivot is then called (following the chain), which adds the PortType.
Any custom types needed are looked up in the registry, and the corresponding
serialiser is responsible for producing the XML Schema object.
5) The engine then passes this WSDL definition to all available transports,
(or at least the ones this webservice is bound too), which adds the
binding/encoding element.
6) The transports also add the Port element to the service

Using your new emitter, I can see how I can simplify the code in each stage,
by giving it the metadata, leaving the WSDL generation up to the emitter.  

I just keep getting the feeling that parts of the engine are still being
bound too tightly to HTTP.  The current emitter assumes that the WSDL is
going to be bound to HTTP.  Could we not pass in some sort of EndPoint
object that defines the metadata of the endpoint?  If we could have an array
of these objects that would also be cool, so in an engine such as mine, the
service can be bound to two different endpoints?

Just my 2c :-)

Dave

Mime
View raw message