Need some help here... desperately

COM+ and non MS server-side technologies

[joshie76]

We have some potential clients that aren't using IIS. Our product uses COM+ and as standard .asp server side scripting. The .asp is simple as the heart of the code is all dealt with by COM+ and we'd be happy to convert it to .php, .jsp etc. The COM+ is most likely to be installed on a separate application server from the web server.

Anybody aware of any problems with this? can .php, .jsp etc deal happily with COM+? I assume the web-server is going to have to be a windows box to do this? Is there anything else I should be aware of?

Thanks muchly in advance.

Frantic Josh

[sugarkane]

*bump*

Joshie - did you get anywhere with this? I'm sorry but I know nothing of COM+ myself, but after quick scoot around it seems that PHP at least can deal with it...

Has anyone tried it?

[joshie76]

Thanks for trying sugarkane.

I figured the residents here are largely *nix peeps. I'll perhaps pay a more MS oriented forum a flying visit.

Keep 'em coming if you have any more for me.

[Xoc]

This sounds like a perfect application of the .NET Web Services technologies. You'd set up the COM component as a web service. Then using virtually any other technology, you could call it and return the results back to the calling app. The only issue would be forming the SOAP packet on the .php, .jsp, whatever platform.

[joshie76]

Yeah, we're looking forward to being able to work on the .NET platform. At the moment though we simply can't expect our clients to install the .NET framework so we have to use COM+ and asp classic etc. Roll on that time!

[Xoc]

That's just it. With .NET, your clients don't have to have .NET on their platform. If you have the application server somewhere on the web (potentially security protected), your client's ASP, PHP, JSP, whatever, machine can make SOAP calls to your .NET machine, get the results and return them back to their client.

You have to create SOAP, an open standard, packets on the ASP, PHP, JSP, whatever machine. Microsoft provides some tools that make this easy on legacy IIS. It will be only slightly harder on other platforms.

SOAP (Simple Object Access Protocol) is sending and receiving XML (eXtensible Markup Language) over HTTP (Hypertext Transfer Protocol) using particular DTDs (Document Type Definitions). As long as the sender can form the XML in the right format and send it off, the .NET machine doesn't care where it came from, be it an Apache server, IIS server, whatever.

[joshie76]

Sorry - I should have explained.

The whole thing has to run enclosed within the clients network. It's just the way it is! Kinda' like SAP or PeopleSoft type web applications.

[Xoc]

Can you put the .NET framework on the application server, and leave it off the web server?

[joshie76]

Possibly, but we can't rely on it. In fact it's probably quite unlikely at this stage. .NET will need to mature a little before the big corps go letting us install it on their application servers.

Because of this our product has been developed away from .NET for the time-being, we're choosing to rely on the more well-founded technologies (development of this product has been going for around 2 years now!). We'll start moving to .NET as the likelihood of it being available increases.

From what you're saying about .NET I'm guessing that the web-server would have to be a windows box to deal with COM+ on the app server (in ASP classic etc)?

[Xoc]

No. The web server can be anything that when a URL is retrieved can execute something that can form some XML (text), and POST a HTTP request to the application server. The only reason why the application server has to be a Windows box is that, in your case, it will need to access COM components. SOAP is actually platform/language neutral. Microsoft just is trying to create better tools for doing SOAP than anyone else.

You can do SOAP on any platform, including standard IIS. It's just easier if you have the .NET framework installed.