RE: [stp-dev] Java First Programming Model Refactor

["Mark Walker" <mwalker@xxxxxxxxxxxxxxxxxxxx>]

>> -----Original Message-----
>> From: stp-dev-bounces@xxxxxxxxxxx 
>> [mailto:stp-dev-bounces@xxxxxxxxxxx] On Behalf Of Oisin Hurley
>> Sent: 26 September 2007 10:00
>> To: STP Dev list
>> Subject: Re: [stp-dev] Java First Programming Model Refactor
>> 
>> > Sounds like a job for... EMF. Perhaps we should introduce 
>> an EMF based 
>> > Customizable WSDL2Java, Java2WSDL tool, and not just pass 
>> through to 
>> > the underlying implementation. Leaving the templates open 
>> to further 
>> > customization. That way, domain/application specific WSDL could be 
>> > generated.
>> 
>> Just the sort of thing I was thinking of, Mark :)  I know 
>> that Ed Merks has created an EMF model for WSDL 2.0, which 
>> I'm sure already holds a Schema model and could very well be 
>> compatible with the WSDL 1.1 that is in the greatest usage today.
>> 
>> Making a WSDL code generator using this EMF model at the 
>> core would be cool. Make it an OSGI application and we have 
>> this nice feature where we can run it as a command-line java 
>> application, or just pull in the model part and make it part 
>> of the Eclipse UI. The backend generation could even be 
>> replaceable, using OSGi service techniques for general 
>> applicability (or extension points if we want to be more 
>> tightly bound to Eclipse). Same goes for the front end of 
>> course - it would be relatively straightforward to construct 
>> a DSL that we would translate to the WSDL model for use with 
>> existing tools. This might save developers some grief.
>> 
>> Now for the dark side of the equation: there are hundreds of 
>> people who have put tens of thousands of hours into the 
>> several dozen WSDL2Mumble generators out there. They 
>> probably don't want to do it all again, or port it :) That 
>> being said, it probably makes sense for companies to think 
>> about bringing in a WSDL processing framework, since that 
>> isn't a competitive element in their products.
>> 
>>   cheers
>>    --oh
I agree, that is the current major drawback: existing tools.

However, the ideal of allowing developers using the tool to customize
the tool to suit their domain/application needs is a major win - and
would increase the chances of adoption of that tool. 

Depending on how much "buy in" we could get from the general WS
community (notwithstanding the concerns of existing JEE/WS vendors) the
win/win would be that future versions of their tools could be
produced/maintained by the Open Source community.

Ciao,
Mark Walker,
Technical Architect (Tools),
Ubiquity Software (Avaya UK),
Cardiff

"It takes less time to do a thing right than to explain why you did it
wrong."
-- H. W. Longfellow. 



Information contained in this e-mail and any attachments are intended for the use of the addressee only, and may contain confidential information of Ubiquity Software Corporation. All unauthorized use, disclosure or distribution is strictly prohibited.  If you are not the addressee, please notify the sender immediately and destroy all copies of this email. Ubiquity Software Corporation plc, a company registered under the laws of England and Wales, Registration 2719723, registered offices at Eastern Business Park, Building 3, Wern Fawr Lane, St. Mellons, Cardiff CF3 5EA, Wales, United Kingdom.