Ever time I work with the current Indigo bits, I am always continously amazed with the excellence in engineering and design behind it. With such a great extensibility model, a clear demarcation of local and distributed behaviors, expilict design time declarcations of binding requirements for communications to take place successfully, the explict nature in exposing operations and scheme through contracts and the powerful, yet simply elegant layering of the programming model; all of these provides a great framework for building distributed systems, whether leveraged in greenfield or brownfield scenarios.
One of the aspects that made my jaw drop, was when I first saw the COM & COM+ intergration featureset of Indigo in a demo that I saw a while back. The demo showed a MTS application orginally built in circa ‘96 (with no changes to the codebase and used only the binary and TLB), and it showed the “Indigo” enabling of some of the Interfaces so that they could speak WS-* on the wire, WOW!
During my usergroup sessions on Indigo a few weeks ago (in Cork and Belfast but not the Indigo session in Dublin for some reason, sorry! I revised the slide deck a little), I gave this particular feature set a quick mention and gave an overview of the COM(+) intergration features and the DTC talking WS-AtomicTransaction; and it got folks very interested, and they duly followed up afterwards for more information on what is possible. Overall it seems to resonate very well with folks; as it answers the big question of how does it play with the stuff I have today, “as we have a little of this and a little of that”, which has developed over time.
So far, my feedback from the sessions fits into two buckets, those with older/current existing MS tech. stack based solutions and those with solutions not based on MS tech. stacks. For this series I will focus on those with MS stacks that are older/current, but some details and possibilities for solutions based on non-MS based tech stacks will emerge and be interwoven in the blog series and this is especially for the use case of Transaction context flowing between callee and caller (or vice versa), as well as all of WS-* protocols.
When it comes to the older/current existing MS tech. stacks, I guess it is fair to say that not every VB6 application is going to be migrated to the .NET goodness in the long run for different reasons. In my opinion, it is a shame really, as the release of Whidbey (the codename for the next version of .NET, which is offically titled .NET 2.0 when released) in Nov. of this year, is Version 3 of .NET (i.e. .NET 1.0 and .NET 1.1, were significant releases after all) and certainly the level of productivity, performance and scalability enhancements that has occured in the Framework and CLR over the last 5 years has been very, very significant. All of these bring great leaps in performance, scalability and performance, and this is before I even mention how intelligent, productive and all encompassing the Visual Studio suite has become with the upcoming release of Whidbey. I won’t delve any further in this space, but software factories, DSL’s, Visual Studio Team System are areas that warrent much attention in my view.
So while everyone is looking forward, what about the systems that are live and in production today. What about VB6, ES, COM+, MTS, etc… With so many distributed systems already in place today, it raises the question what can be done with these systems in the Indigo world or even more so, when migrating these systems now, what technologies are out there and what needs to be thought about? As I have covered ASMX, Remoting and MSMQ in the sessions, I thought I would focus on systems that don’t use these particular technologies from MS and delve into some of the others.
When it comes to the others, I think the VB6 developed solutions would be an interesting topic to cover. This is especially the case when it comes to distributed applications that have been developed over the last 10 years or so on the Microsoft platform, back in the days when MTS was king or its current incarnations of COM+/ES. If doing the dual movement, from MTS to COM+ (especially COM+ 1.5 on Windows 2003) and VB6 to .NET, it is really amazing the performance, availability, scalability and increased maintainability (from a dev and IT-Pro perspective) that can be achieved when some re-designing when migrating a code base. Obviously the current wave of innovation will possibly overshadow some of the innvovations from the recent past, but innovations done as recently as 2–3 years ago are as important today, as they were the day they were released.
Taking for example, COM+ 1.5, you have a very comprehensive set of features that increase the maintainability of COM+ applications, such as:– application recycling– component aliasing– SxS, which is side by side assemblies, i.e. multiple versions of Dll’s on the one box, which is a very useful feature when consolidating apps onto less server tin– marking of components as private, therefore being explicit about what is exposed– better debug capabilities – etc….
(For all a good overview of the goodness in Enterprise Services and COM+1.5 architecture this link is very useful, in describing the all of the features)(also for all things COM+ 1.5, this link is useful)(and for all things Enterprise Services, this link is useful)
And when you combine this with the comprehensive framework of class libraries, with the powerful runtime and development environment of .NET, the performance and maintainability of applications is ever increased.
With so much emphasis being placed on Web Services over the last few years and today on SO and SOA, it raises the question what is possible with existing VB6, COM, COM+, ES applications/assets and what possibilities exist to leverage them and bring them into the new evolutionary world of SO. Perhaps even starting to do so today, but if this is not possible what possibilities exist in the Indigo timeframe? Isn’t Indigo just only about Web Services and SO? Well, it depends on what you mean by Web Services and SO?
I currently see SO as being about a design philisophy which you can merge with your own thought processes for designing better distributed systems and it assists with what best practices needs to be thought about when building system today, when making them loosely coupled, agile, reusuable, scalable etc.. and more resilent to change and changing requirments. When it comes to Web Services, at its inception it was mainly focused on being a “port 80” friendly way of making remote procedural calls with a particular text based encoding. Since then it has evolved to its current point where it is now more focused on how to make Services communicate, this in my view makes the “Web” moniker a subset and not a superset of the capabilities it offers. Currently, (“Web”/) Services has evolved to a point where it can be used to devise the fundamental unit of transmission (i.e. a message), how that message is strucutured (i.e. the infoset), how that message is encoded, how it is versioned; and through its strucutured messaging approach allows for the composability of protocol information to be easily factored into the unit of transmission. With all of this in mind, as I currently like to see it, Indigo as a communication/messaging/V.Next framework , allows you to leverage the technical capabilities of (“Web”/) Services and the design philisophy of SO in a far easier way that is currently available to us today, but in saying that, much of the analysis, design and implementation of Service Orientation can be done with todays technologies, to create Service facades that are loosely coupled, more coarser grained, pass messages and more resilent to change and changing requirments. One of the key aspects of Indigo, is that it leverages key standards and protocols, very easily caters for new additions and does not mandate a particular calling convention or Message Exchange pattern, transport, or encoding. A good illustration of this, is that with one implementation, you can have multiple contracts developed into an implementation; and at deployment time, can have multiple bindings to different transports and encoding, protocols and distributed behaviors (such as session, flow, context, transaction, etc..), maximising the reach, agility and reusability of an implementation, while allowing those that consume the service offered by the implementation to be abstracted from any underlying changes that may occur in the actual implementation but not the facade.
When it comes to VB6 implemented distributed applications (and those based on DCOM or other technologies based on the RPC paradigm of communication), I think it is fair to say that by and large these would be tighly coupled systems, like their peer systems based on other distributed object technologies. In general they are tighly coupled from the perspective of a number of high level concerns, such as requiring implementation to be shared, wire/protocol being used, assumptions about the distributed enviornment between them and the time (responsiveness, latency, always running/connected/available) and space (near or far, security, network topology, etc..) properties of the overall environment and the systems they interact with. All of these aspects of distributed object/component technology Obviously with systems based on the design philosophy of distributed objects, the cleaving apart or cleaving together of enough functionality to graft a service facade onto the implementation with sufficent levels of granulairty is not an easy endeavor, and in my view is very rarely as simple as “Web Services” enabling of existing interfaces in an existing system. Certainly “Web services”, in the form of ASMX etc.. provides some of the base plumbing to tactically create a service facade into an existing implementation, but only after some analysis of the system and determining what coarsed grained funtionality can be enabled in a loosely coupled, message based service and can be leveraged by new and existing systems, by exposing a composable unit of functionality at an endpoint(s). When it comes to the VB6 and/or COM based implementations, there is lots of things to consider from a technology perspective, when looking to leverage these systems and evolve them into the Service Oriented world.
To start with, if the application is implemented with VB6, I would strongly suggest moving the codebase to .NET and looking at redesigning some/all of the application, to leverage the fact that the .NET environment has a powerful framework and also, when it comes to Enterprise Services, VB.NET is able to leverage all of the COM+ runtime environment. When considering the options of whether to still use the COM+ environment when moving code to .NET, Enterprise Services may or may not be a relevant option for you. Enterprise Services is COM+ from the perspective of .NET and is an almost parrallel stack with little interop between the two for maximium performance, but some necessary interop for max. flexibiliy/agility/consistency. ES provides full and complete access to the COM+ feature set, as .NET does not have STA constraints and/or the thread affinity issues that the VB runtime had, so all of those options that are available in the COM+ runtime are available to you and you are no longer restricted because of the thread affinity world of VB6, which was severely limiting to the VB developer. As well as this it has many other features worth considering:– ES can be easily accessed from an ASMX app. Allowing you to create a service facade that is loosely coupled, message oriented and verionable; while also allowing you to create one or more communications channel for max interop, reach and flexibility. – It still gives you flexibility in deployment scenarios (when applying layers over tiers, ideal for ISV’s and solutions that target multiple deployment scenarios). While this option is very much distributed object based, IMHO, today it is sometimes necessary due to DCOM’s protocol features/performance but obviously it introduces tightly coupling between the layers when distributed across tiers. So (with no bun intended), a service facade would need to be created into the layers concerned, as the sphere of control not requires that the automous unit deployed/versioned etc.. is composed of more than one tier and that the Service Boundary is that which is the entry point into each tier or in the more likely case, is the entry point into a composite of the tiers.– It still has the fastest protocol on the wire from MS, i.e.DCOM, which is not surprising with over 10+ years of engineering effort and optimisation. While this is relevant to us today, it is important to apprciate that DCOM is a monlithic protocol that is only suitable for scenarios that are within a Service Boundary, where it is neccessary to have – Has a whole host of security options for the wire format and as well as the authorization/authentication for the application. – Eases the effort required for implementing distributed transactions.– Object pooling, JITA, Object throttling, host startup and idle time management, granular security, loosely coupled events, asynchronous disconnected calls, administrative tools and application activation– Allows you to be more explicit between what is exposed between your layers/tiers, in that not every object is implicitly exposed by the ES application, unlike VB6/COM developed objects– Certain features, such as Transactions be accessed directly from within ASMX, without the need for a full serviced component to be created– Code can be easily migrated to Indigo if so desired. There are few exceptions to this.– Easy intergration with Indigo. This obviously applies to COM also, which I will cover later.
When it comes to the move from COM+ to ES, another consideration is for the use case, where you are using COM+ only for Transactions (be they distributed or local, to an execution context). .NET V2.0 introduces the System.Transactions namespace and this is a very innvovation piece of technology that is introduced into the upcoming version of the framework, which I personally feel is the most innvovative (if not one of the top five) additions to the framework in this upcoming release. When I think of System.Transactions, I like to think of it from the perspective of the levels of innovation it brings to transaction processing, like that of its predecessor, MTS. When MTS first came out, it provided us with a platform for building very scalable distributed systems; with its RAD and clean techniques of ensuring consistency when accessing one or more data servers (aka, resource managers, such as SQL Server etc..) through declarative attributes which enlisted hosting environment/container services – was the first mass distributed commerical hosting container - and had a profound impact on how we have developed software for the last 10 years.While there is much written about how MTS/COM+ was not really about transactions, but more about building very scalable distributed object/component solutions, I do think it is fair to say its’ introduction into the
In my view, Transaction services from the hosting container became one of the primary uses of MTS/COM+, while the archiecture was more about building scalable systems and instance management than it was about Transactions. When it comes to migrating Transactional functionality, the System.Transactions namespace maybe something you may want to consider, depending on whether to use ES and/or ES for Transactions and what is required for that layer/tier.System.Transactions offers you implicit transactions, by encapsulating a code block with a Transaction context, but in a hosting container agnostic way, while being very well intergrated with COM+/ES/ServiceDomain. It also provides great performance improvements, through transaction delegation (a “pay as you go performance”, when using only one connection to SQL Server 2005, the DTC is not involved) and transaction promotion will seemlessly occur when a second connection to a durable resource manager occurs within the scope of the transaction (Note, Transaction promotion and delegation will also be available for ES transactions soon). There are many other capabilities to Sys.Tx, because of its independence of instance management and hosting container, it is will worth a look. When considering this option, it maybe an option to place all of your layers in ASMX, create service facades into them and leverage either Transactions at the ASMX level and/or leverage transactions at the code block level. This comes with the obvious caveat that security context etc.. will not flow across service facades or between tiers and this is something to bear in mind, as this is offered by ES/COM+. And also Transaction context will not flow across Service facade, if this functionality is required.
While all of this is great stuff, but if some/none of these options are not possible for you to do right now or in the short/medium term due to some constraints, it does raise the question about what is possible with VB6/COM/COM+/ES applications, in relation to Indigo?
Obviously, there will be offical papers on these topics from the Indigo team in the pipeline when Indigo gets nearer to RTM, but in the mean time, with the offical Beta 1 of Indigo not too far away, I thought I would blog a few entries on the COM/COM+ intergration features in the current Release Candidate of Beta 1, as I find them quite useful to know.
So thats if for now. For the next entry, I will cover the little apps I will use to show the features. So expect some VBA, VB6, VBScript and of course .NET.
I guess before I finish this entry, I will mention that there is the obvious caveat that these are still pre-beta features, so are subject to possible changes etc…. And also, much of what can be done with the Indigo COM/COM+ integration feature set can be done with today’s technologies (with the exception of some of the WS-* protocols), while it maybe a little more work, cracking open mid-tier apps (not necessarily the code, but the tier), analysing the interfaces and designing/implementing/publishing a coarser grained service facade is possible with ASMX/WSE/MSMQ.
The COM/COM+ intergration features of Indigo expands the possibilities in leveraging exisiting assets in your orgainsation, but I feel this should not hold you back from looking at exisiting systems that you have today; performing some Service Oriented analysis on them and leverage them to develop composable unit of functionality.
Rgds,
Paul
ps
Obviously where I use an example of VB6/COM/COM+ in this blog series, these also apply to solutions implemented with Delphi, VC++, J++, etc… its all about the COM binary dll/exe (and its VTable) and the TLB (its metadata) and the very clever internal meta engine of Indigo.