You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by Bob McConnell <rv...@CBORD.com> on 2006/12/07 16:30:30 UTC
RE: Evaluation of application
I am sorry for resurrecting an old thread, but there is a question
remaining that I would like some guidance on.
Support Overhead: After we implement this interface, it will have to be
deployed onto several hundred transaction servers. The initial
installation will need to install all of the framework components onto
Win2K and 2K3 servers. Most of this will be managed by our support
specialists, with the physical tasks of inserting a CD and running the
install scripts done by the local system operators. Updates and bug
fixes will have to be done either by mailing CDs or connecting to each
server with a VNC and manually doing the updates.
Can anyone provide a reasonable guess of how many support man-hours will
be required for each deployed server to install and then maintain the
Axis 2/Tomcat/Apache framework?
Thank you,
Bob McConnell
> -----Original Message-----
> From: Dennis Sosnoski [mailto:dms@sosnoski.com]
> Sent: Monday, October 30, 2006 4:28 AM
> To: axis-user@ws.apache.org
> Subject: Re: Evaluation of application
>
> 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
Re: Evaluation of application
Posted by Martin Gainty <mg...@hotmail.com>.
Hi Bob-
If you get a chance to Read charlie calvert's article located at http://bdn.borland.com/article/31871
you'll see the statement
"Web Services differ from RMI, DCOM, CORBA, and RPC in that they are specifically designed to work with an XML based technology called SOAP. The great advantage of an XML based technology is that it need not be language or platform specific"
By implementing thru COM (as dennis mentioned) you will either have to :
-write your own COM provider or
-purchase/install/configure a 3rd party COM provider
One COM provider is located here
http://documentation.softwareag.com/crossvision/eli/webservices/services.htm#WS_Runtime_for_DCOM
The tradeoffs are time vs budget where if you're short on time you're probably better off purchasing the provider which is a ready to go solution
If you have some time and or perhaps a stricter budget which doesnt accomodate 3rd party software (be aware you'll probably need a newer version
every time you upgrade Tomcat and or Axis versions) then I would look into writing your own COM provider
HTH,
Martin --
---------------------------------------------------------------------------
This e-mail message (including attachments, if any) is intended for the use of the individual or entity to which it is addressed and may contain information that is privileged, proprietary , confidential and exempt from disclosure. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited.
---------------------------------------------------------------------------
Le présent message électronique (y compris les pièces qui y sont annexées, le cas échéant) s'adresse au destinataire indiqué et peut contenir des renseignements de caractère privé ou confidentiel. Si vous n'êtes pas le destinataire de ce document, nous vous signalons qu'il est strictement interdit de le diffuser, de le distribuer ou de le reproduire.
----- Original Message -----
From: "Bob McConnell" <rv...@CBORD.com>
To: <ax...@ws.apache.org>
Sent: Thursday, December 07, 2006 10:30 AM
Subject: RE: Evaluation of application
I am sorry for resurrecting an old thread, but there is a question
remaining that I would like some guidance on.
Support Overhead: After we implement this interface, it will have to be
deployed onto several hundred transaction servers. The initial
installation will need to install all of the framework components onto
Win2K and 2K3 servers. Most of this will be managed by our support
specialists, with the physical tasks of inserting a CD and running the
install scripts done by the local system operators. Updates and bug
fixes will have to be done either by mailing CDs or connecting to each
server with a VNC and manually doing the updates.
Can anyone provide a reasonable guess of how many support man-hours will
be required for each deployed server to install and then maintain the
Axis 2/Tomcat/Apache framework?
Thank you,
Bob McConnell
> -----Original Message-----
> From: Dennis Sosnoski [mailto:dms@sosnoski.com]
> Sent: Monday, October 30, 2006 4:28 AM
> To: axis-user@ws.apache.org
> Subject: Re: Evaluation of application
>
> 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