Sorry your browser is not supported!

JSN

Ok, here is the deal. I need to have asp.net client browswer sessions submiting data via IIS to a central application (vb.net exe) Central app takes data, pushes to sql db, communicates with bank to verify Credit Cards, stores bank return data, prints records for customer and fulfillment, pushes back an asp.net page to the data entry person (client session) letting them know if all ok or any problem along the way. OK, before we get all haywire all of this is written/being written and is not the problem...

The problem is in the intermediary piece, either a WebService or .NET remoting - this is where I need advice/suggestions/design assistance. I am new to remoting and webservices although over the past week I have taught myself alot. webservices are simply awesome but I want to use remoting (or at least I think I have to) for what I want to do...

I need the vb exe portion to get the data from the client asp.net portion, preferably using soap/xml via remoting but I am lost on some of the concepts. I have mimiced the functionality in a webservice, and I know how to traverse networks via MSMQ xml messages but the architecture we are looking at seems like it should involve .Net remoting due to the scalability being so flexible, and client overhead being naught as they would only need a browser session. I believe I am looking at a SAO, in Singleton Mode, communicating via httpChannel, serializing in SOAP/XML

Any thoughts on how to proceed with the intermediary piece would be greatly appreciated!

I eagerly await your response
Thanks

OK, part 1, the user interaction, as you said works fine, so lets throw that out of the window.

If you're wanting to get the session details from the server, then yes, I'd go with the remoting rather than the webservices. And as you've correctly found out, the Singleton mode would be better suited at 'grabbing' this information. I've VERY briefly touched this, and the only problems I had is that I had to say how long I wanted the session to remain open. Previously I think if I remember rightly, I didn't have to say how long to leave the session open, because as long as I was accessing it, it was there. In the singleton-mode however, because of security issues and to reduce overhaul on the server, you have to physically say how long the session is to remain open. I think the default is only a few minutes, which is fine on a LAN, but if you're customers have a WAN or the network is generally slow, then obviously increase this.

Don't know what you mean when you say SAO though? Sorry.

Sorry, forgot to add.

In terms of a flow, I'd say keep part 1 as it is, it's looking great as it is.

When the information has been passed to the server, the clients browser takes them to an activation URL which in turn then runs your intermediary routine to extract the information. Within this intermediary code, you have the session of the browser which of course throws this to your code.

You could then of course throw the client back to the initial page whilst your program does all the hardwork.

JSN thanks for your response. Oh, btw, SAO is Server Activated Object, as opposed to Client Activated Object.

Since I understand the concepts, and understand the concepts in your reply, I guess what I am asking/saying is that I don't understand the implementation of all this from the perspective of the vb exe portion ack! lol. I am not sure where to begin to have the vb exe portion sit there and receive http messages from muliple clients (having first passed through IIS). I am reading Ingo Rammer's book Advanced .NET Remoting in VB.NET but the guy is a prodigy and is losing me - examples on the net are few and far between, and when I do find examples they are not the architecture I need and/or are unclear and poorly written. My head hurts and I need help.

Anything in the way of code snippets, tuorials, examples in the arc that I am looking for is beyond immensely appreciated - I know this is asking alot

Thanks,
James

Funny, never hear dof SAO, o well, still a lot to learn in this mammoth.

Anyway, I understnad what you mean about the concepts. If you were having an asp.net client code that was passing data via the browser to a server (which it is), and in turn the server was saying "Right, got that, thanks, away you go", the browser received this and before it went back to page 1, it called another web-page that activated some code on a server in a top-secret location, then it wouldn't be too hard to do I guess.

BUT...

The last part, as you said, isn't server-side code, it's an actual program.

The only thing I could possibly think of then, would be can't you pass the confirmation to the SQL server, which in turn has a trigger attached, which in turn, runs an activeX control on the SQL Server (or runs a 'mini-program' of what you want to do), which is a call to you code?

Just a thought...

jsn, thanks. No the route through the sql trigger isn't necessary. The concept of remoting supposedly can do the stuff I need it to do, raise events at vb exe, communicate http direct between iis and vb exe etc ect but ::sigh:: I have no examples to work from. I'll keep digging tho. I am in the "proof of concept" stage of this project so it is expected to be a hairy endeavor~~

Thanks again for your time and help.
I'll keep you posted if I find out anything useful
<needs to go lie down now>

James

No worries Rust, sorry I couldn't help any more. Not really had much experience on that side of things, not had the need really.

Last project can be found at http://www.hbitl.net/register/ if you're interested. I did the "VoiceNet" system.

Keep me informed how you get on.