No, Jibx2Wsdl works fine with 1.4.x code and JVMs. The support for Java
5 features is strictly optional, and just means that if you *are* using
these features Jibx2Wsdl will make use of the added information.
--
Dennis M. Sosnoski
SOA and Web Services in Java
Axis2 Training and Consulting
http://www.sosnoski.com - http://www.sosnoski.co.nz
Seattle, WA +1-425-939-0576 - Wellington, NZ +64-4-298-6117
[EMAIL PROTECTED] wrote:
Thanks Dennis,
That's very helpful. I looked up jibx2wsdl, and found that it "has support for Java
5 enumerations and generic collections". Does that mean that Java 5 is required? I
have to stick with Java 1.4.2 for now because working for the Canadian government means
working amongst glaciers and dinosaurs!
cheers
md
-----Original Message-----
From: Dennis Sosnoski [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 29, 2007 3:16 PM
To: [email protected]
Subject: Re: Recommendations for a new project?
Hi Michael,
There are no magic bullets when it comes to doing WSDL.
Contract-first
is great in theory, and is pretty much the only way to do things in
cases where you're dealing with different groups in
developing services
to be used organization wide. However, the tools that are
available to
support editing WSDLs and schemas are really very primitive, and you
need to have a good understanding of what you're doing in
order to make
effective use of these tools. For WSDL this isn't too bad,
but schema is
very complex and has a steep learning curve. So if you want to do
contract-first development correctly, expect to spend a
couple of weeks
on researching and learning the basics of schema beforehand.
Think of it this way - would you sign a contract that was
written in a
language you couldn't read, under the legal system of a country you
weren't familiar with? If the answer is "no", then you should
expect to
have to learn WSDL and schema regardless of whether you're using
"contract-first" or "code-first" service development.
There's a lot of confusion over just what is meant by code-first vs.
contract-first development. I saw a recent posting on this list that
pointed at the Spring (mis)information on this topic, which
assumed that
code-first meant the WSDL and schema was effectively always generated
on-the-fly from the current code, so that any time the code
changed the
WSDL and schema would also change. That's effectively what
was done by
the deprecated rpc/enc style of SOAP, and I agree completely
that this
is unworkable for any serious enterprise use.
I'd define code-first differently, to say that it means you
start with
template code and use that to generate a WSDL and schema definition,
which can then be used directly or modified as appropriate.
But whether
used directly or modified, what you end up with is a WSDL and schema
that are "fixed" definitions for the service (meaning that
they are part
of the service contract, and changing these becomes a service
versioning
issue). Based on what I've seen this is actually the approach
used for
the majority of real-world web service development. The
Jibx2Wsdl tool
(http://www.sosnoski.com/jibx-wiki/space/axis2-jibx/jibx2wsdl) is
designed around this principle, and if you're considering
using JiBX you
may want to look into using the tool since it handles JiBX binding
generation, as well as WSDL and schema generation, from
existing code.
The current version of the tool is an early release, and I
expect do an
update within the next week.
- Dennis
--
Dennis M. Sosnoski
SOA and Web Services in Java
Axis2 Training and Consulting
http://www.sosnoski.com - http://www.sosnoski.co.nz
Seattle, WA +1-425-939-0576 - Wellington, NZ +64-4-298-6117
[EMAIL PROTECTED] wrote:
To me, Contact-First makes perfect sense. I haven't heard
the Axis experts say "No No No!" yet, so I figure I'll go with that.
thanks
md
-----Original Message-----
From: Luis Mariano Luporini [mailto:[EMAIL PROTECTED]
Sent: Monday, May 28, 2007 1:17 PM
To: [email protected]
Subject: Re: Recommendations for a new project?
Michael:
I'm having this kind of questions as you stated in
your mails.
And think, probably, the better one would be to go with a
'Contract-First' approach to keep the environment
controlled when one
needs to implement features/changes. This way your clients
will be happy
to get a consistent WSDL across releases.
But anyway I would like to hear your points on this.
Please, let
know if you come to some conclusions.
Thanks,
Luis
[EMAIL PROTECTED] escribió:
Ok, thanks again
-----Original Message-----
*From:* robert lazarski [mailto:[EMAIL PROTECTED]
*Sent:* Monday, May 28, 2007 12:36 PM
*To:* [email protected]
*Subject:* Re: Recommendations for a new project?
JIBX has its own site and docs - I'd follow those to
get on the
right track.
Robert
On 5/28/07, [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>*
<[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Thanks very much. I am using Hibernate and
fortunately I have
complete control over the schema, so I'll check out jibx.
So assuming I'm creating my own wsdl and will use
jibx, would
you generate code using wsdl2java or would you start from
scratch? I suspect that starting from scratch
will allow for
cleaner and simpler code in the long run, because as the
number of operations grows then there will be more
opportunities for refactoring code rather than
having lots of
redundant generated code, am I right?
cheers
md
-----Original Message-----
*From:* robert lazarski
[mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>]
*Sent:* Monday, May 28, 2007 12:18 PM
*To:* [email protected]
<mailto:[email protected]>
*Subject: *Re: Recommendations for a new project?
From what you say I'd go with ADB
databinding, creating
and validating your WSDL via eclipse's WST. If you are
using hibernate / jdo and such, I'd consider
jibx. If you
have complex schemas out of your control -
which is often
the case for me - use xmlbeans. Either way,
starting with
the WSDL for a 'contract first' approach is
often a good
choice.
If you've never done single sign on before I
recommend CAS:
http://www.ja-sig.org/products/cas/
See rampart for ws-security - available for
axis2 1.1.1 .
Search the archives for questions related to
soap headers
as the subject comes up frequently.
HTH,
Robert
On 5/28/07, [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>*<[EMAIL PROTECTED]
icecanada.gc.ca
<mailto:[EMAIL PROTECTED]>> wrote:
I forgot to mention, in case it's
important. I'm using
axis2 1.1.1, because due to circumstances
beyond my
control, I'm forced to use jdk 1.4.2 and WebSphere
6.1, and I couldn't get axis2 1.2 to work
with that
combination.
md
> -----Original Message-----
> From: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> [mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>]
> Sent: Monday, May 28, 2007 11:44 AM
> To: [email protected]
<mailto:[email protected]>
> Subject: Recommendations for a new project?
>
>
> Hi,
>
> I apologize in advance for a slightly
rambling and
unfocussed
> request for advice. The short questions
are: if you are a
> really experienced Axis user, and are starting a
brand new
> project, would you write everything from scratch
using Axiom?
> Would you use one of the data binding
libraries such
as JiBX?
> Would you maintain your wsdl/xsd files by hand?
>
> Now for the long version:
>
> I'm new to Axis and web services, but have been
programming
> Java for several years.
>
> I'm working on a simple web service that
provides a
> single-sign-on for our organization's
applications.
The first
> operation I'm working on is very simple
- it just
takes three
> strings (user name, password and
application name) and
> returns a string containing a list of
permissions.
>
> It works fine, but I've implemented it using the
easiest way
> possible. I just wrote a POJO class
with a method
>
> String authenticate( String, String, String )
>
> and ran Java2Wsdl using the basic
defaults. I don't
> explicitly use any of the Axis apis.
>
> However, looking to the future, I can see
where I'll
> eventually need to take more control, for
example I might
> want to manipulate the SOAP headers and/or use
WS-Security,
> and I'll probably eventually want to pass
around more
> complicated structures than strings.
>
> So I'm trying to determine the best
strategy. I'm
slightly
> bewildered with all of the choices:
>
> 1. Should I write the clients and services from
scratch using
> the axiom libraries, or generate the stubs and
skeletons?
>
> 2. If I write them from scratch, and
already have my own
> model classes (representing such things
as users),
should I
> use one of the data binding libraries
such as XMLBeans or
> JiBX? If so, which one?
>
> 3. Should I be maintaining my wsdl file
(and included
schema
> files) by hand (or using an appropriate
editing tool) in
> order to maitain control over the various
types, as
opposed
> to generating it using Java2Wsdl every time the
interface changes?
>
> I can see that the Axis developers have
tried hard to
provide
> a spectrum of methods and interfaces from the
easy/simple to
> the complex/powerful. But I'd be very
interested to
know what
> methods a really experienced Axis user
would use.
>
> Many thanks,
> Michael Davis
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail:
[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
