Return-Path: Delivered-To: apmail-ws-axis-user-archive@www.apache.org Received: (qmail 9271 invoked from network); 24 Mar 2005 23:10:27 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 24 Mar 2005 23:10:27 -0000 Received: (qmail 95454 invoked by uid 500); 24 Mar 2005 23:10:06 -0000 Delivered-To: apmail-ws-axis-user-archive@ws.apache.org Received: (qmail 95392 invoked by uid 500); 24 Mar 2005 23:10:06 -0000 Mailing-List: contact axis-user-help@ws.apache.org; run by ezmlm Precedence: bulk Reply-To: axis-user@ws.apache.org list-help: list-unsubscribe: List-Post: Delivered-To: mailing list axis-user@ws.apache.org Received: (qmail 95316 invoked by uid 99); 24 Mar 2005 23:10:06 -0000 X-ASF-Spam-Status: No, hits=0.1 required=10.0 tests=FORGED_RCVD_HELO X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: local policy) Received: from stamsmtp1.paymentech.com (HELO stamsmtp1.paymentech.com) (12.96.58.25) by apache.org (qpsmtpd/0.28) with ESMTP; Thu, 24 Mar 2005 15:10:04 -0800 Received: from stamsmtp2.paymentech.com (stamsmtp2.paymentech.us [10.21.54.26]) by stamsmtp1.paymentech.com (8.12.10/8.12.10) with ESMTP id j2OL684k024909 for ; Thu, 24 Mar 2005 16:06:08 -0500 (envelope-from Sam.Ayers@paymentech.com) Received: from sTamExchange1.paymentech.us (stamexchange1.paymentech.us [172.16.52.8]) by stamsmtp2.paymentech.com (8.12.11/8.12.11) with ESMTP id j2OL68DY007510 for ; Thu, 24 Mar 2005 16:06:08 -0500 (envelope-from Sam.Ayers@paymentech.com) X-MIMEOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: possible ways of creating WSDL file Date: Thu, 24 Mar 2005 16:06:08 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: possible ways of creating WSDL file Thread-index: AcUwpexF0Q9HuYNBS2+FSm5w0RfR4AADOYNA From: "Ayers, Sam" To: X-Virus-Checked: Checked X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Venkat, At this point, I believe we are "violently agreeing with each other" :-) T= hat's an expression a friend of mine used to use when we seemed to be debat= ing an issue, but then realize we are agreeing with each other :-) I am all for beginning with an interface design, then fleshing out the desi= gn. But, then use round-trip tools to keep the implementation (code) in sy= nch with the design. Now, for legacy systems that we are encapsulating with web services - and w= e must agree that much of the serious web services work will encapsulate le= gacy systems - I have found it easier to code a java interface and implemen= tation, then generate the initial WSDL from the code. But I consider this = just a way to quickly generate a "starting point" for the WSDL. After that= , the wsdl stands alone, and can be iteratively refined. I will admit that I am biased toward the notion that I have lots of legacy = systems to be served up via new web services. And I might take a more "top= -down, structured, waterfall" approach if it weren't for those darned legac= y systems ;-) But, whatever the case, I believe rapid iterative development is the way to= develop and refine WSDL. So, I believe tools that operate like java2wsdl = and wsdl2java should be kept as an important part of a toolset that would a= lso include the upfront schema generation tools. Sam -----Original Message----- From: Venkat Reddy [mailto:vreddyp@gmail.com] Sent: Thursday, March 24, 2005 2:16 PM To: axis-user@ws.apache.org Subject: Re: possible ways of creating WSDL file Regarding errors due to manual creation of WSDL, use graphical WSDL editors instead. I also think that the text version of a WSDL document is analogous to serialized form of a database schema, or a use case or a class diagram. Create and manipulate, and generate code from all these the same way. I agree with you that Java2WSDL is good for prototyping. I also think it is useful where web service facade is an after-thought for existing systems, and another use is to update WSDL document to reflect changes in the code any time. However, if we consider iterative development, then the question is the same as - do we do the class diagrams to start with or write the code first, assuming we have tools to generate one from the other. I would say we need minimal design artefacts to start with, to express end-to-end working of a system, then fill in the details as the implementation goes on. But the overall integrity of the system is the reponsibilty of the design and not the implementation. So the design tends to dictate implementation, though it builds up from fedback. -venkat On Thu, 24 Mar 2005 09:58:23 -0500, Ayers, Sam w= rote: > Then, are you saying java2wsdl should not even exist as a tool? >=20 > Again, take the analogy of round-trip software engineering (model driven = architecture). You change your system by modifying the diagrams, generatin= g the code, or, conversely, by modifying your code, generating the diagrams. >=20 > For a new model-driven project, up-front you start with diagrams - i.e. t= he "forward-engineering path". Then, at some point later, you modify the c= ode and regenerate the diagrams from the code. >=20 > Another analogy is iterative development. With iterative development, it= really doesn't matter how you get to your requirements, so long as you do = get to them within the time and cost constraints of your project. Sometime= s in order to produce good requirements quickly, you must do some rapid pro= totyping. >=20 > This same idea applies to WSDL. Sometimes, in order to get good WSDL qui= ckly, you must do some rapid prototyping. The wsdl generation from code he= lps greatly in this process. You just have to make sure that before the pr= oject is deeply into coding, and before outside vendors or partners have be= en asked to develop to your wsdl, that everyone agrees to the wsdl, and tha= t the wsdl meets the interoperability requirements of your project. >=20 > Sam >=20 > -----Original Message----- > From: Venkat Reddy [mailto:vreddyp@gmail.com] > Sent: Thursday, March 24, 2005 8:08 AM > To: axis-user@ws.apache.org > Subject: Re: possible ways of creating WSDL file >=20 > I agree with Anne. At design level, stuff like WSDL, database schema, > interfaces with existing systems and workflow constitute the overall > system design. And all of them are participants and pieces in the > pipeine in ensuring the integrity of the overall system. Java > interfaces are just one kind of implementation that follow the design. > They should not dictate the WSDL, unless the design is being reverse > engineered from java code. Iterative approach for WSDL is just as good > as it is for designing a database - i mean, we need it in right > amount. >=20 > jmho, > -- venkat >=20 > On Thu, 24 Mar 2005 07:37:02 -0500, Ayers, Sam = wrote: > > I believe you are all correct, from different perspectives. But, I bel= ieve one must take into account the same lessons learned from "round-trip" = engineering in software development. > > > > 1) If it is a new system, starting from scratch, and involving heteroge= neous systems integration, yes, it is best to focus on the interface early = in the lifecycle, and perhaps design the WSDL before coding. After the WSD= L is "roughed-in", use the round trip tools (wsdl2java) to maintain. > > > > 2) If the system involves extension of an existing legacy code base it = is practical to "reverse engineer" the interface from the code, starting wi= th code and generating the wsdl. Then, you can maintain the wsdl by editin= g the wsdl, or by editing the code, and using the round-trip tools to keep = them in synch. > > > > 3) For expert developers who are relatively new to web services and SOA= P (i.e. exactly the audience we are trying to bring up to get on board) I b= elieve writing WSDL from the get-go is impossible. You must start from cod= e, generate the wsdl, then hopefully learn-by-doing by examining the output= wsdl, and maintaining it moving forward. Insisting that expert developers= start by creating wsdl is somewhat akin to the round-trip engineering "par= alysis by analysis". You'll end up spending large amounts of time trying t= o create and perfect the WSDL, while in the end the project fails because y= ou took too long analyzing and creating the interface. > > > > So, I believe the answer is in "rapid iteration", i.e. successive appro= ximation utilizing both techniques, and choosing the right one at the right= moment. To insist on working WSDL before a project begins, especially for= legacy systems integration, is somewhat akin to following the "waterfall m= odel" of software development. Instead, we need to be flexible, rapidly it= erate, and judiciously use all tools at our disposal. > > > > Sam > > > > -----Original Message----- > > From: Anne Thomas Manes [mailto:atmanes@gmail.com] > > Sent: Wednesday, March 23, 2005 6:02 PM > > To: axis-user@ws.apache.org > > Subject: Re: possible ways of creating WSDL file > > > > In a better world, you have a XML Schema administration team (similar > > to your DBA team) that is responsible for developing the schemas that > > applications will communicate with. (Do your developers define their > > own database schemas???) > > > > When developers build services, they should be handed the schemas they > > are supposed to use, and then map those schems to their code. > > > > Developers should not generate WSDL from code. > > > > Anne > > > > On Wed, 23 Mar 2005 14:55:38 -0800, Tim K. (Gmane) wrote: > > > In an ideal world I would agree with Anne. However, consider this > > > scenario: you have a team of 10+ developers working on a server side = API > > > that follows the rules to allow it to be easily exposed as web servic= es. > > > The API has over 200+ methods total, distributed over 20+ modules. Ea= ch > > > module would be exposed as a web service, hence 20+ WSDL files. The g= oal > > > is to have the API on the server side look exactly the same as the API > > > on the client side, so in theory an application built against the API > > > could be run in process on the server or remotely via web services. > > > > > > Now, only a couple of these developers know anything about web servic= es > > > and even those developers are just getting their feet wet with web se= rvices. > > > > > > During the development cycle the API's can (slightly) change many tim= es > > > a day and everything needs to be recompiled/regenerated. I think it's > > > unreasonable in this case to edit any generated WSDL files by hand. I= t's > > > much more reasonable to just fire an ant task that starts with the > > > server side java classes, generates the WSDL's and from those the cli= ent > > > side stubs. This improves the development process a lot. > > > > > > I hope I'll live to see the day when the tools are good enough to > > > achieve this task end to end. Obviously we are not there yet, but we = are > > > getting close. > > > > > > Btw, this is not an imaginary scenario, it's the cruel reality I live= in > > > every day. > > > > > > Tim > > > > > > Anne Thomas Manes wrote: > > > > I strongly disagree with Sunil. WSDL First (TM) is the way to go. > > > > > > > > I think it's okay to use java2wsdl to generate a WSDL template to > > > > start with, but you should always edit the generated WSDL. > > > > > > > > My recommendation is to use a WSDL editing wizard. Cape Clear provi= des > > > > a free one (SOA Editor). Altova and Sonic provide commercial ones. > > > > > > > > Anne > > > > > > > > > > > > On Wed, 23 Mar 2005 13:49:53 -0500, Soti, Dheeraj wrote: > > > > > > > >>Sunil, > > > >> > > > >>Will java2wsdl create the complex type hierarchies correctly? I hav= e a complex > > > >>class hierarchy (using inheritance and nested classes) and finally = I ended up > > > >>handcoding the wsdl from scratch. Did I miss something? I've also r= ead some best > > > >>practice articles talking about top down approach where u write you= r wsdl first > > > >>and then proceed. > > > >> > > > >>Thanks > > > >> > > > >>Dheeraj > > > >> > > > >>-----Original Message----- > > > >>From: Sunil Kothari [mailto:sunil.kothari@majoris.com] > > > >>Sent: Wednesday, March 23, 2005 1:20 AM > > > >>To: axis-user@ws.apache.org > > > >>Cc: hamza.hydri@gmail.com > > > >>Subject: Re:possible ways of creating WSDL file > > > >> > > > >>I think of 3 ways of creating WSDL > > > >>1) Using java2wsdl tool > > > >>2) Using .jws facility > > > >>3) Handcode WSDL > > > >> > > > >>I think 3) is error-prone and requires high level of understanding = of > > > >>WSDL. 2) is also not recommended for various reasons like > > > >>a) No deployment descriptors are created > > > >>b) WSDL is not persistent and prone to changes > > > >>c) (This I am not sure) For overloaded methods this way of creation > > > >>causes problems. > > > >> > > > >>I hope this helps. > > > >> > > > >>Sunil Kothari > > > >>Valtech India > > > >> > > > >>DISCLAIMER: > > > >> Any Information contained or transmitted in this e-mail and / or > > > >>attachments may contain confidential data, proprietary to Majoris > > > >>Systems Pvt Ltd., and / or the authors of the information and is > > > >>intended for use only by the individual or entity to which it is > > > >>addressed. If you are not the intended recipient or email appears > > > >>to have been sent to you by error, you are not authorised to access, > > > >>read, disclose, copy, use or otherwise deal with it. If you > > > >>have received this e-mail in error, please notify us immediately at > > > >>mail to: sysadmin@majoris.com and delete this mail from your record= s. > > > >> > > > >>This is to notify that Majoris Systems Pvt Limited shall have no > > > >>liability or obligation, legal or otherwise, for any errors, > > > >>omissions, viruses or computer problems experienced as a result of > > > >>this transmission since data over the public Internet cannot be > > > >>guaranteed to be secure or error-free. > > > >> > > > > > > > > > > > > > > > > > > Learn more about Paymentech's payment processing services at www.paymen= tech.com > > THIS MESSAGE IS CONFIDENTIAL. This e-mail message and any attachments = are proprietary and confidential information intended only for the use of t= he recipient(s) named above. If you are not the intended recipient, you ma= y not print, distribute, or copy this message or any attachments. If you h= ave received this communication in error, please notify the sender by retur= n e-mail and delete this message and any attachments from your computer. > > .. > > >=20 > Learn more about Paymentech's payment processing services at www.paymente= ch.com > THIS MESSAGE IS CONFIDENTIAL. This e-mail message and any attachments ar= e proprietary and confidential information intended only for the use of the= recipient(s) named above. If you are not the intended recipient, you may = not print, distribute, or copy this message or any attachments. If you hav= e received this communication in error, please notify the sender by return = e-mail and delete this message and any attachments from your computer. > .. > =20=20 Learn more about Paymentech's payment processing services at www.paymentech= .com THIS MESSAGE IS CONFIDENTIAL. This e-mail message and any attachments are = proprietary and confidential information intended only for the use of the r= ecipient(s) named above. If you are not the intended recipient, you may no= t print, distribute, or copy this message or any attachments. If you have = received this communication in error, please notify the sender by return e-= mail and delete this message and any attachments from your computer. ..