Mailing-List: contact axis-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-dev@xml.apache.org
Message-ID: <9C79F2D39765D411B18900508BE326A2072CA8D0@USPLM208>
From: "Sadiq, Waqar" <waqar.sadiq@eds.com>
To: axis-dev@xml.apache.org
Subject: RE: WSDL musings
Date: Mon, 20 Aug 2001 15:29:33 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"


If you are taking requirements for WSDL support in Axis, then here is one.
I believe that the business process orchestration on languages such as WSFL
will play a significant role.  These process engines require a dynamic
invocation mechanism.  During the course of executing a business process
engine, the process engine may retrieve WSDL for the target web service from
some source.  A flexible engine will be able to invoke the target operations
on the target web service dynamically, without statically generated stubs.
It would be great if the process engine is not burdened with the task of
having to parse WSDL to figure our how to make the call.  In order to be
partly blind to how the call needs to be made, meta data is required.  For
those familiar with CORBA-DII, the meta data came from the interface
repository.  For web services, all that meta data is in the WSDL document
for the target service.  This requirements is partly being addressed by the
two JSR's (JSR 101 & 109) and also by WSIF. How about Axis supporting this?

Thanks,

Waqar Sadiq
EDS EIT ESAI - Enterprise Consultant
MS H3-4C-22
5400 Legacy Drive
Plano, TX 75024

phone:     +01-972-797-8408 (8-837)
e-mail:    waqar.sadiq@eds.com
fax:       +01-972-605-4071


-----Original Message-----
From: Glen Daniels [mailto:gdaniels@macromedia.com]
Sent: Monday, August 20, 2001 1:00 PM
To: 'axis-dev@xml.apache.org'
Subject: WSDL musings


I'd like to get a more general WSDL generation mechanism going, which can
take into account different providers, and also changes to the description
caused by deployed Handlers.  It seems to me that the good way to do this is
to have an editWSDL(MessageContext) method on Handler, and then use the
exact same process to invoke handlers that we do when actually processing a
message.  That way, whatever dispatch mechanism you have in place (custom,
URLMapper, JWSHandler...) will work to decide on the service, and the "core"
WSDL will be generated by the provider.

Can I get people's opinions on this?  I want to do something to generalize
WSDL composition ASAP, so if I don't hear anything from other committers in
the next day or two, I'm going to move ahead with this idea and we'll see
where it goes.

I think it's a good plan; the only other way I might do it is by fleshing
out ServiceDescription a little bit more (i.e. adding space for headers,
bindings, etc) and having the handler chains create one of those, which
would then get turned into WSDL...

Glen Daniels
Macromedia
http://www.macromedia.com/
                                Building cool stuff for web developers