[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xmlbeans-dev
Subject:    Re: Generating interfaces from WSDL using XMLBeans
From:       Christopher Eliot <eliot () cs ! umass ! edu>
Date:       2004-09-19 13:50:59
Message-ID: F049A1AA-0A42-11D9-B08F-000A95B3E4B6 () cs ! umass ! edu
[Download RAW message or body]

On Sep 19, 2004, at 7:11 AM, robert burrell donkin wrote:

> On 17 Sep 2004, at 08:53, James Strachan wrote:
>> On 17 Sep 2004, at 00:44, Dmitri.Colebatch@toyota.com.au wrote:
>
> <snip>
>
>>> where abouts would an xmlbeans generated
>>> implementation fit in?  I don't see that asking the user to write a 
>>> simple
>>> servlet that parses its input and forms a response is that difficult.
>>
>> That is fine for pure HTTP based transports; but SOAP can work over 
>> JMS, SMTP, Jabber etc. So all I'm after is a POJO model that uses 
>> XMLBeans that developers can write the business logic to then drop it 
>> into a SOAP stack which handles the headers/roles/mustUnderstands 
>> properly, does the servlet/JMS/SMTP/Jabber stuff and delegates to the 
>> POJO.
>
>
> +1
>
> i think that there definitely is a spare niche in the ecology for some 
> kind of instant SOAP.
>
> it seems to me that SOAP isn't used as frequently as it might in 
> mainstream J2EE development. i've seen a number of home-grown 
> solutions where document-centric SOAP messaging would be a better fit. 
> i suspect that one of the main reasons is the high knowledge barrier. 
> frameworks take quite a lot of learning to be used effectively.  yes, 
> developers can always roll their own but that means learning and 
> understanding the SOAP specification completely. instant SOAP would 
> allow J2EE developers to quickly add SOAP to mainstream J2EE 
> applications without having to spend too much time learning SOAP and 
> without having to commit to a particular transport mechanism.

I looked at SOAP some time ago and didn't pursue it in large part 
because of security concerns.
I was able to get it going with TOMCAT/AXIS fairly easily, but there 
seemed to be lots of simple
ways to make a serious mistake that would leave a server wide open. 
Learning to make it work
was not a barrier, but learning enough to feel safe about it seemed 
like a big barrier.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org

[prev in list] [next in list] [prev in thread] [next in thread]