Yes - it's SessionBound. They're available via Session.Services property.

Btw, I'm significantly changing this part right now (this is tightly related to common IoC pattern we use, and that's what I'm working on), so after this refactoring you'll be able to use nearly the following code:

[Service(typeof(IMyService))]
public class MyService: SessionBound, ISessionService
{
  ...
}

...

var myService = mySession.Services.Get<IMyService>()

Nearly the same approach will work for Domain.Services. Moreover, we're going to open access to various internal stuff using this approach, e.g.

var sqlHelper = session.Services.Get<SqlHelper>();
var dbCommand = sqlHelper.CreateCommand();
...

Yes, it will be possible. Currently you should set Domain.Services.SetServiceLocator, which (as I consider) is wrong approach (it was actually one of quick temporary solutions). It's wrong, because it allows to modify the setting after the configuration. So shortly it will work as follows:

1) If nothing special is done, we'll use our own IServiceContainer implementation. It will allow to access the services available in DomainConfiguration.Types, mapping here is done via [Service] attribute and/or configuration section.

2) If DomainConfiguration.ServiceContainterType is specified, we'll use its instance instead of our own; our own container will be chained after it (now we have ChainingServiceContainer). So basically, your own container can override anything.

IServiceContainer is identical to IServiceLocator from CommonServiceLocator project (I re-declared it in Core.IoC just to get rid of CommonServiceLocator assembly reference - we always get complains too many assemblies must be referenced to use DO4, so we slowly reduce this number). So generally any IoC container type can be used with DO4.

See

• http://code.google.com/p/dataobjectsdot ... ?id=573#c3

• http://code.google.com/p/dataobjectsdot ... id=569#c13

No, this won't work on the client, if any remote interaction is implied, because all these objects aren't MBR objects now.

Preliminary version of pattern for remote services is shown in Xtensive.Storage.Samples.Wcf.*. Soon it will be polished, but for now this demonstrates the whole idea.

The latest version in repository (already in stable branch) uses typed results:

[ServiceContract]
  public interface IOrderingService
  {
    // Customer operations

    [OperationContract]
    CustomerResult GetCustomerById(int id);

    [OperationContract]
    CustomerResult GetCustomerByName(string firstName, string lastName);

    [OperationContract]
    CustomerListResult GetAllCustomers();

    // Product operations

    [OperationContract]
    ProductResult GetProductByName(string name);

    [OperationContract]
    ProductResult GetProductById(int id);

    [OperationContract]
    ProductListResult GetAllProducts();

    // Order operations

    [OperationContract]
    OrderResult GetOrderById(int orderId);

    [OperationContract]
    OrderListResult GetCustomerOrders(int customerId);

    [OperationContract]
    void SaveOrders(ModificationSet modifications);
  }

TODOs for us:

• Improve SaveOrders - currently it returns nothing, but ideally it must return either a set of remapped keys & new versions, or an explicit "refresh the UI by re-query" flag (this is the only supported "result" now - i.e. it is void ;) ).

• Convert this console sample to WPF sample (in progress).

• Improve DisconnectedResult<t> & ModificationSet and move them to Storage - in particular, we must support compression there.