|
Sponsored Links
Resources
.NET Research Library
Get .NET related white papers, case studies and webcasts
|
News
News
News
|
Messages: 26
Messages: 26
Messages: 26
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Developing Distributed Services Today
Richard Turner has written a new article providing guidance on technologies and creating distributed systems today that will be able to work in future environments, such as when Indigo is released. In addition to overall guidance on which technology to use, the paper also discusses new features that will be available in Indigo that justify that guidance.
The article starts with a brief discussion of the issues involved with distributed object approach to system development.Object technology was designed as a local programming concept that assumed many things in order to make the technology work. For example, object technology originally assumed that objects would run within the same process and on the same platform (OS or runtime). We then began to stretch that object technology by building components that spanned multiple processes on a given machine (using COM and, more recently .NET). We then stretched this technology further still by providing mechanisms (COM+ and later, .NET Remoting) that enable components running on more than one machine to communicate. Many distributed systems have been built on our distributed component technologies. These systems can exhibit extremely high levels of performance, security, reliability, and availability. The basic guidance is to use ASMX web services, enhancing these with WSE in the cases where you need WS-* functionality. He also discusses when to use Enterprise Services, Remoting, and MSMQ and how those decisions will affect the future integration with technologies such as Indigo.Your investment in developing with ES is protected because you will be able to expose your ES/COM+ components as "Indigo" services by running a simple command-line tool—no code changes required! Read Developing Distributed Services Today
|
|
|
Message #178827
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Developing Distributed Services Today
Great piece of marketing but very inaccurate when it comes to talk about distributed computing. Having worked in that field since 1994 I think I can challenge some of the things he states.
|
|
|
Message #178836
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Developing Distributed Services Today
Please do so, instead of just stating that you probably can. Thnx in advance.Great piece of marketing but very inaccurate when it comes to talk about distributed computing. Having worked in that field since 1994 I think I can challenge some of the things he states.
|
|
|
Message #178861
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Developing Distributed Services Today
but very inaccurate when it comes to talk about distributed computing
What exactly?
I think I can challenge some of the things he states.
Then do so!
|
|
|
Message #178875
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Developing Distributed Services Today
As soon as Indigo is officially released, I believe .Net Remoting and COM+ are not likely to last very long. The more I understand about Indigo and its future direction, many if not all features provided by remoting and COM+ have been directly superceded, ASMX and MSMQ are much less impacted.
I still somehow doubt that all the hypes about SOA and the global web services that the industry is taking us. How much actually are the issue of compatibility, performance, ease of use for developers to jump on this band wagon, deployment, and acceptance of the industry? Didn't they promise us 10 or 20 years ago that they will unite us with DCOM, CORBA, and many cool distributed technologies which are the way out?
A very unconvincing developer.
|
|
|
Message #178879
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Developing Distributed Services Today
As soon as Indigo is officially released, I believe .Net Remoting and COM+ are not likely to last very long. The more I understand about Indigo and its future direction, many if not all features provided by remoting and COM+ have been directly superceded, ASMX and MSMQ are much less impacted. If I understand Indigo correctly (big ?), there will be a single API for messaging, with the underlying technologies varying between something like remoting, web services and MSMQ, etc. So I think I agree, with the addition that preferred APIs to the technologies you mentioned changing somewhat.
--Kevin
|
|
|
Message #178885
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Developing Distributed Services Today
As soon as Indigo is officially released, I believe .Net Remoting and COM+ are not likely to last very long.
Incorrect understanding of what Indigo and Remoting are. Indigo is a messaging stack (essentially a large abstraction layer) in the application space. Remoting is a communications subsystem (essentially a transport and packaging system). They are different technologies solving different problems and in fact Indigo can utilize any number of different transport systems including Remoting. There are plenty of other application servers out there that are built on the same concept (Base4 and even the EDRA are built on that idea).
The more I understand about Indigo and its future direction, many if not all features provided by remoting and COM+ have been directly superceded, ASMX and MSMQ are much less impacted.
That is because the engineers at MS are not idiots and reuse existing technologies they have developed. This is aggregation of technology and not replacement. For example, the same windows APIs and services that COM+ use are in turn used by ES. The same holds true in 2.0 with the System.Transaction namespace.
|
|
|
Message #178912
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Developing Distributed Services Today
Incorrect understanding of what Indigo and Remoting are. Indigo is a messaging stack (essentially a large abstraction layer) in the application space. Remoting is a communications subsystem (essentially a transport and packaging system). They are different technologies solving different problems and in fact Indigo can utilize any number of different transport systems including Remoting. There are plenty of other application servers out there that are built on the same concept (Base4 and even the EDRA are built on that idea).
It's true that Indigo can use transport system using Remoting and they are different technologies solving different problems. From the Indigo's perspective, I see no reason for using Remoting because I can build Indigo client and server and solve everything there is and better that Remoting has to offer. One primary reason for continue with Remoting is backward compatibility.
That is because the engineers at MS are not idiots and reuse existing technologies they have developed. This is aggregation of technology and not replacement. For example, the same windows APIs and services that COM+ use are in turn used by ES. The same holds true in 2.0 with the System.Transaction namespace.
If the same API is used by COM+, ES and System.Transaction in 2.0, then I agree with you. From what I read, System.Transaction doesn't require registration the way COM+ transaction does.
|
|
|
Message #178920
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
random comments
* Interoperate broadly between platforms and devices.
* Integrate your systems with Microsoft products and technologies.
* "Future-proof" your systems so that you can adopt and integrate with tomorrow's technologies without requiring massive investment in time and effort.
* Compose your applications into autonomous, cooperative services that can be independently deployed, managed and versioned, enhancing your ability to adapt rapidly to changes in the business' environment.
The first two items in the bullet points seem rather general, but good points to make. The third claim of "future-proof" feel wrong to me. If we look at history from Tux, Tuxedo, Corba, COM, COM+, EJB, RMI and Remoting, there is no such thing as future proof. All the vendors are guilty of making these silly claims. The forth claim is a nobel goal, but in practice, it takes experts and years of experience to really build a large application meeting all those requirements.
Using Indigo will make the guts easier, but it doesn't begin to make a dent towards services that really can be version and developed independently. Just look at the history of MapPoint.NET from 2001 to 2005. With every new release, those using the older version had to invest several months to rewrite and validate the changes. Having used the pre-SOAP version of MapPoint and the first SOAP version, the change was significant. The change from the first version MapPoint SOAP to the second version required quite a bit of recoding also. It's easy to see that by reviewing the different API versions of MapPoint.
To the best of my knowledge, the only way to build distributed applications that meet the lofty goal of being independent requires a lot of discipline and years of experience. Your average developer would need to spend 3-6 years in the trenches to learn these lessons.
One of the most commonly misunderstood concepts with ES/COM+ components is around the nature of transactions. A transaction in this context is a two-phase commit transaction often associated with databases such as SQL Server or other transacted resources including MSMQ. The purpose of transactions is to ensure that two or more changes applied across two or more transacted resources are completed atomically, or if there is a failure or problem detected during the transaction, that all changes are reversed so that no partially updated data is left in the system.
I don't like this definition of transactions from the article. The purpose of transactions in a distributed environment isn't just a simple commit/rollback or atomicity. In real world distributed transactions, the systems have different transaction thresholds and states. The point of distributed transactions is to provide a normalized way of handling difference in state and manage different transaction thresholds. Take for example a banking system.
Federal regulation requires that every single transaction is logged. What that means is the system must log every single transaction. If the logging system is down or cannot commit the transaction to the audit log, the entire transaction should be rolled back. In many cases, if one system is busy and unable to handle the transaction, the transaction should queued and retry later. This way, the process can continue and bottlenecks are avoided. On the other hand, if a critical insert/update fails, it may be necessary to rollback the entire transaction. That includes all sub-transactions that are involved.
The article gives me the impression the author has never had to build an application that dealt with distributed transactions. Or at best, only simple distributed transactions. If that's all Indigo is designed for, then I would say there's still a mountain of work needed to support real-world scenarios.
peter
|
|
|
Message #178943
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
random comments
Federal regulation requires that every single transaction is logged. What that means is the system must log every single transaction. If the logging system is down or cannot commit the transaction to the audit log
What federal regulation? the Durability aspect of ACID already guarantees that no transaction can be succesfully commited if it cannot be written into the audit log so that in the event of a sudden system failure, the entire steps can be replayed back. This is fundamental. I think the article simply doesn't explicitly state that.
|
|
|
Message #178948
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Developing Distributed Services Today
Because the underlying technology is the MSDTC service. Syste.Trans doesn't use COM+ but calls the same low level system APIs that COM+ did. 2PC in windows is way lower than COM
|
|
|
Message #178984
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
random comments
Federal regulation requires that every single transaction is logged. What that means is the system must log every single transaction. If the logging system is down or cannot commit the transaction to the audit log
What federal regulation? the Durability aspect of ACID already guarantees that no transaction can be succesfully commited if it cannot be written into the audit log so that in the event of a sudden system failure, the entire steps can be replayed back. This is fundamental. I think the article simply doesn't explicitly state that.
I don't remember the exact law, but if you look at recent actions by the SEC about email retention, you'll the see the federal goverment requires accurate audit logs. The CPA guidelines also have recommendations about audits and how much to log. The the best of my limited knowledge, that means every single transaction has to be logged. Even if it's as simple as changing a customers address.
I'm not talking about Database audit logs here. All financial systems are required to maintain an audit log, which keeps a record of a customers transactions. The log is used to reconcile any problems and make it so the federal government can tack where money is going or coming from. Database level audit logs are the minimum requirement for building financial systems. Above that is a mountain of regulations the system must comply with.
My own fault for being unclear and assuming others know this domain. Say a bank has 4 separate and distinct systems. If changing the customers address requires updating all 4 systems. In this type of scenario, each system has to have its own audit log. That means at minimum, a single "change my address" transaction involves 8 separate Atomic transactions. 4 would be updates and 4 would be audit logs. Some systems are very restrictive and log the beginning of the transaction and subsequent success or failure.
Managing this kind of transaction in my mind is not appropriate for soap webservices. When I said "In real world distributed transactions, the systems have different transaction thresholds and states.", I meant this.
Say you're writing a wireless portal that integrates with 3 different partners. In your system, a customer's account is either active or cancelled, but the other two systems have different states.
system A:
active, cancelled
system B:
active, cancelled, suspended, inactive
system C:
active, cancelled, suspended, inactive, violation, locked
Say a customer initiates a transaction from System B and the transaction has to propogate to the other two. In many cases, the threshold for committing the transaction will differ and managing the distributed-ness of the transaction is the hard part. What's worse is these transaction might go over the internet or a VPN. One system might not be able to talk to the others, so the transaction should be queued and the user should be able to proceed.
hopefully this is a less obtuse explanation.
peter
|
|
|
Message #179015
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Why wold COM+ disappear with Indigo ?
COM+ deals with more than just RPC : what about Loosely Coupled Events, Queued components, JIT Activation, Object Pooling... Does Indigo include all these services ?
|
|
|
Message #179168
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Why wold COM+ disappear with Indigo ?
COM+ deals with more than just RPC : what about Loosely Coupled Events, Queued components, JIT Activation, Object Pooling... Does Indigo include all these services ?
Indigo supports Message Queueing. In regarding to JIT activation, Object Pooling, I first thought it includes those features, but I was wrong when I revisit many MSDN articles on Indigo.
|
|
|
Message #179276
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
random comments
Federal regulation requires that every single transaction is logged. What that means is the system must log every single transaction. If the logging system is down or cannot commit the transaction to the audit log What federal regulation? the Durability aspect of ACID already guarantees that no transaction can be succesfully commited if it cannot be written into the audit log so that in the event of a sudden system failure, the entire steps can be replayed back. This is fundamental. I think the article simply doesn't explicitly state that.
You are comparing apples to oranges. Nobody is talking about Database Transactions but Application Transactions as Peter Lin has correctly pointed out.
I was also left with the impresion the author does not have experience building Enterprise Distributed Applications. And please dont think that just because your application talks to 2 separate DB servers it is distributed. There are more complex scenarios in real life which seem the author does not have familiarity with.
|
|
|
Message #179277
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
random comments
One of the most commonly misunderstood concepts with ES/COM+ components is around the nature of transactions. A transaction in this context is a two-phase commit transaction often associated with databases such as SQL Server or other transacted resources including MSMQ. The purpose of transactions is to ensure that two or more changes applied across two or more transacted resources are completed atomically, or if there is a failure or problem detected during the transaction, that all changes are reversed so that no partially updated data is left in the system. I don't like this definition of transactions from the article. The purpose of transactions in a distributed environment isn't just a simple commit/rollback or atomicity. In real world distributed transactions, the systems have different transaction thresholds and states. The point of distributed transactions is to provide a normalized way of handling difference in state and manage different transaction thresholds. Take for example a banking system.Federal regulation requires that every single transaction is logged. What that means is the system must log every single transaction. If the logging system is down or cannot commit the transaction to the audit log, the entire transaction should be rolled back. In many cases, if one system is busy and unable to handle the transaction, the transaction should queued and retry later. This way, the process can continue and bottlenecks are avoided. On the other hand, if a critical insert/update fails, it may be necessary to rollback the entire transaction. That includes all sub-transactions that are involved.The article gives me the impression the author has never had to build an application that dealt with distributed transactions. Or at best, only simple distributed transactions. If that's all Indigo is designed for, then I would say there's still a mountain of work needed to support real-world scenarios.peter
I agree with Peter. The author seems to relate to DB transactions whereas the context is about distributed transactions and they are more like a simple 2-phase commit scenario. You can have transactions and subtransactions and these in turn can be dependent on some other or maybe totally independent. Again, the context for these distributed transactions is the application they relate to so no quick cookbooks here.
|
|
|
Message #179278
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Developing Distributed Services Today
but very inaccurate when it comes to talk about distributed computing What exactly?I think I can challenge some of the things he states. Then do so!
The author says:
Object technology was designed as a local programming concept that assumed many things in order to make the technology work. For example, object technology originally assumed that objects would run within the same process and on the same platform (OS or runtime).
As far as my knowledge is concerned the above is a false statement. Object technology was designed first as an abstract concept first with no relation whatsoever to the underlying platform layer. When the time came to implement this as programming languages, it was just constrained by the known limitations at that time. As far as objects running in the same process and on the same platform it was not an assumption done per see but rather the concept used at that time when the concept of distributed applications was non-existent.
A point to keep in mind is that although we often use Object Oriented Technology for building distributed applications the fact is that Distributed Systems are not Object Oriented Systems.
|
|
|
Message #179282
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
random comments
I agree with Peter. The author seems to relate to DB transactions whereas the context is about distributed transactions and they are more like a simple 2-phase commit scenario. You can have transactions and subtransactions and these in turn can be dependent on some other or maybe totally independent. Again, the context for these distributed transactions is the application they relate to so no quick cookbooks here.
I was probably a bit hard on the author of the article. In relative terms, my experience with distributed transactions has been focused in very specific areas. I'm sure there are all sorts of distributed transactions which I have absolutely no clue. I still consider myself a newbie when it comes to hair raising distributed transactions that have to integrate with mainframes. With my limited knowledge, the world of distributed transactions feel a lot more varied and complex than the author of the indigo gives credit.
peter
|
|
|
Message #179611
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
random comments
I agree with Peter. The author seems to relate to DB transactions whereas the context is about distributed transactions and they are more like a simple 2-phase commit scenario. You can have transactions and subtransactions and these in turn can be dependent on some other or maybe totally independent. Again, the context for these distributed transactions is the application they relate to so no quick cookbooks here. I was probably a bit hard on the author of the article. In relative terms, my experience with distributed transactions has been focused in very specific areas. I'm sure there are all sorts of distributed transactions which I have absolutely no clue. I still consider myself a newbie when it comes to hair raising distributed transactions that have to integrate with mainframes. With my limited knowledge, the world of distributed transactions feel a lot more varied and complex than the author of the indigo gives credit.peter
I think you have an over the average understanding of distributed transactions than most people here. It's very sad to see that still there are some guys who think that distributed transactions (or computing for what it matters) are no more than old C/S applications talking to more than one database.
|
|
|
Message #179725
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
The Author Responds
Thanks to everyone on this thread for reading the "Developing Distributed Services Today" whitepaper that I recently published on MSDN and posting commentary here.
I've just posted an article on my blog responding to many of the comments and criticisms levelled in many of these discussions - please post follow-ups there if required.
|
|
|
Message #179730
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
random comments
Using Indigo will make the guts easier, but it doesn't begin to make a dent towards services that really can be version and developed independently It's dangerous to make definitive statements about something you don't yet understand. In fact, we're planning technology within Indigo to enable services to support multiple versions of data contracts simultaneously without having to host multiple implementations - something that is very, *very* hard to do today.
Now, of course, there are scenarios where the next major version of a service needs a major revamp and this is when one would publish a new contract and implementation - this is something that cannot really be catered for via some magical feature - this is where good, clear design is required.
|
|
|
Message #179841
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
random comments
In fact, we're planning technology within Indigo to enable services to support multiple versions of data contracts simultaneously without having to host multiple implementations - something that is very, *very* hard to do today.Now, of course, there are scenarios where the next major version of a service needs a major revamp and this is when one would publish a new contract and implementation - this is something that cannot really be catered for via some magical feature - this is where good, clear design is required.
As far as I know, I've been using that approach since 1997. There are/were tools that allowed you to publish services (dont confuse them with webservices) and broker the request for a particular version of one depending on the service signature used to invoke it in a particular application environment.
|
|
|
Message #179889
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
random comments
Using Indigo will make the guts easier, but it doesn't begin to make a dent towards services that really can be version and developed independently
It's dangerous to make definitive statements about something you don't yet understand. In fact, we're planning technology within Indigo to enable services to support multiple versions of data contracts simultaneously without having to host multiple implementations - something that is very, *very* hard to do today.
thanks for responding and clarifying my bad assumptions. since I don't work for microsoft, I have no clue what the future plans are, so please accept my apologies. I was probably unclear and obtuse in my explanation. Just in case. The type of scenario I was thinking of this.
1. I build an application that uses a partners webservice and I only use the wsdl to generate my client code.
2. my business partner uses my WSDL to build the corresponding client on his end to call my services.
3. I sign a new customer who needs additional features I currently do not provide.
4. I want to provide a new version of my service for the new customer without breaking the existing services.
5. the new features require changes to my object model and my database model
6. my application has to have a concept of domains, to keep the data for each customer in a separate domain.
In my bias opinion, that is a lofty goal, but it's not practical. What does Microsoft consider "support multiple versions of data contracts simultaneously without having to host multiple implementations"?
If the goal is to support multiple object models, I would think using mapping techniques would be the easiest way to handle this. I've done this on several occasions in the past integrating customer data across 3-5 partners. In my case, the data was in 5 different formats. Or, does Microsoft mean data contracts as in the WSDL operations? I would think careful planning would reduce the need to change the WSDL operation name and signature. If a change requires change to a operation signature (ie inputs), then it's better to have separate implementations form a management perspective. This way, the old service can stay on one machine and slowly phased out.
Now, of course, there are scenarios where the next major version of a service needs a major revamp and this is when one would publish a new contract and implementation - this is something that cannot really be catered for via some magical feature - this is where good, clear design is required.
My main criticism is the definition of distributed transactions was simplistic and not representative of the types of transactions I've dealt with the last 5 years.
peter lin
|
|
|
Message #180372
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
random comments
Hey Peter.
Schemas define the structure of data that a given service exchanges with clients. Contracts define what the service looks like and what operations it exposes. Indigo enables you to modify an existing data schema to include new (optional or mandatory) fields not included in prior published versions of the schema without having to host and maintain individual instances of each version of a service's implementation as StarTrooper points out is a common solution to the problem today, but one frought with support and maintenance cost and difficulty. It is precisely these reasons that led us to design data contract versioning support into Indigo - to defer the need to support multiple instances of a given service.
If one needs to break an existing schema, however, by breaking the established contract (eg: removing or changing the type of published fields), then the chances are that you'll break existing deployed apps and should instead consider publishing operations that support for the older schema in addition to the new schema where possible.
Changing operational contracts (WSDL) on the other hand is a very difficult thing to do cleanly in a general manner without breaking existing apps. If an app's semantics and protocols need to change significantly, then yes, this is a time when you'd need to consider supporting multiple versions of a given service or providing some type of mapping technology but this approach, as I have mentioned before, rarely is something that is easily solved.
|
|
|
Message #180374
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
random comments
Only since 1997??? Wow - what took you so long? ;) This practice has been in wide use ever since applications that share data have evolved beyond V1. Is there any better example of why modern languages have the switch or case statement?
You can also do some clever things with the packet-aware technologies such as ISA Server too! :)
If you've read my blog at all, you'll know that I've never mixed up the notions of a service and a web-service.
|
|
|
Message #180381
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
random comments
Hey Peter.
Schemas define the structure of data that a given service exchanges with clients. Contracts define what the service looks like and what operations it exposes. Indigo enables you to modify an existing data schema to include new (optional or mandatory) fields not included in prior published versions of the schema without having to host and maintain individual instances of each version of a service's implementation as StarTrooper points out is a common solution to the problem today, but one frought with support and maintenance cost and difficulty.
Agreed. when ever the schema (aka object model) changes, the implications are not always clear at first. And often a simple addition actually means significant changes. Although the idea of hosting "versioned" services sounds desirable, in practice I find it like walking a tight rope. It's generally better to create a proxy service, which uses the new schema. of course this approach leads to chaining services and creates a different set of problems. If taken to an extreme, someone could change 20 services together and result is poor performance. One of the reasons I asked for clarification is that I like the idea of dynamically generating the schema at deployment time and allow schema extensions. some people may not like this approach. To facilitate this type of interaction, I wrote my own Schema compiler for C# named Dingo.
It is precisely these reasons that led us to design data contract versioning support into Indigo - to defer the need to support multiple instances of a given service.
If one needs to break an existing schema, however, by breaking the established contract (eg: removing or changing the type of published fields), then the chances are that you'll break existing deployed apps and should instead consider publishing operations that support for the older schema in addition to the new schema where possible.
Changing operational contracts (WSDL) on the other hand is a very difficult thing to do cleanly in a general manner without breaking existing apps. If an app's semantics and protocols need to change significantly, then yes, this is a time when you'd need to consider supporting multiple versions of a given service or providing some type of mapping technology but this approach, as I have mentioned before, rarely is something that is easily solved.
That's an interesting approach, but I would think removing types or fields from a schema should be done with caution. Since the data is most likely persisted in a database, removal of fields impacts persistence. By going with data contract versioning, does it mean Microsoft is still committed to providing an ORM solution so that RDB and Objects can be mapped to each other more easily?
peter
|
|
|
| |
|
| New content on TheServerSide.NETNew content on TheServerSide.NETNew content on TheServerSide.NET |
|
|
Language "mashups" will become more prominent, and developers will become polyglots, one programmer suggests.
SearchWinDevelopment.com offers an introduction to the language, performance, testing and data management improvements in VS 2008.
VBCode.com code snippets cover all aspects of application development, from data binding to security to the user interface.
Get up to date on XAML best practices with a variety of articles, tutorials and webcasts. [SearchWinDevelopment.com]
One team's experience with the VSTS DB edition suggests that it can improve workflow for dev teams. It also enhanced Agile efforts.
(June 24, Article)
Microsoft has begun to include DSL tools in the VSTS kit. A new book by Steve Cook and other VSTS team members helps set the stage.
(June 24, Article)
Cartoon: Be it ever so humble there is no place like your home after you get a Microsoft Home Server .
(June 18, Cartoon)
Microsoft's Thom Robbins says new technology to highlight in NET 3.5 includes AJAX, LINQ for both C# and VB, as well as tooling enhancements intended to ease the task of building WPF, WF and WCF apps.
(June 29, Podcast)
Venkat Subramaniam discusses AJAX bottlenecks, the tenets of Agile development and more. He spoke at the Ajax Experience.
(June 25, Tech Talk)
In the second of a two-part series, Michele Leroux Bustamente discusses design decisions related to the claims-based security model. Read the story and walk through the process for creating a set of claims-based utilities to encapsulate claims authorization at the service tier.
(May 24, Article)
Understanding why the Entity Framework exists and learning where it can fit into your projects can get you prepared for the eventual release early next year.
(May 10, Article)
Resource: This learning guide gives you quick access to useful links on Windows Communication Foundation security information.
(April 24, Article)
TSS.NET's Jack Vaughan spoke recently spoke with Microsoft's Brad Abrams to find out what he is seeing in the field and what the chefs in Redmond are cooking. Along the way he discusses patterns of AJAX frameworks.
(April 11, Article)
In a two-part series, Michele Leroux Bustamente explains how claims-based security is supported by WCF, and how you can implement a claims-based security model for your services.
(March 29, Article)
Windows Workflow Foundation is a new technology that many developers will need to get their heads around. In a brief excerpt adapted from Programming Windows Workflow Foundation: Practical WF Techniques and Examples using XAML and C#, K.Scott Allen considers aspects of workflow definition.
(March 22, Chapter Excerpt)
|
|
