July 2004 - Posts
Ingo Rammer found issues not (yet) supported by System.Messaging and gives a brief introduction in calling the C API.
http://www.thinktecture.com/staff/ingo/weblog/archives/001397.html
The SQL Server 2005 Express Technical Preview can be downloaded for free now - but you have to install the .NET Framework 2.0 beta package first.
Don Box identifies four tenets on service orientation:
Tenet 1: Boundaries Are Explicit. Services interact through explicit message-passing behind the boundaries. We make no assumptions on the space behind the service boundaries. Crossing service boundaries can be costly (for example, you may need to span geography, trust boundaries, or execution environments). We explicitly opt in to service invocation, by formally passing defined messages between services. The explicit boundaries allow us to formally express implementation independent interaction—we can be agnostic to choices of platform, middleware, or coding language used to implement other services.
Tenet 2: Services Are Autonomous. Services behave reasonably as independent entities. We make no assumptions on the space between the service boundaries. There is no presiding authority in a service-oriented environment. Services are independently deployed, versioned, and managed. The topology in which a service executes can and will evolve. The service should expect that peer services can and will fail, and that it can and will received malformed or malicious messages. Services should be built not to fail, using (for example) redundancy and failover techniques.
Tenet 3: Services Share Schema and Contract, Not Class. Services interact solely on their expression of structures using schema, and behaviors using contract. The service's contract describes the structure of messages and ordering constraints over messages. The formality of the expression allows machine the verification of incoming messages, which allows us to protect the service's integrity. Contracts and schema must remain stable over time, so building them flexibly (for example, through use of xsd:any in schema) is important.
Tenet 4: Service Compatibility Is Based on Policy. Both service-providers and service-consumers will have policies—operational requirements—for interactions across boundaries. A simple example of provider-side policy is that a service may require that the invoker have a valid account with the service provider. From the consumer-side, an organization may require that service invocations across the Internet be encrypted, so it will only use services that offer the capability of bi-directional security-enhanced data exchanges. Services express their capabilities and requirements in terms of a machine-readable policy expression. Policy assertions are identified by a stable, globally unique name. Individual policy assertions are opaque to the system at large; services must simply be able to satisfy each other's policy requirements.
Taken from Service Orientation and Its Role in Your Connected Systems Strategy.
I've published a new article about Microsoft's Virtual PC 2004 in the latest issue of the dot.net magazin (German). This tool is a must-have for developers and for all friends of buggy beta software ;-) Test your software in a virtual environment and discard changes whenever you want.
More Posts