In essence, I’m trying to go meta, and do exactly what SQL Server does, just at a system wide level.

I had in mind some sort of configuration file that defined all the relationships between the entities of the system. The business rules engine would use these to check whether an association could be created at runtime. For instance, the Business service call AddOrderToCustomer(o,c) would go check with the BusinessRules service by checking the result of the call CanAssociate(o,c). This call would check if:

1. The relationship between Customer to Order is 1-1 and that each of the entities ( order+id, customer+id ) wasn’t already associated with a different entity. For instance if a Customer with id=1 was already associated with Order id=2, then the call to check if an association between Customer id=1 and Order id=3 can be created should return false.

2. The relationship is 1-many and the given order isn’t already associated to a customer entity.

3. The relationship is many-many and the assocation between the given customer and order doesn’t already exist.

In other words, I working towards creating a generic association service that will work on any and all types of entities, and the associations between them.

The associations are themselves stored in a database, could be the same DB as the system itself. The tables used are as follows:

1. A table for storing binary relationships ( 1-1, 1-many, many-many )

2. A table for storing tertiary relationships ( many-many-many ).

3. I haven’t yet needed quarternary relationships, but you can see where this is going.

The binary relationship table is quite simple:

FirstTableName – string

FirstID – int ( or string for those who like GUIDs )

SecondTableName – as above

SecondID – as above

Tertiary and the rest would be done in the same way just with a Third*.

I’ve tried this method on several development projects with much success. However, these projects have had little changes in the domain model during their lifetimes, so the benefits of the technique were not really felt.

I’m not advocating that this is how you should go and develop a production system, but rather floating this idea that’s been growing on me for some time.

I like the fact that it greatly simplifies the rest of the system and allows changing the "domain model" of a system while it is still running. What I worry about is the effect on performance. Obviously this is slower than optimal, the question being – would it become the system bottleneck ? I don’t know yet. From all the tests I’ve done, its nothing too serious in cases when you don’t have upwards of a million rows of associations. That’s when you have to start doing some serious measurements to see how an optimal, non-generic solution compares.

This isn’t fully baked yet, but I like the way its turning out. I think that just thinking about these things helps me better understand the service-oriented, separation of concerns mindset that I find so necessary when working on large, complex, long projects that have high probabilities for change in major architectural ( that’s OOA ) portions of the system. When working SO, my capability to react to change without impacting my architecture is greatly increased.

Think about it, then tell me about it.

-James

-Brian

Even at the database level where entities are persisted into tables, you won’t find any connection between them. All the relationships between entities are persisted separately from the entities themselves. You wouldn’t have a CustomerID field in the order table, for instance

Imagine, not having to update any CRUD sql because you changed a relationship from 1-many to many-many. Not having to change data access code. This is separation of concerns.

Anyway, all out of time.

Bye

You are the yang to my ying, and I thank you for it.

Udi

Despite the fact that I always seem to argue against you, I thoroughly enjoy it, and cannot (wholly) disgree with (most of what you have to say.

-Brian

Interesting — though I cannot say I like it, I can see the possible benefit of the externalized relationships, but I don’t think that the way you do it is any better.

If the relationship service always returns a collection, change the object to always have collections as properties so it may have 1, or 100, or none. Either way you have to write code that deals with what the service gives back to you, and that code gets coupled to the number of addresses ( 0-1, 1, 1-N, 0-N). You still have the maintenance headache, but you also now have less expressive code.

Need to think on this some more =)

-Brian

I shall reiterate.

The set of Service Layer, Remote Facade, and Data Transfer Object patterns are essential components of SOA. The Data Transfer Object pattern is implemented by what I call entities. These entities form the schema in SOA.

Now, as to Brian’s comment, the relationships between entities are not found in the entities themselves. A customer entity, for instance, would not have a collection of order entities as a property. Rather, in order to get the orders for a customer, you would turn to the Association service calling the method GetOrdersForCustomer and pass the customer entity as a parameter.

It is in this manner that entities are all self defined, and the relationships are externalized. Why is this good ? Because the changes in relationships 1-1, 1-many, many-many back and forth are localized, and client code is less coupled to it.

For instance, changing the customer-order relationship from 1-many to many-many requires no changes in client code. The same call as above is used – GetOrdersForCustomer. This creates systems that are more robust to change.

And this, Brian, is how to handle the Address example you threw back at me =) , that is, as long as Address was implemented as an entity in its own right. Had it been implemented as a string property of customer, this would have been more problematic.

Eventually I’ll get around to writing a full fledged post on how to do the whole persistence/relationships thing in SOA.

I definitely agree with you that SOA is really about the larger systems, and groups of applications working together. That is why in this article I tried to steer the discussion away from talking about the internals of the service, as that is just not as important as the overall architecture.

-James