This is a slightly less technical post, covering my experiences and thoughts on cloud computing as a viable business processing platform.

Recent Amazon EC2 failure was gathering a considerable amount of press and discussion coverage. Mostly discussions revolve around the failure of cloud computing as a promise to never go down, never lose a bit of information.

This is wrong and has been wrong for a couple of years. Marketing people should not be making promises their technical engineers can't deliver. Actually, marketing should really step down from highly technical features and services, in general. I find it funny that there is no serious marketing involved in selling BWR reactors (which fail too), but they probably serve the same amount of people as do cloud services, nowadays.

Getting back to the topic, as you may know EC2 failed miserably a couple of weeks ago. It was something that should not happen - at least in many techie minds. The fault at AWS EC2 cloud was with their EBS storage system, which failed across multiple AWS availability zones within the same AWS region in North Virginia. Think of availability zones as server racks within the same data center and regions as different datacenters.

Companies like Twitter, Reddit, Foursquare, Tekpub, Quora and others all deployed their solutions to the same Amazon region - for example - North Virginia and were thus susceptive to problems within that specific datacenter. They could have replicated across different AWS regions, but did not.

Thus, clouds will fail. It's only a matter of time. They will go down. The main thing clouds deliver is a lower probability of failure, not its elimination. Thinking that cloud computing will solve the industry's fears on losing data or deliver 100% uptime is downright imaginary.

Take a look at EC2's SLA. It says 99.95% availability. Microsoft's Azure SLA? 99.9%. That's approximately +- 7 hours of downtime built in! And we didn't even start to discuss how much junk marketing people will sell.

We are still in IaaS world, although companies are really pushing PaaS and SaaS hard. Having said that, Windows Azure's goal of 'forget about it, we will save you anyway' currently has a lot more merit that other offerings. It is indeed trying to go the PaaS and SaaS route while abstracting the physical machines, racks and local/private datacenters.

During exploration of high availability (HA) features of Windows Server AppFabric Distributed Cache I needed to generate enough load in a short timeframe. You know, to kill a couple of servers.

This is what came out of it.

It's a simple command line tool, allowing you to:

• Add millions of objects of arbitrary size to the cache cluster (using cache.Add())
• Put objects of arbitraty size to cache cluster
• Get objects back
• Remove objects from cache
• Has cluster support
• Has local cache support
• Will list configuration
• Will max out you local processors (using .NET 4 Parallel.For())
• Will perform graceously, even in times of trouble

I talked about this at a recent Users Group meeting, doing a live demo of cache clusters under load.

Typical usage scenario is:

1. Configure a HA cluster
   Remember, 3 nodes minimum, Windows Server 2008 (R2) Enterprise or DataCenter
2. Configure a HA cache
3. Edit App.config, list all available servers
4. Connect to cluster
5. Put a bunch of large objects (generate load)
   Since AppFabric currently supports only partitioned cache type, this will distribute load among all cluster hosts. Thus, all hosts will store 1/N percent of objects.
6. Stop one node
7. Get all objects back
   Since cache is in HA mode, you will get all your objects back, even though a host is down - cluster will redistribute all the missing cache regions to running nodes.

You can download the tool here.

I'm happy to announce our organization work is coming to fruition.

Bleeding Edge 2008 is taking the stage for the autumn season.

Portorož, Slovenia, October 1^st, 9:00

Official site, Registration, Sponsors

Go for the early bird registration (till September 12^th). The time is now.

Potential sponsor? Here's the offering.

I'm a huge fan of document style parameter models when implementing a public, programmatic façade to a business functionality that often changes.

public interface IDocumentParameterModel
{
   [OperationContract]
   [FaultContract(typeof(XmlInvalidException))]
   XmlDocument Process(XmlDocument doc);
}

This contract defines a simple method, called Process, which processes the input document. The idea is to define the document schema and validate inbound XML documents, while throwing exceptions on validation errors. The processing semantics is arbitrary and can support any kind of action, depending on the defined invoke document schema.

A simple instance document which validates against a version 1.0 processing schema could look like this:

