Last week some colleagues of mine returned from a Microsoft training class
on Web Services with the notion that Web Services are replacing COM+. This
is what the instructor (a Microsoft employee) told them. This seems naive
to me, since COM+ encompasses much more than what web services can provide
(DTC, MSMQ, etc). So I think this instructor may have been speaking from
inside his own little bubble. Perhaps he meant to say that DCOM is being
replaced by web services. I know that is an option in COM+ 1.5. I also
know that Enterprise Services uses .NET Remoting under the covers when .NET
is on both ends. So that may be a possibility. Although completely
replacing it with only one protocol seems extreme. Don't get me wrong, I'm
all for web services and service oriented architecture. I just don't think
there's only one tool for every job. And I'd like to know which tools I
should be using going into the future.

Anyway, I guess my question is, to what extent is COM+ changing or
disappearing, and how much of it is being replaced by web services? If
anyone can provide links to some authoritative, factual online
information--preferably by Microsoft--I'd appreciate it. No links to blogs
by web guru wannabees, please.

Thanks,
John

I can't say for sure but I'm guessing the discussion may have been about the
new 'Indigo' infrastructure MS is working on. COM+, MSMQ, Remoting, Web
Services, etc. are all supposed to be encompassed within it. Next
generation, SOA, blah, blah... you get the picture. I've only read one or
two articles on it so far and it sounds promising.

"Stingray" <nospam> wrote

In common with MSMQ, .NET Remoting and ASMX Web Services, COM+ is not going
away. All of these technologies are to a greater or lesser extent, widely
used by customers today and their investments in those will be preserved.

As we look to a future where web services are prevalent and they offer
integration benefits above and beyond what has previously been possible,
COM+ and Enterprise Services will remain a fine way for building distributed
applications but there will be real utility in providing web service
interfaces at the explicit boundaries and entry points to these
applications. In this way COM+ can have a core role within SOA.

Indigo will provide integration capabilities with COM+ that will make the
construction and declaration of these boundaries a relatively painless
exercise.

Hope this helps,
Andy Milligan. Indigo Team.
--
This posting is provided "AS IS" with no warranties, and confers no rights.


"Douglas Gallant" <no (AT) spam (DOT) net> wrote

Andy,

Thanks for clarifying the future of COM+ in Longhorn/ Indigo.

I was hoping that COM+ would be tidied up to avoid having to Register
COM components, and export and register proxies etc. I cannot
convince my software design leaders that the MS .NET solution has yet
solved its "dll hell" problem.

Will Indigo provide a full enterprise level services (Queued
components, Transactions, Asynchronous messaging) with .NET components
without dll (COM)registration ?

It would be nice to have a clearer view on where MS is going wrt to
Enterprise Services to support Application business logic. And if web
services are the way to go, what services and quality of service these
will provide, especially their invocation performance. [ c.f. we
currently use private Express MSMQ queues in our MS based solution,
since these provide good asynchronous performance, but we are now
considering the use of JMS services in the next release.]

Thanks

Julian

"Andy Milligan [MSFT]" <amillig (AT) online (DOT) microsoft.com> wrote

Andy,

Thanks for clarifying the future of COM+ in Longhorn/ Indigo.

I was hoping that COM+ would be tidied up to avoid having to Register
COM components, and export and register proxies etc. I cannot
convince my software design leaders that the MS .NET solution has yet
solved its "dll hell" problem.

Will Indigo provide a full enterprise level services (Queued
components, Transactions, Asynchronous messaging) with .NET components
without dll (COM)registration ?

It would be nice to have a clearer view on where MS is going wrt to
Enterprise Services to support Application business logic. And if web
services are the way to go, what services and quality of service these
will provide, especially their invocation performance. [ c.f. we
currently use private Express MSMQ queues in our MS based solution,
since these provide good asynchronous performance, but we are now
considering the use of JMS services in the next release.]

Thanks

Julian

Indigo will build upon the provide a broad set of enterprise messaging
facilities and, as described at
http://msdn.microsoft.com/Longhorn/u...o/default.aspx,
it will deliver a "composable and extensible architecture, spanning
transports, security systems, messaging patterns, encodings, network
topologies and hosting models"

The specific registration and deployment requirements of a full Indigo
exposed service will depend upon the range of technology choices that make
up that solution but you should note that when deployed as an Indigo
service, a well-behaved client is only responsible for adhering to the (XML
based) service contract. There is no requirement for deployment of any
particular client-side proxy solution though the use of one may ease client
development.

Thanks,
Andy Milligan. Indigo Team.
--
This posting is provided "AS IS" with no warranties, and confers no rights.


"Jules" <Roseanna80 (AT) hotmail (DOT) com> wrote