The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

marc.divet@gmail.com (2) [Avatar] Offline
#1
Hy,

Great book! I have some trouble with the ch 8.4. If you want say a service directly Map whith en table representation on the DB is en wrong thing I'am agree whith you. BUT, if a service is name ‘person’ and the result of get or put (a1b2c3) is a document of all the information’s person, it’s SOA or old way? Personally I implement this on a large insurance company. This type of service in an entity service (for other author is a thin service) but I think for you is a coarse service. Coarse of course, because they are a lot of information. But it’s the more use and reuse service (it’s an attribute of thin service on another books). In fact we test deeply this architecture, and (because we make just 1 call) it’s more relevant than the RPC way (not for 1 call but it’s better after 2 call, ex. Person + adresses.

I think I am not use old way, what’s your opinion?
Regards,

PS sorry for my poor English, I’m French !
arnonrgo (62) [Avatar] Offline
#2
Re: Same Old Way antipattern
Hi Marc,

Thanks for the complement about the book smilie
It doesn't sound like what you're doing is "same old way". The point of that anti-patten is to say that that if you just put an SOA name on something which is essentially an n-tier architecture than it isn't really SOA. Same goes for artificially inserting a "service layer" without taking the steps to separate services anywhere besides that layer.

In any event, when designing architectures, getting to a SOA or a RESTful or whatever is not a goal in itself. we can and should use design ideas from whatever paradigm and get something that is both a good fit for our problem and a sustainable solution for moving forward.

Regards,
Arnon
marc.divet@gmail.com (2) [Avatar] Offline
#3
Re: Same Old Way antipattern
Hello,

In fact I was the lead architect of the refactoring the architecture on a major insurance company, in France. Your book would be helpful, but in fact, retrospectively I found all your pattern, the major contribution of your book is an organization and the description of the patterns!.

Meanwhile my major issue is about the scope, not an application but an entire information system. For that, we must categorize and organize an ontology of services. In the SOA’s book this point is to often reduce as thin and coarse grained services. It’s too weak. On the respect of “ Separation of concern” and “ don’t do spaghetti anymore” we produce an architecture without the possibility of circuit (only tree from the UI to the data).

And for that we are made a kind of layers (not based on old way …)

First layer is the entity services, and this services are not thin ! Strong documentation orientation (for the read and for the write)
On the second layer two kinds of services, the first kind of service is the rules services or all the operations doesn’t change the state of the SI. And the second one is the services who change the state of the SI (Transactional Service pattern!), the transactional service can call a rule service but a rule service can’t call a transactional service. Both of them use the entities services. In top of this structure we have the Use Case Services. The services consumers (UI, workflow, …) use only this type of service. In our architecture the type of service implements a lot of non-functional requirement (now I know the Security pattern smilie. This service is a bag for all the interaction involve of the use case (proper sizing of UC was a major concern of our work …)
And on top of that the Service consumer pattern of the ch6! AND a strong SOA governance.

And one more, your/this book as a pinpoint of the major issues on an SOA approach,

Regards,
Marc Divet.