<?xml version="1.0?>
<Process xmlns="http://www.gama-system.com/process10.xsd" version="1.0">
   <Instruction>Add</Instruction>
   <Parameter1>10</Parameter1>
   <Parameter2>21</Parameter2>
</Process>

Another processing instruction, supported in version 1.1 of the processing schema, with different semantics could be:

<?xml version="1.0?>
<Process xmlns="http://www.gama-system.com/process11.xsd" version="1.1">
   <Instruction>Store</Instruction>
   <Content>77u/PEFwcGxpY2F0aW9uIHhtbG5zPSJod...mdVcCI</Content>
</Process>

Note that the default XML namespace changed, but that is not a norm. It only allows you to automate schema retrieval using the schema repository (think System.Xml.Schema.XmlSchemaSet), load all supported schemas and validate automatically.

public class ProcessService : IDocumentParameterModel
{
   public XmlDocument Process(XmlDocument doc)
   {
      XmlReaderSettings sett = new XmlReaderSettings();

      sett.Schemas.Add(<document namespace 1>, <schema uri 1>);
      ...
      sett.Schemas.Add(<document namespace n>, <schema uri n>);

      sett.ValidationType = ValidationType.Schema;
      sett.ValidationEventHandler += new
         ValidationEventHandler(XmlInvalidHandler);
      XmlReader books = XmlReader.Create(doc.OuterXml, sett);
      while (books.Read()) { }

      // processing goes here
      ...
   }

   static void XmlInvalidHandler(object sender, ValidationEventArgs e)
   {
      if (e.Severity == XmlSeverityType.Error)
         throw new XmlInvalidException(e.Message);
   }
}

The main benefit of this approach is decoupling the parameter model and method processing version from the communication contract. A service maintainer has an option to change the terms of processing over time, while supporting older version-aware document instances.

This notion is of course most beneficial in situations where your processing syntax changes frequently and has complex validation schemas. A simple case presented here is informational only.

So, how do we validate?

• We need to check the instance document version first. This is especially true in cases where the document is not qualified with a different namespace when the version changes.
• We grab the appropriate schema or schema set
• We validate the inbound XML document, throw a typed XmlInvalidException if invalid
• We process the call

The service side is quite straightforward.

Let's look at the client and what are the options for painless generation of service calls using this mechanism.

Generally, one can always produce an instance invoke document by hand on the client. By hand meaning using System.Xml classes and DOM concepts. Since this is higly error prone and gets tedious with increasing complexity, there is a notion of a schema compiler, which automatically translates your XML Schema into the CLR type system. Xsd.exe and XmlSerializer are your friends.

If your schema requires parts of the instance document to be digitally signed or encrypted, you will need to adorn the serializer output with some manual DOM work. This might also be a reason to use the third option.

The third, and easiest option for the general developer, is to provide a local object model, which serializes the requests on the client. This is an example:

ProcessInstruction pi = new ProcessInstruction();
pi.Instruction = "Add";
pi.Parameter1 = 10;
pi.Parameter2 = 21;
pi.Sign(cert); // pi.Encrypt(cert);
pi.Serialize();
proxy.Process(pi.SerializedForm);

The main benefit of this approach comes down to having an option on the server and the client. Client developers have three different levels of complexity for generating service calls. The model allows them to be as close to the wire as they see fit. Or they can be abstracted completely from the wire representation if you provide a local object model to access your services.

Nick is continuing my discussion on durable messaging support in modern WS-* based stacks, especially WCF.

I agree that having a simple channel configuration support to direct messages into permanent information source (like SQL) would be beneficial.

A simple idea that begs for an alternative implementation of a WCF extensibility point, has some questions:

• What happens when messages are (or should be) exchanged in terms of a transaction context?
• How can we demand transaction support from the underlying datastore, if we don't want to put limitations onto anything residing beind the service boundary?
• What about security contexts? How can we acknowledge a secure, durable sessionful channel after two weeks of service hibernation down time? Should security keys still be valid just because service was down and not responding all this time?
• Is durability limited to client/service recycling or non-memory message storage? What about both?

Is [DurableService]enough?

