Hi Keith,
Thanks for getting back to me. Yes, that article floated to the top when
I google searched the subject the other day. And in fact WebObjects' web
services support is actually Axis under the hood.
But our existing, working web services was implemented before WO added
web services support. The concern is that moving our current
infrastructure might be challenging and beyond the scope of what we can
do at the moment.
Also, I'm concerned that if we use Axis that it's unclear how we'd
continue to use SOAP embedded in a dsig. I think that any SOAP server
approach will require us to use actual SOAP back and forth, which means
we'd have to move both ourselves and our clients to signed SOAP (ala
Oasis). While this might be a good long term direction, it would be very
disruptive at this point.
So considering that we have limited changes possible and an existing web
services infrastructure that works, I think it would be safer and more
pragmatic to just extend our current implementation. That's why I've
been looking at Castor to help move us deal with the XML validation,
marshaling and unmarshaling.
Best regards,
--
Allen Cronce
Keith Visco wrote:
Hi Allen,
Have you seen the following:
http://www-128.ibm.com/developerworks/webservices/library/ws-castor/
--Keith
Allen Cronce wrote:
Hi all,
We're looking to extend an existing WebObjects-based services
application to support additional SOAP methods. I had a good experience
with Castor in the past for another project, so I'm considering using it
for this project to generate Java classes that support the unmarshalling
and marshalling of our SOAP requests and responses. At this stage I'm
looking for some advice regarding overall direction.
First off, I should mention that our current web services interface
requires that the SOAP be digitally signed. Historically we've done this
by embedding the SOAP in a standard signed XML document. We went with
this direction originally because the signed XML standard was well
defined at the time, while signed SOAP was not. In any case, all
requests to our web services consists of a SOAP method riding in a
standard SOAP body/envelope, which in turn is embedded in a signed XML
dsig element.
Given the above design constraint, what should be the scope of our
Castor-generated sources? Should we try and import the XML signature and
SOAP standard schemas into our schema, then generate Java sources that
include these standards' objects as well as ours? From what I've read on
the archives, this might be a bad idea. One poster indicated that he had
problems generating working Java sources from the XML signature schema.
Also, this seems like overkill since we already have a solution for
validating and creating signed XML, so access to the XML signature
elements via a Castor-generated Java interface is not very useful.
Alternatively, we could simply limit our use of Castor to unmarshal and
marshal our specific SOAP methods. This way, we'd validate the signed
XML as we do today, then locate the contents of the SOAP body, and use
Caster to unmarshal from there. Marshalling would go in reverse where we
create a set of Castor objects and marshal them into a fragment in the
body, then embed the resulting SOAP in a signed document. I think that
this is probably the most sensible approach.
If anyone has any comments or thoughts regarding the best direction, I'd
appreciate it.
Best regards,
--
Allen Cronce
-------------------------------------------------
If you wish to unsubscribe from this list, please send an empty
message to the following address:
[EMAIL PROTECTED]
-------------------------------------------------
-------------------------------------------------
If you wish to unsubscribe from this list, please send an empty
message to the following address:
[EMAIL PROTECTED]
-------------------------------------------------
-------------------------------------------------
If you wish to unsubscribe from this list, please
send an empty message to the following address:
[EMAIL PROTECTED]
-------------------------------------------------
