Joe Long is Product Unit Manager for Enterprise Services at Microsoft, a product unit
that is part of the larger Indigo group. The Indigo team owns Remoting, ASP.NET
Web Services, Enterprise Services, all of COM/COM+ and everything that has to do with
Serialization.

And if you want to hear the same song sung by the technologyspeakmaster,
go and hear Don:

If you want to read the core message right now, just scroll
down here. I've been working directly with the Indigo folks on the messaging
for my talks at TechEd in Dallas earlier this year as part of the effort of setting
the stage for Indigo's debut at the PDC.

I'd also suggest that you don't implement your own ES clone using custom
channel sinks, context sinks, or formatters and ignore the entire context model of
.NET Remoting if you want to play in Indigo-Land without having to rewrite a large
deal of your apps. The lack of security support of Remoting is not a missing feature;
Enterprise Services is layered on top of Remoting and provides security. The very
limited scalability of Remoting on any transport but cross-appdomain is not a
real limitation; if you want to scale use Enterprise Services. Check out this page
from my old blog for a few intimate details on transport in Enterprise Services.

ASMX is the default, ES ist the fall-back strategy if you need the features or the
performance and Remoting the the cheap, local ORPC model.

If you rely on ASMX and ES today, you'll have a pretty smooth upgrade path. Take that
expectation with you and go to Joe's session.

[PS: What I am saying there about
ES marshaling not using COM/Interop is true except for two cases that I found later:
Queued Components and calls with isomorphic call signatures where the binary
representation of COM and the CLR is identical - like with a function that passes
and returns only ints. The reason why COM/Interop is used in those cases is very simple:
it's a lot faster.]

PDC Countdown: Use ASMX and Enterprise Services Now For Tomorrowhttp://vasters.com/clemensv/PermaLink,guid,2e27b7d3-8567-4cee-86ee-6b3e23e86d5d.aspxhttp://vasters.com/clemensv/2003/10/24/PDC+Countdown+Use+ASMX+And+Enterprise+Services+Now+For+Tomorrow.aspx
Fri, 24 Oct 2003 06:54:46 GMT<p>
<a href="http://weblogs.asp.net/bmore/posts/33113.aspx">Brad More</a> is asking whether
and why he should use Enterprise Services.
</p>
<p>
Brad, if you go to the PDC, you can get the definitive, strategic answer on that question
in this talk:
</p>
<p>
<strong>“Indigo”: Connected Application Technology Roadmap<br>
</strong><font style="FONT-SIZE: 8pt"><strong>Track: </strong>Web/Services&nbsp;&nbsp;&nbsp;<strong>Code: </strong>WSV203<br>
<strong>Room: </strong>Room 409AB&nbsp;&nbsp;&nbsp;<strong>Time Slot: </strong>Wed,
October 29 11:30 AM-12:45 PM<br>
<strong>Speakers:
<SPEAKER>
</strong><a>Angela Mills</a>>
,
<SPEAKER>
<a>Joe Long</a>
</font>
</p>
<p>
Joe Long is Product Unit Manager for Enterprise Services at Microsoft, a product unit
that is&nbsp;part of the larger Indigo group. The Indigo team owns Remoting, ASP.NET
Web Services, Enterprise Services, all of COM/COM+ and everything that has to do with
Serialization.
</p>
<p>
And if you want to hear&nbsp;the same song sung&nbsp;by the technologyspeakmaster,
go and hear Don:
</p>
<p>
<strong>“Indigo": Services and the Future of Distributed Applications<br>
</strong><font style="FONT-SIZE: 8pt"><strong>Track: </strong>Web/Services&nbsp;&nbsp;&nbsp;<strong>Code: </strong>WSV201<br>
<strong>Room: </strong>Room 150/151/152/153&nbsp;&nbsp;&nbsp;<strong>Time Slot: </strong>Mon,
October 27 4:45 PM-6:00 PM<br>
<strong>Speaker: </strong>
<SPEAKER>
<a>Don Box</a>
</font>
</p>
<p>
If you want to read the&nbsp;core message right now, just&nbsp;<a href="http://staff.newtelligence.net/clemensv/PermaLink.aspx?guid=97f80d05-73bc-4e59-b2f1-c748d7eed43b">scroll
down here</a>. I've been working directly with&nbsp;the Indigo folks on the messaging
for my talks at TechEd in Dallas earlier this year as part of the effort&nbsp;of setting
the stage for Indigo's debut at the PDC.
</p>
<p>
I'd also suggest that you don't&nbsp;implement your own ES clone&nbsp;using custom
channel sinks, context sinks, or formatters and ignore the entire context model of
.NET Remoting if you want to play in Indigo-Land without having to rewrite a large
deal of your apps. The lack of security support of Remoting is not a missing feature;
Enterprise Services is layered on top of Remoting and provides security. The very
limited scalability of Remoting&nbsp;on any transport but cross-appdomain is not a
real limitation; if you want to scale use Enterprise Services. Check out this <a href="http://radio.weblogs.com/0108971/2002/09/12.html">page
from my old blog</a>&nbsp;for a few intimate details on transport in Enterprise Services.
</p>
<p>
ASMX is the default, ES ist the fall-back strategy if you need the features or the
performance and Remoting the the&nbsp;cheap, local&nbsp;ORPC model.&nbsp;
</p>
<p>
If you rely on ASMX and ES today, you'll have a pretty smooth upgrade path. Take that
expectation with you and go to Joe's session.
</p>
<p>
[PS: What I am saying <a href="http://radio.weblogs.com/0108971/2002/09/12.html">there </a>about
ES marshaling not using COM/Interop is true except for two cases that I found later:
Queued Components and calls with isomorphic call signatures&nbsp;where&nbsp;the binary
representation of COM and the CLR is identical - like with a function that passes
and returns only ints. The reason why COM/Interop is used in those cases is very simple:
it's a lot faster.]<em>&nbsp;</em>
</p>
<img width="0" height="0" src="http://vasters.com/clemensv/aggbug.ashx?id=2e27b7d3-8567-4cee-86ee-6b3e23e86d5d" />http://vasters.com/clemensv/CommentView,guid,2e27b7d3-8567-4cee-86ee-6b3e23e86d5d.aspxPDC 03TechnologyTechnology/COMTechnology/Enterprise ServicesTechnology/Indigohttp://vasters.com/clemensv/Trackback.aspx?guid=4261db53-025c-4b18-bc45-4ed99b86d582http://vasters.com/clemensv/pingback.aspxhttp://vasters.com/clemensv/PermaLink,guid,4261db53-025c-4b18-bc45-4ed99b86d582.aspxhttp://vasters.com/clemensv/CommentView,guid,4261db53-025c-4b18-bc45-4ed99b86d582.aspxhttp://vasters.com/clemensv/SyndicationService.asmx/GetEntryCommentsRss?guid=4261db53-025c-4b18-bc45-4ed99b86d582