Jamie Cansdale of TestDriven.NET fame just posted an intro post describing the hosting of Silverlight's CLR - CoreCLR.

Having the ability to host the runtime inside a Win32/.NET process brings up new possibilities, especially running Silverlight apps outside the browser or developing test harnesses/unit tests for Silverlight intended object models.

Silverlight 1.1 alpha and CoreCLR currently expose a very trimmed down version of the Framework's BCL. This will change by RTM, but be aware that its sweet spot is still the browser.

I can imagine a world where Silverlight apps will not only be media/presentation related. Currently, the competing platform, though having a strong install base, has not reached into that space.

You could arm Flash developers with rocket launchers, but they would still lose a battle war against .NET developers armed with chopsticks. Every day of the week and twice on Sunday. I believe the number of souls will significantly influence the outcome in this case.

WCF includes support for establishing a security session through a simple configuration attribute. The primary reason of a security session is a shared security context which enables clients and services to use a faster, symmetric cryptographic exchange.

WCF sessions should not be thought of in terms of HTTP based sessions, since the former are initiated by clients and the latter by the servers. In other terms, WCF sessions are there to support some kind of shared context between a particular client and a service. This context can be anything, and is not limited to security contexts.

The attribute that establishes a security session and shared context is called, well, establishSecurityContext and is present in binding configuration. An example of such a binding would be:

<bindings>
  <wsHttpBinding>
    <binding name="SecureBinding">
      <security mode ="Message">
        <message clientCredentialType="Certificate" establishSecurityContext="true"/>
      </security>
    </binding>
  </wsHttpBinding>
<bindings>

This binding allows HTTP based communication, demands message based security (think WS-Security) and uses certificates to sign/encrypt the message content. The attribute establishSecurityContext is set to true, which actually enforces a WS-SecureConversation session between the client and the service.

The following is a simplified version of what is going on under the covers:

• Client instantiates the service proxy
  No message exchange is taking place yet.
• Client requests a SCT (Secure Context Token)
  This is done by the infrastructure, when the first service method is called. SCT (again simplified) represents a secure context, which includes the symmetric key. The message which demands it is (per WS-SecureConversation spec) called RST (Request Secure Token).
• Service responds with RSTR (Request Secure Token Response) message
  Session bootstraps and is ready to piggyback all further message exchanges.

What is not well known is that there is a very low limit on the number of sessions a service is willing to accept. The default is set to 10 sessions and this was changed (from 64) late in the WCF development cycle (summer 2006). So RTM ships with this default.

Service session count is greatly influenced by the instancing scheme the service is using. Since instancing is a completely different beast, let's leave this for another post (uhm, I already wrote something here). Let's just say that hitting the session problem is a non-issue when using singleton instancing (InstanceContextMode = InstanceContextMode.Single).

The main issue is, that most developers think of Indigo WCF services in terms of simple request-response semantics and forget that such sessions get queued up on the service side if you do not terminate them appropriately.

This is the default service throttling behavior in the shipping version of WCF:

<behaviors>
  <serviceBehaviors>
    <behavior name="DefaultThrottlingBehavior">
      <serviceThrottling maxConcurrentCalls="16"
                         maxConcurrentSessions="10"
                         maxConcurrentInstances="<Int32.MaxValue>" />
    </behavior>
  </serviceBehaviors>
</behaviors>

Every service is throttled, even if you don't specify it. You can, of course, override all three throttling parameters.

Sessions can only be initiated by the client. They can be explicitly terminated only by the client. There are three ways a session can get terminated:

• Explicitly by the client
• Implicitly by a timeout
• Implicitly by errors

Timeout can pass on a client or a service and, if the timeout happens, the transport channel that ensured communication gets faulted (Channel.State = CommunicationState.Faulted). Session is also terminated if an error is detected, thus invalidating the possibility to continue.

Remember that every service proxy you use will demand a new session on the service side (when using
sessionful services). If you spawn 11 threads and use a non-singleton proxy you will cause 10 sessions on the service side. The 11^th will not get setup and will block the client thread until the timeout expires. In this case, the WCF infrastructure on the service side will issue a warning in the trace log, but nothing will be returned to the client. It seems as if the service would stop working. Nada.

