The ORM Foundation

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

Hi Sten,

Good questions, and well stated.  I hope you get feedback on this from several people.

I don't have an answer for you but will offer a few comments.

ORM, and NORMA are well along in development and use, but not fixed.  Expect to see more functionality in the tool, and more types of modeling addressable by the ORM/NORMA framework.

Even if you don't see the ORM/NORMA as encompassing all the aspect of the modeling and implementation required by your agenda, you can still get a lot of value from an incomplete modeling of the facts within any UofD.  You can always place notes, and placeholders where you know you'll need something not implementable yet.  The model won't generate a correct and complete implementation, but it can help you get your ducks in a row.

Always keep in mind that the concept of objects in ORM is not the same as in Object Oriented techniques.  One type may translate to another in some instances, but they are conceptually different, and are not interchangeable.  While your endgame may require OO objects, think in terms of fact based ORM objects for the conceptual model.  For example, if your UofD includes companies, you'll likely have an ORM Company entity type object.  This will have some value types associated with it, like Name() Address(), etc...; yet the Company entity object is a conceptual representation of a "real world" concept. An OO Company object has an independent existence as a "real world" thing - IT exists, IT has properties, IT can consume stuff and spit stuff out, it has code behind it; even if its reason for existence is (like an ORM entity), to represent companies in the "real world."  We can get really weird with some epistemological roundabouts, but isn't it fair to think of these two conceptions of an object in these terms? 

There's no reason that you can't create ORM Objects to represent OO objects, within an ORM model.  Also, a real tool to assist and automate the methodology of ORM is going to use OO objects to do that (internally).  So, it's not a matter of "this is what an object is, ... No, an object is really...." I think it's keeping the distinctions in mind that's important.  Know where you are in the modeling process, and have it straight in your mind what it is you are trying to model, and you can't go far wrong.

I look forward to seeing what others say about your question/comments, and mine.  BRN..

Thanks again Brian,

I strongly agree with your statement about objects in ORM being different from Objects in OO techniques. In fact, I tend to think about the ORM objects as terms rather than as objects, terms which refer to underlying concepts.

As a matter of fact I'm not very interested in so-called domain objects in OO. This is because I'm intensely interested in SOA, which means that "components" - or rather services - can't talk directly to each other's objects but only by sending messages to each other. This makes the service stateless in the sense that it can't keep any temporary state in memory for its consumers between messages. It can only keep state in the database or in some session object. Therefore, it doesn't make much sense to create domain objects in main memory.

There's also the question of impedence mismatches. One of the most talked about problems in OO is how to handle the object-relational impedence mismatch. In SOA there's also an impedence mismatch between the structures needed by consumers for business reasons, represented in message schemas, and the typical domain object structures. So, if you insist in managing a service's internal functionality through domain objects you take it upon yourself to manage double impedence mismatches. In my opinion it's much better to allow message objects, perfectly matching the contracts' message schemas, to flow between the database and the service interface.

I look forward to more comments to this thread.

Chears
/Sten

Hi Sten,

From this last reply of yours concerning SOA, you gave me a few ideas to check out using NORMA.  Also, it's important to have people (like yourself), that are knowledgeable and skilled in SOA style and techniques, participating in ORM development discussions, such as this one.  Please do keep posting comments and questions.

Here are two other places that I (and some others here), look to for answers and information exchange for ORM and related topics:

    http://tech.groups.yahoo.com/group/information_modeling/

        Clifford Heath got this started this past spring, and there's a pretty good discussion on using and expanding the NORMA framework.  There are some serious OO and agile development people that bring that perspective to the table.

    http://ormfoundation.net

        This is the recently revamped (and nicely done), website for ORM Foundation.  I think only a couple of forums there are open as of yet, but the framework for several others is in place.  You could take up the idea of adding a SOA/ORM forum (if there isn't one already), with the site's creator/administrator: Ken Evens.

I think you know how knowledgeable and skilled the NORMA team members are; it's often that they are so pressed for time, that they can't respond to posts here as much as they would like to.  If you have an important question or comment, try addressing it to them directly - if they don't respond to a post here.  It may take a while for them to get back to you, but  nobody knows more about the topic, or are as dedicated to its development.

BRN..

Brian,

Thanks for the tips. I haven't been in those places you suggest yet, but I'm certainly going to.

And I totally agree with what you're saying about the Neumont team. Terry and I go back quite a while now, and Matt has been really helpful too. They are great guys, and they know what they are doing. And we all know that Terry is the undisputable Mr ORM.

If you're interested in some SOA matters, you might want to take a look at our website at http://www.2xsundblad.com/en. You'll only find stuff that has to do with SOA and with architecture. There are some articles, which are absolutely free. You'll also find a preview of a training course called Architecting Service-Oriented Systems - Overview. The preview is in Macromedia Flash, but we're doing the production version in Microsoft Silverlight (which wasn't quite available when we started to create the preview.) I must say that Silverlight and the Expression suite are so awesome, so much more than we ever expected.

/Sten

Hi,

Thanks for the link - I'll check it out.  

Got the SilverLight presentation from an MSDN tour in my area a couple of months back, just after the .Net 3.0 release.  Bob Familiar (MS New England region), did the segment.  I'm impressed with how good the stuff looks, given the fairly low bar set for hardware requirements, and the short DL time MS set.  Expression Suite isn't in the budget, but I'm planning to play with the stuff through VS a little anyway.

Attended some good SOA webinars and live events as well.  No doubt about the impact it has, and will have going forward.  BRN..