Here's the second wish of the day. IMO it's an important wish, especially in a SOA environment. It's for a chance to designate an object (probably just entity objects) as an external object to the model, belonging to another model.
A typical service-oriented architectural pattern is (or will be) to create an infrastructure of shareable information on top of the technical infrastructure. Such an infrastructure consists of a set of entity services, where each entity service encapsulates a database storing instances of a set of closely related entity types. This database can be accessed by that entity service only; the only way to get to its data is to send a message to the entity service asking it to perform an operation and returning the results of that operation to the sender.
User applications will tend to consume multiple entity services. However, in many cases such consumption of multiple services will be transparent to the consuming application. For example, the application will ask a Customer Service for a complex set of information about a customer. In addition to information about the customer, held by the Customer Service, the application might want information about products the customer have bought. Product information would typically be held by a different service, a Product Service. It might even be so that information about the sales of those products to that customer is held by a third service, a Sales Order Service.
In principle, two different strategies could be applied here. The application could be forced to send two or three different messages to two or three different services, then itself compiling the information received to the single set the application really needs. This could be thought of as a bad strategy, because it would be difficult to improve the operation if needed. If it turns out that this process is to slow, and that the second strategy would be better, then not only the services but also the user application must be modified.
The second strategy is, IMO, a better one. It allows the user application to send the message to the Customer Service only, letting that service compile the information the best way it can and then return a proper set to the application.
Again, there are two ways for the Customer Service to collect the data for the application: (1) it can keep customer data only in its own database, and send messages to the Products and Sales Order services to complete the set needed. (2) a publication scenario can be set up, so that product and sales data are periodically (for example) published from the owners of that data to the Customer Service. If (1) is selected and found to be to slow, then (2) can be selected at a later point without modifications to the user application.
Anyway, in both these scenarios, the Customer Service will have to handle objects which not really belongs to it. In the case described, the response schema will contain entity objects from one or two other services, and therefore from two external models. This will be a very common situation in SOA environments, and at least I believe very strongly that most of us will deal increasingly with SOA over the coming years.
I'm sorry for the long message here, but I wanted so to explain why I think it's so important now to be able to mark, and clearly see, some entity objects as external to the model in which they reside.
/Sten
/Sten