Hi Martin, The intent of this interface is to provide a standards based front end on a DCOM transaction server. This is needed to allow access to services already available in that DCOM framework for Point Of Sale systems that are not running on MS-Windows. Instead of having to create a new socket based component each time we need another third party interface, we are examining Axis as a framework to build a common interface based on SOAP over https. Then we would publish WSDL subsets for various classes of POS system. Our server components are written in a mix of Visual C++ 6, J++ and VB6.
We already know the costs to deploy and maintain the DCOM components, since we have been doing that for about eight years. We need to compare this with the other options in order to evaluate that make/buy decision. We recognize that there will be a cost bump in the initial deployment because of the framework, but we don't know if there are other long term costs involved. That initial bump will not vary much no matter which framework we choose. We have another month or so to make the decisions, then five to eight months to implement the interface before we have to begin deployment. Development manpower is not as big an issue as are deployment and support. Since it takes four to six months to train a new support tech, we need to know if we have to hire more of them to deal with this project. Thank you, Bob McConnell > -----Original Message----- > From: Martin Gainty [mailto:[EMAIL PROTECTED] > Sent: Thursday, December 07, 2006 11:11 AM > To: [email protected] > Subject: Re: Evaluation of application > > 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/webservice > s/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 -- > > ----- Original Message ----- > From: "Bob McConnell" <[EMAIL PROTECTED]> > To: <[email protected]> > 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:[EMAIL PROTECTED] > > Sent: Monday, October 30, 2006 4:28 AM > > To: [email protected] > > 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 [EMAIL PROTECTED] > > > Web www.cbord.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