There is a method on every service proxy and it's there for a reason. The method is called Close(). It closes the transport channel graciously and terminates the security session, thus freeing up service resources. The same happens for reliable messaging session or a combination of both.

Note: Another message (pair) is exchanged on Close(). This message is saying "We are done." to the service. Thus, one should be cautious when calling Close() for any exceptions, like CommunicationObjectFaultedException.

The best practice is to catch any CommunicationException exceptions when closing the channel.

To illustrate this, consider the following. You call a single method on a sessionful service. Then hang on to the service proxy instance for an hour. The inactivity timeout (attribute inactivityTimeout on a RM binding) is set to 10 minutes. So, ten minutes after the first call the channel gets faulted. Then you call Close(). This call will fail and throw an exception.

The following is the expected way of communication with sessionful services:

ServiceClient proxy = new ServiceClient("<Configuration>");
try
{
  // call service methods
  int intSum = proxy.Add(1, 2);

  // ... call all other methods ...

   // call service methods
  int intSum = proxy.Subtract(1, 2);

  // close session
  proxy.Close();
}
catch (TimeoutException ex)
{
  // handle timeout exceptions
  proxy.Abort();
}
catch (FaultException<T1> ex)
{
  // handle typed exception T1
  proxy.Close();
}
...
catch (FaultException<Tn> ex)
{
  // handle typed exception Tn
  proxy.Close();
}
catch (FaultException ex)
{
  // handle all other typed exceptions
  proxy.Close();
}
catch (CommunicationException ex)
{
  // handle communication exceptions
  proxy.Abort();
}

Note that using the using statement is not recommended. The problem of using statement in this case is that CLR automatically calls Dispose() method on the using variable when exiting the statement. Since Close() can fail (remember, another message is exchanged), you can miss this important exception.

Everything in this post is true for all kinds of WCF sessions. It is not limited to security or RM sessions only.

In the previous post we discussed possible scenarios and methods for configuring reliable message delivery in WCF. Let's look further into this great WCF feature.

Delivery assurances can have a large impact on the way your code processes incoming messages. Especially, ordering can be of importance if your code relies on ordered message delivery. Since configuration can be changed by any WCF service administrator there is a knob in WCF which lets you demand the appropriate binding. The knob is in a form of a declarative attribute, called DeliveryRequirementsAttribute.

Here's how it's used:

[DeliveryRequirements(RequireOrderedDelivery = true,
   QueuedDeliveryRequirements =
      QueuedDeliveryRequirementsMode.Required)]
interface IServiceContract
{
   int Operation(int a, int b);
}

DeliveryRequirementsAttribute can be set on any service interface or service class implementation. It has three properties:

1. QueuedDeliveryRequirements which has three possible values, Allowed, NotAllowed and Required. Setting NotAllowed or Required makes the binding either demand or prevent WS-RM usage. Setting Allowed does not make any requirements.
2. RequireOrderedDelivery demands a binding that supports and has ordered delivery turned on.
3. TargetContract property is applicable only when the attibute is applied to a class definition. Since WCF service interfaces can be implemented by multiple classes, one can specify a specific interface for which the queued delivery requirements are defined.

The specified contract interface would demand a WS-RM capable binding and thus prevent service administrators to turn reliable delivery off.

In case where an administrator would turn reliable delivery (or ordering, in this case) off, the service host would throw an exception while trying to host the service.

So, DeliveryRequirementsAttribute guards developers from wrongdoings of service administrators. It should set QueuedDeliveryRequirements = QueuedDeliveryRequirementsMode.Required or RequireOrderedDelivery = true, when there are objective reasons to demand guaranteed and/or ordered delivery of messages.

Windows Communication Foundation includes concepts which enable the developer to insist on reliably delivering messages in both directions. The mechanism is actually transport agnostic and allows messages to be flown reliably from client to service and replies from service to client.

Underneath, WS-ReliableMessaging (WS-RM) implementation is used. Click here for Microsoft's specification. Content is the same.

