On the road to Indigo: Prescriptive Guidance for Today's Technologies
How do I prepare my code and systems to ease my adoption of Indigo?
This is a VERY hot topic based upon the questions we get asked daily by customers and partners.
In this posting, I will be dealing with the following questions:
- “Which current technologies should I use, where and when?”
- “How will Indigo interoperate with systems based on existing platform and technologies?”
- “How much of my code will I have to change to migrate my code to Indigo?”
- “How will Services Perform & Scale?”
Our prescriptive guidance for where to use which technology and when is formulated from two viewpoints:
1) From the perspective of moving to a Service Oriented mindset. For a discussion on Service Orientation, see my posting on SO here.
2) To smooth the migration from current .NET technology to Indigo.
Which current technologies should I use, where and when?
The following points outline when you should use which technologies and for what purposes:
1) Develop ASMX Web Services at your service boundaries whenever possible. ASMX Web Services map closely to simple Indigo Services and support the .
2) Use WSE at your service boundaries for advanced web services support (such as WS-Security)
a. HOWEVER – note the following:
i. WSE has a limited support policy (currently 2yrs + 1 yr extended)
ii. WSE is a technology accelerator and not a strategic platform. This means that your WSE code will need to be migrated by hand to Indigo and this may incur non-trivial work.
3) Use Enterprise Services inside your service boundaries when …
a. You need rich service support such as transactions
b. You want to take advantage of JIT Activation and object pooling
c. You want a resilient remote component infrastructure
4) Use .NET Remoting inside your service boundaries for …
a. In-Process, Cross-AppDomain communications – Remoting has been optimized to pass calls between app domains VERY quickly
b. If you need to support custom wire protocols. Understand, however, that this customization will not port cleanly to Indigo in the future and it will have to be re-coded as an Indigo Channel Provider
How will Indigo interoperate with systems based on existing platform and technologies?
Indigo will interop on the wire with:
1) ASMX – with no changes
2) WSE – Indigo will ONLY interop with the version of WSE (WSE3?) released alongside Indigo
3) EnterpriseServices (ES) – we are planning to extend the ES/COM+ infrastructure to talk Indigo on the wire so that ES/COM+ components can call and be called by Indigo services
4) MSMQ – with no changes. MSMQ is being extended to talk Indigo on the wire
Note that:
1) Indigo will NOT interop on the wire with Remoting in either binary or SOAP. This subject is discussed here
2) Indigo will ONLY fully interop with WSE Web Services built against the version of WSE released alongside Indigo. Indigo is NOT guaranteed to interop on the wire with WSE v1 & v2 Web Services.
I discuss the Remoting situation in this posting.
How much of my code will I have to change to migrate my code to Indigo?
Essentially, the news is good! We’re working hard to minimize the amount of code you will have to change in order to port your existing .NET ASMX, Enterprise Services and Remoting code to Indigo and will provide a code migration strategy from these technologies to Indigo. Migrating your.NET ASMX, Enterprise Services and Remoting to Indigo will largely involve changing namespaces, attributes, inheritance points and the occasional minor code-fix.
NOTE: There are two main caveats here:
- If you’ve implemented any .NET Remoting channel & sinks, you will need to do some work to port this logic to Indigo Channel Providers. See my posting on Remoting for more discussion on this.
- WSE code will require manual effort to migrate. The amount of work required should not be huge, but it will not be a simple, mechanical renaming process.
This stated, if you need to (or are insistent upon) create your own messaging protocols/formats using .NET Remoting, and you understand that you will need to do non-trivial work in order to port this system to Indigo in the future, then, go ahead and write the necessary logic. My guess is that you will rarely want to do the extra work and should therefore aim towards exposing your services using ASMX (and WSE if required) wherever possible. Your existing components can continue to exist within this service boundary as before, but you should aim not to expose any of your service’s logic through channels other than your ASMX service interface.
How will Services Perform & Scale?
This one subject demands a posting all on its own and I will post several discussions on this subject. However, note at this point, that there are cases where performance, scalability and capacuty is EXTREMELY important in a number of scenarios. Services, XML, SOAP and HTTP may not be the most optimal way of transferring information quickly and efficiently – be assured that we’re taking this subject VERY seriously and are working hard to ensure that Indigo performs within close proximity to existing technologies in comparable scenarios.
More on this soon!
