|
|
I think as developers, we all can sympathise with the challenge that
comes with keeping up with evolving technology that changes,
literally, every day. The only thing that remains constant in our
industry is change. Unfortunately, if as a developer, one finds this
reality overly troublesome, then I would encourage that individual
to seriously reconsider their career.
We can't blame Microsoft for being innovative, and no, Microsoft is
not going to stop supporting remoting or gut it from the framework
anytime soon. However, for nearly a year now, through literature and
developer events, the community has been providing guidance on what
can be done today to prepare for Indigo and remoting does not
present a sound choice if this is your goal because the semantical
differences are too great due to the significan differences in
underlying architecture. As such, there is no straightforward
migration from remoting to Indigo. Its a rewrite.
While I can undersand the frustration of those who have made
significant investments implementating remoting, to stifle
innovation in the interest of maintaining current assets is to
become complacent and complacency breeds stagnation. I am by no
means suggesting that you use a new technology just for the sake of
using new technology- always evaulate the cost/benefit- but when the
technology is as revolutionary as Indigo, you'd better pay
attention.
No one is saying drop remoting, or remoting is bad (although I'm
sure you would agree that the programming model is horrendously
complex), we're simply saying that the future is Indigo and if you
want to prepare for Indigo, then you should start thinking about
your existing infrastructure now and make careful choices in
choosing the right tools for the future based on your current design
goals (interperability, extensibility, reliablilty, etc).
Indigo represents a truly revolutionary advancement on many, many
levels, but most significantly in making true service orientation a
reality. Indgo takes the concept of interface based programming to a
new level, providing the interop benefits of ASMX, extensiblility
features of remoting, security features of WSE and the reliability
and performance of COM+. This will be the genesis of true SOA, which
quite frankly you cannot truly do today without writing a signficant
amount of custom plubming and even so, I would argue that your
probably not hiting all the tenants of true SOA as defined. You can
come closer if you are using ASMX wrapped COM+ 1.5 components but
there are still limitations. This brings me to my final point.
If anyone is truly interested in understanding Indigo today and is
hesitant to play with the Beta 1 RC, I strongly encourage you to
start spending some time with COM+ and Enterprise Services, because
while it is much more than this, Indigo really represents the next
release of COM+ and the programming model and architecture is
remarkably similar. Also, from a migration perspective, the move
from Enterprise Services to Indigo is really a matter of changing
some attributes and namespace references.
|