Re: [jug-discussion] ColdFusion from JAXRPC

2004-05-03 Thread Dennis Sosnoski
Duffy Gillman wrote:

...
So far I've wished real hard, crossed my fingers and held my breath.  
Neither these nor scouring newsgroups and tutorial sites have yielded the 
tools nor tutorials I imagine.  So I thought to put this to the group.  
Has anyone ventured to implement the same web service on different 
platforms (ideally JAXRPC and ColdFusion)?  Am I the only wingnut out 
there who wants to treat WSDL as an interface definition for multiple 
services (I *can't* be, but hope I'm not the only one here)?  Is it 
possible to get ColdFusion to produce errors (SOAP fault messages) that 
match up with those in a Java-derived WSDL document?

I'd be interested in whatever experieces y'all have had.

-Duffy

P.S.  If I put down a vote for Dennis for the full meeting, do I get to 
ask obnoxious questions about sharing WSDL files between platforms ;)

 

'course you do, obnoxious questions are half the fun of speaking at 
developer groups! :-)

As for the specifics of what you're running into, I don't really know 
anything about the ColdFusion implementation but I suspect this may be 
one of the examples of why the trend is away from rpc/encoded and toward 
doc/literal. Most of the existing stuff is written to the rpc/encoded 
style, which basically takes the parameters to a method call and 
translates them into XML in a manner that's supposed to be 
cross-language and cross-platform. The problems with that are (1) it's 
pretty much impossible to do a cross-language and cross-platform data 
representation that goes beyond the basics and actually have it work 
well, and (2) it exposes too much information about your implementation 
structure as part of the interface, and that implementation may not be 
appropriate for developers on a different language or platform. I assume 
that's probably what you're trying to work with.

doc/lit basically says ignore the implementation and specify the XML. 
That means you just have a schema description of the data going in each 
direction, and it's up to the applications on each end (or the 
frameworks, more often) to translate that to something useful. For what 
you're describing a doc/lit approach should work a lot better than 
rpc/enc. JAX-RPC RI has decent doc/lit support built in; don't know 
about ColdFusion. If it's based on the Axis code (which I suspect it is 
- several of the Macromedia people are major participants on Axis), 
you're probably going to have problems - they're finally getting some of 
the doc/lit problems cleaned up in the current 1.2 version, but it's 
still messy even there and anything actually being shipped is likely to 
be the old 1.1 code. I'll definitely discuss why it's a mess and what to 
do for workarounds next week, but don't know how much that will help for 
working within the ColdFusion framework.

 - Dennis

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


[jug-discussion] ColdFusion from JAXRPC

2004-05-03 Thread Duffy Gillman

I've run into a snag trying to play friendly with some ColdFusion 
developers where I work and was hoping someone in the JUG would have some 
input.  My situation is this: I am writing a web application that draws 
resources from several other tools within my department (Learning 
Technologies at the U of A).  All players are willing to create web 
services for me to talk to.  So my thought was gee, it would be great if 
everyone shared the same WSDL file and the others implemented their 
services to match it.  [Cut to scene of streets paved with gold, 
ethereal harp music and cats and dogs living in harmony.]

My first group of collaborators are ColdFusion developers.  They are adept 
at creating web services.  Unfortunately they are only adept at making web 
services that they control - making a service that fits with someone 
else's WSDL seems a stretch too far.  In my pollyannaish way I like to 
think that it should be possible to take the JAXRPC-generated WSDL that 
fits my wonderful Java object model and run a magical script that will 
generate template code for implementing the service in ColdFusion.  
Likewise, I like to believe, it should be possible to run a similar 
script on the Java side that would create (potentially poorly factored) 
Java interface and class templates that would implement the service 
described by the WSDL.

Barring these fantastical scripts, I would like to believe that all WSDLs 
are at least mutually producable/expressable by the various leading 
platforms for web service development.  As I grow more hardened and jaded 
I begin to believe this is more wishful thinking.  In Java my model has 
many Exception objects in a nice neat semantically organized hierarchy.  
But the CF developers seem stymied and unable to produce CF components 
that generate WSDL with anything other than CFInternalException (or 
something) messages - and no real subclasses thereof.  There is an 
expressed willingness to reverse engineer the CF components from the WSDL 
if all elements of the WSDL can be reliably bound - but so far there have 
been no breakthroughs.

So far I've wished real hard, crossed my fingers and held my breath.  
Neither these nor scouring newsgroups and tutorial sites have yielded the 
tools nor tutorials I imagine.  So I thought to put this to the group.  
Has anyone ventured to implement the same web service on different 
platforms (ideally JAXRPC and ColdFusion)?  Am I the only wingnut out 
there who wants to treat WSDL as an interface definition for multiple 
services (I *can't* be, but hope I'm not the only one here)?  Is it 
possible to get ColdFusion to produce errors (SOAP fault messages) that 
match up with those in a Java-derived WSDL document?

I'd be interested in whatever experieces y'all have had.

-Duffy

P.S.  If I put down a vote for Dennis for the full meeting, do I get to 
ask obnoxious questions about sharing WSDL files between platforms ;)

Either way put me down +1 for Dennis and +1 for 'Advanced Issues'



-- 




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]