Hi all,
hope u don't mind an novice question.
I am thinking abut writing a tool for converting existing COM components to webservices. (for my final year project) I have boned up on COM and Web Service theory and decided to the project in C#.
Now suddenly (for me) i hear this stuff about COM+ components and them being "serviced" etc , basically that they can automatically be configured as web services!
I am afraid this COM+ stuff is going over my head (i haven't got much exposure to things starting with "Enterprise ..") , can anyone please clerify my doubts about the following.
1. Is COM+ a web service savvy version of a COM component
2. Can we really export a COM+ component as web service, by just ticking a check box
3. finally , Is spending time and effort in making the above stated tool a good idea
convert COM components to Web Services
marco_polo14
I will admit that I have not messed with the com+ services stuff but some thoughts:
generaly a good "WebService" should be based on a stateless http message model.
most COM stuff I have dealt with tends to be statefull and geared to a continued connection. in some cases I think that could be a major problem to map between the two worlds (COM Vs. HTTP)
com+ is not "web service savvy" it's an updated COM that pre-dates web services and .net.
#3 depends, do you know someone who has a bunch of com dll's that need this
if you don't I'd think the answer is no.
my personal idea for a good project is to look at the errors that seem to show up when a web service gets busy, google a bit on "the underlying connection was closed" and web services and http 1.1 and keep-alives.
I and others have found that we get connection errors that we can't quite pin down a cause for ....
and the client side wsdl based proxy just pukes when that happens.
it should I think try to start a new connection if it can and then finish the web service call. only throw the ex. when re-connect fails.