Hi Bob,
The approach I've used for several clients in similar situations is to
write an adapter that on one side talks either plain XML or some other
format to the existing code, and on the other talks SOAP. If you want
the full range of SOAP add-on support (including WS-ReliableMessaging
and the like) you'd be best off writing the adapter as an Axis2
application. If you just want SOAP and perhaps WS-Security, writing code
that works directly with the XML is in my experience simpler and more
robust. That said, I haven't tried interfacing to DCOM. It looks like
there are a few ways of doing this, and some searching should let you
narrow down the best approach for your needs.
Why use custom code for SOAP handling, rather than going through Axis2?
This is really just an issue of usage. Axis2, like most SOAP frameworks,
is primarily oriented toward working with the SOAP Body content as
objects. That's exactly what most developers want to do, but in the case
where data is being passed to another application you're generally just
converting the XML to some other format. If that's the case, the
framework code can add overhead and complexity without providing much
useful functionality.
I not sure what you mean by the support overhead question, but if you
can be more specific I'll try to come up with an answer.
- Dennis
Dennis M. Sosnoski
SOA, Web Services, and XML
Training and Consulting
http://www.sosnoski.com - http://www.sosnoski.co.nz
Seattle, WA +1-425-296-6194 - Wellington, NZ +64-4-298-6117
Bob McConnell wrote:
Good morning,
I am part of a team evaluating options for web services. We are looking
for a way to provide a SOAP style front end for an existing transaction
processor (TP). I am trying to find out what server options we have.
This project is an attempt to provide a standardized front end to
replace several custom interfaces. The service definition will only be
provided to third party application developers with a need to post
transactions to our servers. Those will be web servers, POS servers and
other application servers.
The service will only be available to a few selected clients at each
location. All connections must be secure, and client authentication is
more important than server authentication. In addition, each client will
only be able to use a specific subset of functions available on the TP.
So there must be a way to tell the server which client sent each
transaction. This must run on a Microsoft Windows server, and the
interface to the TP is through DCOM objects.
Is Axis2, in its current state, likely to be able to satisfy these basic
requirements? We did look at Axis, which looked like it would work. But
it does not support the client authentication we need.
How much support overhead will there be to maintain 800 or so servers
scattered all over North America?
What is the quickest path to building a test server to evaluate this
option?
Thank you,
Bob McConnell
Principal Communications Programmer
The CBORD Group, Inc.
61 Brown Road
Ithaca NY, 14850
Phone 607 257-2410
FAX 607 257-1902
Email [EMAIL PROTECTED]
Web www.cbord.com
---------------------------------------------------------------------
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]
