big thoughts in the software world
|
|
benjaminm's blog big thoughts in the software world |
| Home | About | Presentations |
|
WSV201 Indigo: Services and the future of Dist. Apps Don Box, PDC.
Indigo is a long term commitment from MS, begun in 2000.
The software ecosystem: inevitability of connected applications No program is an island. It's not by accident that in the first C program, HelloWorld, the sole executable statement is has a dependency on the standard io library. Programs need other programs to get their work done.
Don has looked at how to link programs together. There's all kinds of technical ways of getting applications to work together. A program often depends on programs that you will ship as one unit. Often this isn't a problem because when you ship your program that uses other other applications the build environment has munged it all together. The 80s and 90s were about breaking the physical packaging of applications into distinct library units. The dream was independent versioning and deployment.
There's often been an attempt to work with programs on different machines. Microsoft and others have had technology to achieve this goal. Unfortunately it's please trainers rather than those that ship software. It's all been the same problem from the 50,000ft view, but it's not quite so simple.
Object Ecosystem: One metaphor to rule them all In the past decade the main idea has been objects. In the 80s and 90s object orientation was considered radical. Now no-one thinks like this anymore. 20 years since the start of objects we've had an industry focus on making object technology work. It's fairly simple to use and we know what the limitations are. We've reduced the performance tax of using objects. But objects were basic in the 80s and took a long time to get viable. It's only now that OS's are making deep commitments to object technology. Windows XP and 2003 aren't built on object technology but on Win32 which was c-oriented, procedural language. Longhorn is still a 'few weeks away', with it's primary object access based on objects. .NET is a thin veneer over the existing goop.
The primary way to access longhorn is managed code: its an object. It took a long time to extend objects from projects to a large framework like Windows. People will stay behind and work at the lower level: ignore them. Every technological wave where the level of abstraction is raised, has stragglers. Natural selection will take care of this. Everything is going to managed. A phrase to stay gainfully employed: 'Do you want fries with that?'
Object technology is fantastic, I can't imagine not having it. However, the way I want to think about the world, the set of abstractions at my disposal, may not be the same ones I want to use when forming a system of co-operating programs. I'm not convinced the same metaphor will work. I'm sceptical because I was in the object wars trying to make COM stretch. COM was an attractive elixir that is hard to make work in reality. The idea was to take a single programming model, take objects and stretch it. What did we find? It was difficult to make work in a real production environment, especially the non-technical issues such as what technology is being made within an organisation? The technical choices being made in an organisation may not even be rational.
Object technology used to build co-operating projects relied on a premise that was false: all programs will share as much as possible (type system model, object model, deployment model). A focus on commonality, shared infrastructure. We stretched it till it broke. No one had a seamless DCOM experience. Corba is the same ('most of them are at work now trying to get it to work').
The notion that I could take a single metaphor, designed for the local in-memory case and stretch it was something the industry thought would work, but it didn't work. Virtually no systems are built exclusively with DCOM or Corba is evidence it wasn't possible to pull it off in a broad industry-wide way.
It's always been tacked on to the side. We never achieved critical mass. The most successful was Http. This is not dead. Why does it work? We had an entire industry saying - we had to make this work. We have Apache and IIS, we know they work and work well.
However, to say Http works doesn't mean we should build in it. It's an unfortunate hack that got ground swell and worked, but it's still not the right mechanism.
The Service Ecosystem: Respecting the boundaries of others There's a new metaphor we can make work well in the distributed case. The metaphor of the service that can bring together programs across platforms and across boxes. The fundamental premise of the service-oriented world. The idea of SOA over objects relies on a boundary between programs.
In the OO world there was a lot of coupling. Boundaries are important. There are many ways in which they exist (Don demonstrated this by getting physical). There are lots of ways to violate boundaries (such as asking someone 'how much did you earn last year?'). Intuition you have about the real world is often valid about the software world. There are social rules. Boundaries are important and we should except them. Sometimes it's reasonable (e.g. If I'm the accountant). There are exceptional ways to cross boundaries when needed. Service oriented architecture is making boundaries explicit in the world of software.
The service-oriented model: Services, Clients and Systems In the trade press are saying there is this SOA business. In Indigo we're taking SOA to the masses so that we can bring it to the masses and build programs in it. We're in the job of making systems work. Indigo involves concrete technologies.
What is a service? A service is a program you communicate with using messages.
What's a client? Another program that uses the service. How does it use it? It sends message.
What's a systems? In OO we think of apps. I'm an app developer, the killer app. We think in systems - deploy and done is a fiction that is over. The real world write programs that have to co-exist with other apps and business processes. I am building and maintaining the system. I will build it piece by piece, new ones will come, old ones will go. The idea that it will be fixed is not the way the world works. Things change in lives, it's no different for software.
Service orientation says an app isn't the interesting outcome. Rather having a system that is up and running and will change over time is the higher order bit.
Tenet 1: Boundaries are explicit Developers opt-in to exposing service-based functionality.
Indigo is just a set of DLL's. What we are trying to institutionalise is these four tenets. First is boundaries. The first is that I know where the lines in my program are. The notion that I can take a program and through config become a web services is naive. Platforms support it, should we have done it, no, but we will atone for our sins with Indigo.
The premise is that developers opt-in. You must opt in to make your code accessible. We don't make it hard but we do make it explicit
Tenet 2: Services are autonomous. Independent deployment, versioning and security. I need to make sure that my program works, even if yours doesn't. I'm part of systems I can't control. I have responsibility - reliability and availability. If I put a service out, then it will be available, even in 6 months. It will be there in a predictable way.
I have to be 1000 times more concerned about security. The world is one where packets fly freely. I can't rely on a firewall. I need to make sure my services is secure, in an authenticated environment with authorisation. If I don't have it, then I have to roll it myself. While this was fun for GUIs, RPC and serialization, you don't want to roll your own security infrastructure. It needs many human eyes to have some hope that it is secure.
Security and reliability are important.
We will deploy things independently. If I redeploy I need to know that things wont break. As something evolves I need some way of controlling what happens to everyone else in the system who relies on David. The idea of a schema or interface repository doesn't exist in the real world. I can't rely on changes made in one place flowing out to another. I need to make choice so that I can do that evolution in a safe, sane, non-wild west.
Tenet 3: Share Schema, not class Integration based on message formats and exchange patterns, not classes and objects.
We share schema and objects. In OO we have a class that provides a single atomic abstraction of state and behaviour. If I control everything, classes are great. If evolution is independent then it is hard, if not impossible. To have a class that is shared between two people is a deep commitment. For us to share a class there has to be an in memory or wire representation as well as code associated with this class. We're letting one app inject code into our mission-critical app.
So, we'll use inheritance. We'll load any inheritance as well. You could poke an orifice into another project and put some code in there to make it run. Java RMI is based on this. If you're happy with this, it's a reasonable choice. We don't want that degree of intimacy.
We have either schema - structural things such as the wire format or in memory layout (same platform) of integers and strings into structures that have no behaviour, or we have contracts. Contracts are schema over time - it describes a set of messages exchanges between services in terms of behaviour. Interactions. The interactions are messages that are schematised.
Classes conflate sate and behaviour. Schema are about representation, Contract is about behaviour. The two don't meet.
Tenet 4: Policy-based compatibility Service compatibility based on policy assertions using stable global names.
We can't assume a central repository of type information. XML Schema started with the idea of a one schema against all data. My schema is distinct from your schema on the same data structure. My assumptions and validation may be different than yours. A shared schema in a central schema repository is a fiction.
So what are we left with. I need to know my program today will work with yours yesterday that may be deployed tomorrow. Policy associates stable global names based on URIs with ideas and concepts. To work out if I can work with you is not based on having the same interface definition, but what are the capability of your service vs. my requirements.
We can use it in discovery, directory lookups or services or any time I need to decide is this the service that I should use?
You can use these ideas today. The platform we have shipped is workable and reasonable at building SOAP apps, but it is not obvious how to do it (how to live in this world), but we have learnt how to do this from the field.
Use ASMX or ASP.NET Web Services. Of all the technologies the one that it is the closest to the truth is ASMX. It's not perfect or ideal, but it is good enough for most things. Best bet today.
The best way to understand it is to use ASMX and .NET remoting. It is the clearest stack of the two ideas butting head.
Remoting is the OO and distributed OO paradigm. It is the finest implementation of distributed object-oriented paradigm released. It has accessible extension points that are pluggable. If you like Corba, RMI or EJB then .NET remoting did everything you did. It is never going away. However, it is not the future direction of the way service systems should go.
You can use a service oriented approach with remoting if you're extremely disciplined. If you're the sort of person who is writing OLEDD providers in assembly - it's for you. It is such a seductive technology - it's compelling to use the OO features that don't translate into service oriented approach, so don't use it remoting for these types of services.
ASMX is not the best technology on the planet. It is a reasonable implementation of a couple of good ideas. The most profound idea, the single differentiation point, of SOA for OO is the way proxy objects works. In OO we perform unnatural acts in order to make sure that an object reference marshalled outside my domain. With ASMX I don't have a proxy like COM (where we assured object identity and the proxy infrastructure got out of the way).
ASMX forces me to think, this is a proxy, this is different when I call a method I'm leaving my app domain and process and even when the URL in the webservice goes out and comes back. ASMX doesn't try to get the proxy out of the way. Accessing the service should be distinct to access things like an object.
Serivces and MS:Indigo A simple technology with a couple of DLLs to make it work, but it serves many services to the platform. It is .NET technology for building and deploying service oriented software. It makes it simpler to build connected applications. We respect the environment around us. We don't assume that the world will have Indigo or windows.
We don't assume that all of your programs will move to Indigo overnight. We don't want it to be seriously disruptive.
Indigo is a bunch of DLLs The were arranged into the following groupings on the slide:
Service (instance manager, context manager, service method, type integration, type integration, declarative behaviours, transaction methods)
Connector The connector layer takes a SOAP message aware of the service oriented model and moves them from place to place in a secure, reliable fashion. It also handles message session. The connector layer can be loaded without loading the service model.
A lot of current environments make developers use one of two approaches. Things are either sockets - do it on your own, or EJB style hosted environment where the approach is 'we [the platform] know everything. Neither is acceptable on its own.
Hosting
Services Message Services We are building stuff that if we didn't build, you'd build it yourself. We are not building the uber queuing system - we are not a replacement yet for MSMQ - we have support for routing, but we aren't replacing CISCO, we support eventing but we aren't a replacement for Tibco. We give you the basic plus the wire protocols to make it work. We provide extensibility hooks.
System Service
What does Indigo Provide What are you getting? We're making the service oriented approach easy for you to do on the CLR. Making it easy for service-oriented programs. We do this by making boundaries come into focus.
A simple service: System.ServiceModel; System.Runtime.Serialization; // the new formatter
// a data structure. This is my service oriented data type. I tell the service about it using the following attribute: [DataContract] // This attributes tells Indigo that this structural type has a schema and I'm going to explicitly control how that schema works. What I do is data contract for the type and the members Public class Person { [DataMember] // I have to add opt in in order to user the service, so I must take an action by using an attribute to make this a service. Private int age; Public string name { get { … } set {…}}; Public bool isTired; }
[Service] //opt in action to make it accessible Public class MyService
{ [ServiceMethod] - promote it to make it part of the service contract. We ignore the CLR accessibility rules - we don't care about OO style fashion, we care about the service oriented fashion. I want to do things different in a service than I would if we were one module within an app domain. Private void f(Person p) {}
Prublic void g() {} }
Service orientation is not something we make lightly. You must deliberately take the step. It's disjointed from the OO façade of your code. We make boundaries explicit. You have to mark it up yourself.
Indigo and Unification Make it easy to share features from each stack inside one single unified model that we will make as fast as humanly possible. If you want it cross proc, like it version from ASMX. Like Enterprise for tx and reliability.
As long as you know that Indigo is on the box, just write to it's API
Indigo and Interop: secure and reliable reach Secure, reliable transactions with partners. All the infrastructure does this. Wer're using WS-Security, WS-AtomicTransactions, WS-ReliableMessaging. We're making these protocols accessible and easy to use for all programmers on the platform.
Indigo and Continuity: we have a lot of that code too… We wont rip and replace and screw the customer. It's easy to do it, but harder to when we've said 'bet on us' and they have made commitments to technologies that we believed in and believe can still continue to work. We are trying to leave as few people behind as possible.
We're loading Indigo into Office and VB6 as well as bringing MSMQ and live within the ecosystem and communicating using the WS-* specs.
Jo Long has an excellent talk on what we are doing to make sure that COM+/ASMX/ES/REMOTING don't get left behind. The transition is simple, often just a re-compile.
Preparing for Indigo today:
Services: The Next 20 years We're at 1987 in the object arc with the service oriented approach. It is easier to do it now than it was earlier.
Ultimately Indigo and the service oriented approach is a bunch of simple ideas that is hard to argue against. It will take us a long time to get there. |
| Copyright 2003 Benjamin Mitchell |