See inline.
Willy.
"David Browne" <davidbaxterbrowne no potted
(E-Mail Removed)> wrote in
message news:(E-Mail Removed)...
|
|
| <DIV>"Willy Denoyette [MVP]" <(E-Mail Removed)>
| wrote in message news:(E-Mail Removed)...</DIV>>
| > "David Browne" <davidbaxterbrowne no potted
(E-Mail Removed)> wrote in
| > message news:%(E-Mail Removed)...
| > |
| > |
| > | <DIV>"Jon Davis" <(E-Mail Removed)>
| > wrote
| > | in message news:(E-Mail Removed)...</DIV>> Can a
| > | solution built in C# utilize MSMQ and/or MTS?
| > | >
| > | > If so, does this make the training material I already have on MSMQ
and
| > MTS
| > | > in the context of VB6 an appropriate prerequisite foundation before
| > | > learning how to build C# solutions on MSMQ / MTS, if I already know
| > VB6
| > as
| > | > well as C#?
| > |
| > |
| > | Also be aware that .NET has much less need of the services provided by
| > MSMQ
| > | and COM+ (formerly MTS), than VB6 did. Each of these platform
| > technologies
| > | is still sometimes useful, and there is good support in the .NET
| > framework
| > | for them, but they are no longer the "bread and butter" of enterprise
| > | applications.
| > |
| > | David
| > |
| >
| > Not sure where you get this idea from, what are the alternatives offered
| > by
| > .NET? How would you implement enterprise like applications without
| > resorting
| > to System.EnterpriseServices and System.Messaging (COM+ and MSMQ
| > wrappers)?
| >
| >
|
| Ok. EnterpriseServices (COM+) basically offers a bunch of services to
| applciations:
|
| Object Lifetime Management
| Threading
| Transaction Management
| Distributed Components
|
| You can do all of this in .NET without the help of COM+. The "COM" in
COM+
| should remind you that COM+ is an application server designed to service
an
| earlier generation of components.
|
| .NET features such as
|
| System.Threading
This is not the same thing, COM+ Threading services are attribute based
(just like all COM+ services) little or no threading code to write it's all
taken care of for you.
| System.Transactions
Yep, this is really the only service pulled from COM+, note that both use
MSDTC when escalating to a distributed transaction.
| Windows Communication Foundation (or .NET Remoting and web services)
| .NET's OO functionality (constructors, singletons, thread agility)
|
WCF is not released yet, and Remoting serves other purposes and it requires
..NET at both ends (not to talk about what it lacks), WCF will build on COM+
for some of it's services (at least for V1 of NetFx V3).
| Really make COM+ redundant.
|
Well, I have to disagree,
How about object pooling, component activation and launch support,
security services like "access and activation security control","private
components" "Identity selection" ...,
distributed components,
COM+ partitions with Active Directory Services integration ,
automatic or user controled application recycling,
application control (pausing/disabling),
run as a Windows service,
low memory activation gates,
Debugging features (Process Dump).....?
and this, all attributed, no or little code to write. And don't forget the
reduced management overhead, all component services & attributes can be
controled from native clients and are scriptable.
| For MSMQ, it's still a useful option for guaranteed delivery messages, but
| SQL Server Service Broker is a better choice for many enterprise
| applications.
I tend to disagree, SQL server is a separate product, it's not part of the
core OS services, nor is the Broker API part of .NET, and when you need
redundency (who doesn't want it?) it's even more expensive. And let's not
talk about administrative overhead and performance.
Having the persistent state of the application stored in one
| place is a great advance over storing "messages" in the file system on the
| application server, and "data" in the database.
|
| See, EG
|
| O COM+, Where Art Thou?
| Rockford Lhotka
|
| It is easy to say that EnterpriseServices in Microsoft .NET gives us
access
| to all the COM+ features. While this is accurate, it really isn't
sufficient
| because it may lead you to believe that you should just continue to use
COM+
| services in Microsoft .NET just as you did in COM, only with a different
| name.
|
| The reality is that some of the overwhelmingly positive benefits COM+
| offered to COM development aren't so overwhelmingly positive in Microsoft
| .NET. In other cases, features of COM+ that were unavailable to Visual
Basic
| 6.0 developers are fully accessible when developing in Visual Basic .NET.
|
|
http://msdn.microsoft.com/library/de...et04232002.asp
|
Sorry, this say's nothing "aren't so overwhelmingly" what is meant with,
and why should it be overwhelmingly ?
.... on the other hand - <features of COM+ that were unavailable to Visual
Basic
| 6.0 developers are fully accessible when developing in Visual Basic
..NET.> - that's great isn't it?
|
| Especially with .NET 3.0 what enterprise application requirement do you
need
| COM+ for anymore?
|
Not sure, it's certainly a departure from COM+ as technology and it offers a
lot more (albeit a number of features are still missing), but as it's not
released yet, you can hardly call it "enterprise ready", (even V2 isn't yet
that widely accepted in the enterprises, let alone V3), and IMHO it targets
Vista and Longhorn more than W2K3, it will take years before it will and the
first release will use COM+ for a number of it's "enterprise services" (MSMQ
and COM+ integration services).
Willy.
Similar Threads
