Ramkumar, YES !!! That is exactly what I’m talking about. Its a different way of thinking about systems. The object is no longer at the center of architecture, but is relegated to implementation status.

When people speak of SOA as the “Death of Objects”, in my opinion, it is really the death of OO Analysis & Design. We’ll see less and less inheritence hierarchies. We’ll see less and less complexity in our systems. This is what we’ve all been striving for, after all.

Sorry for my flippant comment. It stems from reading so many people who seem to think that so-and-so (usually Microsoft) is inventing service architectures Right Now ™.

That isn’t what you were saying, and I apologize for the flippancy of my comment.

-Brian

I fully agree (heh, why wait for Indigo? I do it now in Java

Ramkoth,

What are you using for the rules system? I haven’t found anything that I like the price on that has grabbed me as a standard-to-use yet.

-Brian

a) Business concepts such as Person and role (Note: I didn’t use the word business objects).
b) Business rules that act upon facts. Business concepts are just one type of facts. There are different types of business rules such as Structural, Validation, Policy etc. They can be enforced at different layeers.

c) Business services: Services offered by your business system. Business services provide a service contract. Interaction is essentially message oriented. Request and response Message carries a ‘Document’. Document may contain information about facts.

d) Business activities: These include CRUD type stuff and other computation required to satisfy business requirements.

e) Business Process: There are three types of processes namely: Human workflow, UI Process and scheduled process. Scheduled process is automated process that is composed of business activities and business rules. Human workflow also defined further notions of tasks, actors, roles etc.

I strongly believe these are the first class abstractions. One can use some OO patterns to implement any of these abstractions. But, they are secondary abstractions.

I think you were completely misunderstanding my post. Business object have no business handling persistence. The “Business objects” represent business objects, things relevent to the business domain.

I completely agree with you that not everything can or should be modelled as an object – but it does work for an awful lot of things.

All of your questions are best answered by “it depends” — as a starting point the business object represent business enitities. To use the classic example domain, modeling a basic HR application, your Person, your Role, may be your starting points — from there you clean it up to match your problem domain, or start with other points.

The business rules belong in A) business classes B) a rules system that operates on business objects, C) or somewhere else — it depends on the problems being addressed.

I agree that persistance is just-another-service. In the layering paradigm you mention said service could be seen as an underlieing layer, but that implies that a clean layering can in fact be provided.

A better model, and I cannot remember who proposed this originally or I would give him or her credit, is to simply view any interface between classic layers as yet another API to the system/service/application. The vogue way of modeling this is as an interconnected service system with an expensive EAI system brokering the services. Regardless, you publish an API that others can use, and you use API’s provided by others. You try to make your API as general as you can without making it so general as to be useless, and if you need to cross application boundaries, or platform boundaries, you get into the fun stuff like SOAP.

If you have a system for modelling HR services than it should model HR services and make use of available services for doing things it needs to do but doesn’t know how to – persistence, interacting with a user, interacting with leanring management systems, interacting with mail generating systems, etc.

In well over 99% of applications a very clean and effective way to do this is simply via IoC style abstract factory stuff as well over 99% of applications don’t need to cross application boundaries nor provide services that cross application boundaries.

-Brian

What are the other responsibilities of the business objects, besides persistence ? Where do the business rules reside ? Is there any division between code with a high probability of change, and that with low probability ? For instance, relationships between entities have a reasonable probability for change. Is the code that deals with the relationships separate from the basic persistence of the entities ?

I find that SOA answers all these questions, and more, much better than an OO architecture – even when layering the system.

What are your thoughts ?

-Brian