Help! Evil services are killing my objects...

Question

When I believed in American dream about encapsulation and polymorphism, intrusion of Web Services washed my objects off with RPC calls...

When I cherished my resurrected PONOs, ugly army of barbarians called proxy objects conquered my lands...

Later, peace seemed to come back with DDD and NHibernate on the server side, but the SilverLightning hit my castle, now there's hunger again, delicious lazy loading is only in my memories, and for years now my poor objects have to consume stale services again...

And I am full of fear...the world is talking more and more about some other terrifying procedural monsters...they call them "Workflows"...

How can I save my objects? Literally, I do not provide anyone any services. I am building a simple small system. I don't want to use services to find my data. I do not want to use services to talk from my web interface to my web interface...as I don't want to use snail mail to talk to my colleagues.

Any ideas? Did you manage to save your objects? Did you manage to save more than your domain model? (hopefully you managed the latter...)

Update: If this was not clear... We have a killed architecture because everything is using web service based. There was a fashion "OO - is dead", services rule. In SOA, it is still quite hard to focus on objects when everything is focusing on verbs ("operation contracts"). I feel it is hard to take care of your design.

Answer 1

Clearly you haven't take your abstraction pills this morning. Now, take your nice medicine and you'll feel better in a little while...

Answer 2

Beware you foolish mortals. The Entity That Is has indeed fed on your polymorphed objects. But this also means that you have inherited the Big Slimy Interface that lurks in the dark. So you can retire your puny barbarians (by proxy if you wish).

And yes, thanks to the Entity That Is, your objects got lazy and have their garbage collected. So their joy is only temporary because their life is immediate ended when they move out of scope. And not a single one of then can get away.

If you show fear to the Entity That Is, dead is only a destructor away. So be careful when you ride the waves of the workflow, because they are as unpredictable as the average market stock.

Your objects are never save for the Entity That Is. Persistance can back them up for a while but eventually all wil fail as the last clock cycle has rung. Fortunately thanks to persistance, your objects can be send to better places where they can multiply and live in peace.

The Entity That Is, is strict but fair, so if you use the propert command, your virtual doors to other realities wil open and allow swift and reliable trafic.

Good luck and honour the Entity That Is, you may not always agree with it, but its rule is the law and death the only penalty.

Answer 3

i think you're complaining about verb-centered designed when using SOA. If so, that is not a requirement of SOA, but it is a temptation.

"Anywhere in a normal OO application that you would do something, change that something to a web service" is probably overkill

the best uses for SOA that i've seen just replace the data access layer with an SOA layer, plus they expose a few high-level 'public' operations like registering a new user and so on

one could make a web service out of every class method, but this would be ridiculous in most cases...

Answer 4

It seems like the two ain't compatible when scaling. Amazon apparently lost plenty of time and money due to issues with versioning and their object models. SOA layers seem to work better if there is no dependant object definition leaving the consumer of the services to map EACH call to their own domain model..... hmm.....