use .net remoting?

[Guest]

I want a Visual Basic 6.0 web or desk top application to communicate with a
Visual Basic.NET web or desktop application. I also want a Visual Basic.NET
web or windows
application to communicate with Visual Basic 6.0 web or desktop applications.

Can you tell me what is the best communication method that should be used
and why?

Should .NET remoting, using COM objects, or should some other method be used?

Would you show me a URL that I can use for a reference?

Thanks!

 

[Jeremy S.]

You are asking "what's best" given some rather vague requirements. Help us
help you. Tell us more.

Where are these applications in relation to each other? Is there a firewall
between them? Are all nodes within a private intranet. What operating
systems are involved? What is the nature of the communication? How frequent
is the data to be exchanged? What is the data?

BTW: What's a VB6 Web application?

 

[Guest]

Jeremy:

This exchange of information is within a company's intranet. There is no
firewall to worry about.All the servers are either win2000 or win2003
servers. The data is about updating information on a sql server 2000
database. This communication is necessary since the "main part" of the
application is written in Visual Basic 6.0. I just want the newfunctionality
to be written in Visual Basic.net. I do not want new functionality to be
written in Visual Basic 6.0.

Thank you for your information!

 

[Jeremy S.]

Okay - for clarification purposes, is it true that you currently have one
VB6 application, and that it is a Windows Client application? Is it also
true that this one VB6 application talks directly to a SQL Server? If not,
then please clarify exactly what you currently have. Are there any VB6
"middleware" components sitting between the client application and the SQL
Server?

Is it true that you want to add new functionality to your single VB6 desktop
application - AND that you want all new functionality to be in a separate
VB.NET desktop application? If not, what do you want to go to?

What do you mean by the "main part"? Do you have some vb6/COM DLL sitting
on a server somewhere that is acting as the data access layer?

We're just trying to get a better assessment of (1) what you currently
have - all application components; and (2) what you want to be different.
Also, why do you think your VB6 and VB.NET applications might need to
exchange data with each other. It sounds like they both just need to talk
with the SQL Server.

I hope you aren't planning on running two desktop applications - the "old
vb6 application" next to a new VB.NET application with the user needing both
in order to do his/her job.

 

[Guest]

Jeremy:

One application is a vb 6.0 desktop application. I need the new component
to pull data from a Tandem database and load it onto a SQL server database
for the VB 6.0 desktop. Basically I want the old vb 6.0 desktop application
to call a vb.net component to access the Tandem database. The VB.net
component will obtain the data from the Tandem database by using soap and
xml. The VB.net component will also pass data back to the tandem database via
soap and xml so that the Tandem
table can be updated.

I am thinking that if the desktop vb 6.0 application is every rewritten, I
will have at least the portion that connects to the Tandem database written
in VB.NET.

Let me know your option.

Thanks

 

[Jeremy S.]

Okay, we have a better idea of what it is you are doing.

While I'll give you some things to think about, we unfortunately still
cannot answer your initial question: ("Can you tell me what is the best
communication method that should be used and why?") because we are missing
so much relevant information about what you are doing.

"Best" is always relative to some context and specific limitations of your
environment. What I can tell you is that you have not provided any reason to
use XML and SOAP in your environment. Is that a requriement of the Tandem
database? I doubt it. So, given the performance hit you'd incur in the
XML/SOAP communications - why would you use SOAP and XML at all? Given your
environment as you described - it's all in one intranet running Windows OS -
so no need to exchange to different platforms. That's what XML/SOAP is
useful for - it solves the "different platforms" problem and possibly
firewall issues as well - but you don't have any of those issues. You might
want to find the Tandem data provider for ADO.NET and/or OLE-DB and/or ODBC
and use that (if one exists, and I'm sure one does). Your performance would
be much better than translating XML/SOAP.

Now - about the VB.NET component that is to "connect to the Tandem
database": Is that all it's doing? If so, then there is no need to create
this component at all. If you are just connecting then just go with your VB6
desktop app's current capabilities - and just point it to whatever database
is necessary (just swapping out connection strings and providers).

From what you have described so far, there is no real justification for:
1. The use of XML/SOAP (you could use some native providers for both Tandem
and SQL Server instead)
2. Remoting (that, too, incurs a performance hit all by itself)
3. The architectural decision to have any new physically isolated/separated
data access layer (which is apparently what the VB.NET component would
function as). You just say it is to transfer data between Tandem and SQL
Server. If that's all it's doing, then perhaps don't create the VB.NET
utility and instead create a DTS package and schedule it if it needs to
transfer data on a regular basis. Also, from the client application side,
you apparently already have an investment in a VB6 desktop app that already
communicates with Tandem; why not just point it to SQL Server and be done in
under an hour? I do strongly advocate having a separate data access layer -
but given your existing investment, you just might want to work with the
existing architecture until you get to do a wholesale rewrite.

Good Luck.