axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Sosnoski <...@sosnoski.com>
Subject Re: Evaluation of application
Date Mon, 30 Oct 2006 09:27:46 GMT
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 rvm@cbord.com
> Web www.cbord.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>
>   

---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org


Mime
View raw message