WS-RM is based on a concept of a message sequence. You can think of it in terms of a session, although it does not carry HTTP session semantics (remember, it's transport agnostic). A communication initiator (RM source) sends a <CreateSequence> element inside the message body to establish a RM sequence. Service side (RM destination) responds with either <CreateSequenceReponse> or <CreateSequenceRefused>, in cases where new sequence is not welcome.

After the sequence is initialized, there is an additional SOAP Header in messages. It identifies the message number being transferred. The following is a simple example of headers of the first two messages:

<S:Envelope>
   <S:Header>
      ...
      <wsrm:Sequence>
         <wsrm:Identifier>http://webservices.gama-system.com/RM/Service</wsrm:Identifier>
         <wsrm:MessageNumber>1</wsrm:MessageNumber>
      </wsrm:Sequence>
   </S:Header>
   ...
   <S:Body>
      ...
   </S:Body>
</S:Envelope>

<S:Envelope>
   <S:Header>
      ...
      <wsrm:Sequence>
         <wsrm:Identifier>http://webservices.gama-system.com/RM/Service</wsrm:Identifier>
         <wsrm:MessageNumber>2</wsrm:MessageNumber>
      </wsrm:Sequence>
   </S:Header>
   ...
   <S:Body>
      ...
   </S:Body>
</S:Envelope>

After all messages have been exchanged and acknowledged, the RM destination sends a <SequenceAcknowledgement> inside the body of the message. RM source (communication initiator) then tears down the sequence with a <TerminateSequence> message.

So, how can this specification be implemented in various technology stacks? Well, WCF implements reliable messaging using the in-memory message buffers. There is no durable reliable messaging support in WCF.

Here's how it works:

• Communication initiator (client) sends a <CreateSequence> message.
• Service side responds with a <CreateSequenceResponse>.
• Client sends 1..n messages and buffers them, while waiting for all acknowledgements.
• Service side can and will dispatch the received messages as soon as possible. Now, there are two options:
  • Communication is configured for ordered delivery
    First message will be dispatched to the service model as soon as it arrives, noting that it has been processed. Every other message is processed in order. If message number 5 has been processed and the next received message carries sequence number 7, it will not be dispatched until message 6 is received and processed by the service model.
  • Communication allows out-of-order delivery
    First message will be dispatched to the service model as soon as it arrives, so will all the following messages. Since we did not demand ordered delivery the processing pipeline does not care on when to process the messages. It will process them as soon as they are received. They are acknowledged as soon as possible, but not before acknowledgement interval.
• Service side sends a <SequenceAcknowledgement> message only when all messages have been acknowledged.
• Initiator then stops the sequence with a <TerminateSequence> message.

So, how do we go about enabling WS-RM and realizable delivery in WCF? Simple. Here's the config file:

<wsHttpBinding>
   <binding configurationName="myReliableBinding">
      <reliableSession enabled="true" ordered="true" />
   </binding>
</wsHttpBinding>

The <reliableSession> element has two attributes. The first one, enabled, enables reliable message delivery. The second one, ordered, enables in-order processing by the service model.

One has to acknowledge that the following is true for different WCF bindings:

basicHttpBinding - RM not supported
wsHttpBinding - RM supported, not default
wsDualHttpBinding - RM implicit
netTcpBinding - RM supported, not default

There are a couple of options available for anyone using the custom binding, in regard to reliable messaging behavior:

1. acknowledgementInterval specifies the time lapse duration of message acknowledgement. The default is two seconds, while always acknowledging the first message. This gives you an efficient way to group the acknowledgement messages, thus conserving network traffic.
2. flowControlEnabled enables message sender to acknowledge the receive buffer on the recipient side. It turns out that every acknowledgement message includes a service buffer status and if this attribute is set, sender will not send messages if the recipient buffer is full, thus not occupying network resources.
3. inactivityTimeout defines the absolute duration of a no-message (infrastructure and application messages) session. After the timeout, the session is torn down.
4. maxPendingChannels defines how many reliable channels the service can put in its waiting-to-open queue. If there's a significant load, the pending requests can queue up and the service refuses to open a reliable session (think <CreateSequenceRefused>).
5. maxRetryCount defaults to 8. It defines how many times the infrastructure retries with message delivery. If the limit is achieved, the channel will become faulted.
6. maxTransferWindowSize defines how many messages should be buffered. On service side all messages that have not been acknowledged increase the count. On the client side, all messages which have not received their acknowledgement pair are counted.
7. ordered defines in-order delivery. It's values are true and false.

There is some confusion in the wsHttpBinding's <reliableSession> config element. There's an enabled property in the Visual Studio config schema, which should not have any influence on reliable session establishment (and does not have a matching object model method/property). It does, however. There is a difference if you setup a reliable session by using a customBinding or wsHttpBinding.

I.e., here's the custom binding config:

<customHttpBinding>
   <binding configurationName="customReliableBinding">
      <reliableSession ordered="true" />
   </binding>
</customBinding>

This will enable reliable and ordered session support in any custom binding.

So, in general - WCF implementation of WS-ReliableMessaging gives you automatic message retries, duplicate detection, and ordering. It should be turned on for any multi-hop message paths, but can be very valuable even in high latency/packet loss network scenarios.

Update 2007-02-19

William Tay, a friend and distributed systems expert, replies with a terrific message exchange pattern for groking WS-RM specification. Don't walk, run.

Third incarnation of the .NET 3.0 Middleware Technologies day went through yesterday.

Here are the deliverables:

• PPT: Download [1]
• WCF Samples: Download
• WF Samples: Download

If you did not get/notice the printed articles, here's what should put you to sleep over the weekend:

• Concepts and Semantics of Service Contracts [1]
• Transactional Semantics in Loosely Coupled Distributed Systems [1]
• Cooperation Between Workflows and Services [1]
• Type Systems Compared - XML <> CLR [1]

Also, the accompanying book is available here.

[1] Only available in Slovene.

Second incarnation of the .NET 3.0 Middleware Technologies day went through today.

Here are the deliverables:

Code: Download
PPT: Download [Slovenian]

Frequent answer still stands. This is the best playground.

Since there is so much interest, we are discussing a third repeat of the series. Anyone who wanted to attend, but did not get a seat, stay tuned.

We had a nice discussion throughout the day today, together with around 50 attendees. It's hard to even cover feature changes of .NET 3.0 in a day, but we managed to cover the important things of WCF and WF, spending a complete day inside the Visual Studio.

Here are the demos: Download
And the PPT slides: Download [Slovenian]

And the link to the Tom Archer's compatibility matrix for the .NET Framework 3.0 downloads.

Thanks to everyone who attended.

Last article finished my XML series. This one focuses on transactional semantics in a service oriented universe.

Language: Slovenian

Naslov:

Transakcijska semantika v šibko sklopljenih, porazdeljenih sistemih

The second article is about concepts and semantics of service contracts. It deals with WCF (Windows Communication Foundation) contract definition and its behavioral aspects.

Language: Slovenian

Naslov:

Koncepti in semantike storitvenih pogodb

Having spent the last two weeks tweaking my diagrams and pictures with a book designer, I learned quite a lot about differences in a design and development environment. To get facts straight, they live in a DPI-based world, which is nasty. And since my designer uses MacOS X platform to do the design stuff, a lot of interesting issues arrised. Again.

What I wanted to convey is: The book is finally done.

Title (in Slovene): Arhitektura sodobnih rešitev Microsoft .NET - Načrtovalski vzorci

Its physical incarnation should be available to general developer/architect public in a few weeks, but most definitely here.

Everyone who managed to send me an email after my previous blog post, will be getting a copy in his/her mailbox today.

If you would like a copy (electronic one, that is), drop me an email using this link.

Here's the TOC, up to level 3, (in Slovene):

1    PREDGOVOR
2    UVOD
3    OZADJE
3.1    O PLATFORMI
3.2    O PROGRAMSKIH JEZIKIH
3.3    O NAČRTOVALSKIH VZORCIH
3.3.1    Začetniki koncepta načrtovalskih vzorcev
3.3.2    Načrtovalski vzorci v informacijski tehnologiji
3.3.3    Načrtovalski vzorec: Windows DNA
3.3.4    Porazdeljene transakcije
3.4    SPLOŠNO O PORAZDELJENIH STORITVAH
3.4.1    Strateški pomen Enterprise Services
3.4.2    Prihodnost Enterprise Services
3.4.3    Hitrost COM+
3.4.4    O .NET Enteprise Services
3.4.5    O porazdeljenem transakcijskem koordinatorju (MSDTC)
3.5    KJE SMO?
4    NAČRTOVALSKI VZORCI
4.1    NAČRTOVALSKI VZOREC PORAZDELJENE APLIKACIJE
4.1.1    Ideja
4.1.2    Porazdeljena aplikacija potrebuje nivo fasade
4.1.3    Porazdeljena aplikacija potrebuje nivo dostopa do podatkov
4.1.4    Objekti entitetnih storitev validirajo poslovna pravila
4.1.5    Ločeno upravljanje transakcij
4.1.6    Procesi
4.1.7    Kje smo?
4.2    NAČRTOVALSKI VZOREC SPLETNE APLIKACIJE
4.2.1    Namen
4.2.2    Struktura
4.2.3    Stran začasnih naročil
4.2.4    Objekt DataSet
4.2.5    DataSet <> DataTable <> DataAdapter
4.2.6    Kje smo?
4.3    NAČRTOVALSKI VZOREC PODATKOVNEGA DOSTOPA
4.3.1    Namen
4.3.2    Struktura
4.3.3    Razredi
4.3.4    Dodajanje novega naročila
4.3.5    Kaj pa transakcije?
4.3.6    Dostop do podatkov
4.3.7    Kje smo?
4.4    NAČRTOVALSKI VZOREC ENTITETNIH STORITEV
4.4.1    Namen
4.4.2    Struktura
4.4.3    Primer poslovnega pravila
4.4.4    Nivo dostopa do podatkov
4.4.5    Validacija poslovnih pravil
4.4.6    Naprednejši koncepti validacije poslovnih pravil
4.4.7    Kje smo?
4.5    NAČRTOVALSKI VZOREC POSLOVNE FASADE
4.5.1    Namen
4.5.2    Struktura
4.5.3    Kdaj uporabiti?
4.5.4    Razmislite o spletnih storitvah
4.5.5    Kje smo?
4.6    NAČRTOVALSKI VZOREC TRANSAKCIJSKIH STORITEV
4.6.1    Transakcije in .NET v splošnem
4.6.2    Namen
4.6.3    Struktura
4.6.4    Kako deluje?
4.6.5    Kdaj uporabiti?
4.6.6    Kako uporabiti?
4.6.7    Kje smo?
5    .NET ENTEPRISE SERVICES
5.1    KAKO UPORABLJATI .NET ENTERPRISE SERVICES?
5.1.1    Načrtovanje komponent
5.1.2    Razredni in članski atributi
5.2    NAMESTITEV KOMPONENT
5.3    KJE SMO?
6    UNIČEVANJE VIROV
6.1    METODA FINALIZE
6.1.1    Dedovanje iz System.Object
6.1.2    O finalizaciji
6.1.3    Kdaj uporabiti finalizacijo?
6.1.4    Oživljanje
6.2    METODA DISPOSE
6.2.1    Kdaj klicati metodo Dispose?
6.3    BREZ UPORABE .NET ENTERPRISE SERVICES
6.3.1    Podatkovni nivo – osnovna komponenta
6.3.2    Podatkovni nivo – ostale komponente
6.3.3    Komponente drugih nivojev
6.4    UPORABA V .NET ENTERPRISE SERVICES
6.4.1    Podatkovni nivo – osnovna komponenta
6.4.2    Podatkovni nivo – ostale komponente
6.4.3    Komponente drugih nivojev
6.5    KJE SMO?
7    VIRI

If you still don't have my previous book, Arhitektura spletnih storitev - Usmeritve za načrtovanje, you can write to me using this link.

Thanks again to all the reviewers and especially to Microsoft gals who had to read this technical, unreadable text during the proof reading process. Thanks to Mateja from Alten, for doing a fantastic design work.