Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #20694 > unrolled thread
| Started by | "SL@maxis" <noreply@my-rialto.com> |
|---|---|
| First post | 2012-12-25 01:04 +0800 |
| Last post | 2013-01-01 12:29 -0800 |
| Articles | 20 on this page of 76 — 14 participants |
Back to article view | Back to comp.lang.java.programmer
Java servlet on browsers: dying or kicking ? "SL@maxis" <noreply@my-rialto.com> - 2012-12-25 01:04 +0800
Re: Java servlet on browsers: dying or kicking ? Arne Vajhøj <arne@vajhoej.dk> - 2012-12-24 12:37 -0500
Re: Java servlet on browsers: dying or kicking ? "SL@maxis" <ecp_gen@my-rialto.com> - 2012-12-25 04:32 +0800
Re: Java servlet on browsers: dying or kicking ? Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2012-12-26 23:20 -0800
Re: Java servlet on browsers: dying or kicking ? Arne Vajhøj <arne@vajhoej.dk> - 2012-12-27 21:05 -0500
Re: Java servlet on browsers: dying or kicking ? Arne Vajhøj <arne@vajhoej.dk> - 2012-12-27 21:07 -0500
Re: Java servlet on browsers: dying or kicking ? Gene Wirchenko <genew@telus.net> - 2012-12-27 21:13 -0800
Re: Java servlet on browsers: dying or kicking ? Arne Vajhøj <arne@vajhoej.dk> - 2012-12-28 11:07 -0500
Re: Java servlet on browsers: dying or kicking ? Gene Wirchenko <genew@telus.net> - 2012-12-28 09:14 -0800
Re: Java servlet on browsers: dying or kicking ? Arne Vajhøj <arne@vajhoej.dk> - 2012-12-28 18:18 -0500
Re: Java servlet on browsers: dying or kicking ? Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2012-12-28 00:41 -0800
Re: Java servlet on browsers: dying or kicking ? Arne Vajhøj <arne@vajhoej.dk> - 2012-12-28 11:14 -0500
Re: Java servlet on browsers: dying or kicking ? lipska the kat <lipskathekat@yahoo.co.uk> - 2012-12-28 17:50 +0000
Re: Java servlet on browsers: dying or kicking ? Robert Klemme <shortcutter@googlemail.com> - 2012-12-28 21:22 +0100
Re: Java servlet on browsers: dying or kicking ? lipska the kat <lipskathekat@yahoo.co.uk> - 2012-12-28 21:08 +0000
Re: Java servlet on browsers: dying or kicking ? Robert Klemme <shortcutter@googlemail.com> - 2012-12-28 22:55 +0100
Re: Java servlet on browsers: dying or kicking ? Arne Vajhøj <arne@vajhoej.dk> - 2012-12-28 18:02 -0500
Re: Java servlet on browsers: dying or kicking ? lipska the kat <lipskathekat@yahoo.co.uk> - 2012-12-29 08:55 +0000
Re: Java servlet on browsers: dying or kicking ? Arne Vajhøj <arne@vajhoej.dk> - 2012-12-29 20:40 -0500
Re: Java servlet on browsers: dying or kicking ? Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-31 20:08 -0400
Re: Java servlet on browsers: dying or kicking ? Arne Vajhøj <arne@vajhoej.dk> - 2012-12-31 19:33 -0500
Re: Java servlet on browsers: dying or kicking ? Arne Vajhøj <arne@vajhoej.dk> - 2012-12-28 17:51 -0500
Re: Java servlet on browsers: dying or kicking ? lipska the kat <lipskathekat@yahoo.co.uk> - 2012-12-29 11:37 +0000
Re: Java servlet on browsers: dying or kicking ? lipska the kat <lipskathekat@yahoo.co.uk> - 2012-12-29 11:39 +0000
Re: Java servlet on browsers: dying or kicking ? Gene Wirchenko <genew@telus.net> - 2012-12-29 22:22 -0800
Re: Java servlet on browsers: dying or kicking ? Arne Vajhøj <arne@vajhoej.dk> - 2012-12-29 20:34 -0500
Re: Java servlet on browsers: dying or kicking ? Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-29 08:22 -0400
Re: Java servlet on browsers: dying or kicking ? lipska the kat <lipskathekat@yahoo.co.uk> - 2012-12-29 13:00 +0000
Re: Java servlet on browsers: dying or kicking ? Arne Vajhøj <arne@vajhoej.dk> - 2012-12-29 20:54 -0500
Re: Java servlet on browsers: dying or kicking ? lipska the kat <lipskathekat@yahoo.co.uk> - 2012-12-30 11:02 +0000
Re: Java servlet on browsers: dying or kicking ? Arne Vajhøj <arne@vajhoej.dk> - 2012-12-30 20:33 -0500
Re: Java servlet on browsers: dying or kicking ? Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-31 19:54 -0400
Re: Java servlet on browsers: dying or kicking ? Arne Vajhøj <arne@vajhoej.dk> - 2012-12-29 20:43 -0500
Re: Java servlet on browsers: dying or kicking ? Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-31 19:06 -0400
Re: Java servlet on browsers: dying or kicking ? Arne Vajhøj <arne@vajhoej.dk> - 2012-12-31 19:29 -0500
Re: Java servlet on browsers: dying or kicking ? Martin Gregorie <martin@address-in-sig.invalid> - 2013-01-01 01:46 +0000
Re: Java servlet on browsers: dying or kicking ? Arne Vajhøj <arne@vajhoej.dk> - 2012-12-31 21:35 -0500
Re: Java servlet on browsers: dying or kicking ? Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-01-01 09:22 -0400
Re: Java servlet on browsers: dying or kicking ? Arne Vajhøj <arne@vajhoej.dk> - 2013-01-04 19:46 -0500
Re: Java servlet on browsers: dying or kicking ? "Richard Maher" <maher_rj@hotspamnotmail.com> - 2013-01-05 08:22 +0800
Re: Java servlet on browsers: dying or kicking ? Arne Vajhøj <arne@vajhoej.dk> - 2013-01-04 19:59 -0500
Re: Java servlet on browsers: dying or kicking ? Arne Vajhøj <arne@vajhoej.dk> - 2013-01-04 20:01 -0500
Re: Java servlet on browsers: dying or kicking ? Martin Gregorie <martin@address-in-sig.invalid> - 2013-01-05 01:32 +0000
Re: Java servlet on browsers: dying or kicking ? lipska the kat <lipskathekat@yahoo.co.uk> - 2013-01-06 10:27 +0000
Re: Java servlet on browsers: dying or kicking ? Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-01-06 10:29 -0400
Re: Java servlet on browsers: dying or kicking ? lipska the kat <lipskathekat@yahoo.co.uk> - 2013-01-06 16:29 +0000
Re: Java servlet on browsers: dying or kicking ? Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-01-06 13:46 -0400
Re: Java servlet on browsers: dying or kicking ? lipska the kat <lipskathekat@yahoo.co.uk> - 2013-01-06 18:44 +0000
Re: Java servlet on browsers: dying or kicking ? Arne Vajhøj <arne@vajhoej.dk> - 2013-01-06 21:10 -0500
Re: Java servlet on browsers: dying or kicking ? lipska the kat <lipskathekat@yahoo.co.uk> - 2013-01-07 09:04 +0000
Re: Java servlet on browsers: dying or kicking ? Lew <lewbloch@gmail.com> - 2013-01-06 09:53 -0800
Re: Java servlet on browsers: dying or kicking ? lipska the kat <lipskathekat@yahoo.co.uk> - 2013-01-06 18:21 +0000
Re: Java servlet on browsers: dying or kicking ? Arne Vajhøj <arne@vajhoej.dk> - 2013-01-06 21:07 -0500
Re: Java servlet on browsers: dying or kicking ? Twirlip of the Mists <twirlip@killfile.me.now.invalid> - 2013-01-06 21:18 -0500
Re: Java servlet on browsers: dying or kicking ? Arne Vajhøj <arne@vajhoej.dk> - 2013-01-06 21:28 -0500
Re: Java servlet on browsers: dying or kicking ? Twirlip of the Mists <twirlip@killfile.me.now.invalid> - 2013-01-06 21:58 -0500
Re: Java servlet on browsers: dying or kicking ? Arne Vajhøj <arne@vajhoej.dk> - 2013-01-06 22:04 -0500
Re: Java servlet on browsers: dying or kicking ? Twirlip of the Mists <twirlip@killfile.me.now.invalid> - 2013-01-06 22:10 -0500
Re: Java servlet on browsers: dying or kicking ? lipska the kat <lipskathekat@yahoo.co.uk> - 2013-01-07 08:34 +0000
Re: Java servlet on browsers: dying or kicking ? lipska the kat <lipskathekat@yahoo.co.uk> - 2013-01-07 08:25 +0000
Re: Java servlet on browsers: dying or kicking ? Arne Vajhøj <arne@vajhoej.dk> - 2013-01-06 10:34 -0500
Re: Java servlet on browsers: dying or kicking ? lipska the kat <lipskathekat@yahoo.co.uk> - 2013-01-06 16:46 +0000
Re: Java servlet on browsers: dying or kicking ? Arne Vajhøj <arne@vajhoej.dk> - 2013-01-06 21:05 -0500
Re: Java servlet on browsers: dying or kicking ? lipska the kat <lipskathekat@yahoo.co.uk> - 2013-01-06 17:10 +0000
Re: Java servlet on browsers: dying or kicking ? Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-01-06 14:04 -0400
Re: Java servlet on browsers: dying or kicking ? Arne Vajhøj <arne@vajhoej.dk> - 2013-01-06 21:03 -0500
Re: Java servlet on browsers: dying or kicking ? Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-01-07 07:01 -0400
Re: Java servlet on browsers: dying or kicking ? lipska the kat <lipskathekat@yahoo.co.uk> - 2013-01-07 11:11 +0000
Re: Java servlet on browsers: dying or kicking ? lipska the kat <lipskathekat@yahoo.co.uk> - 2013-01-07 14:25 +0000
Re: Java servlet on browsers: dying or kicking ? "Richard Maher" <maher_rj@hotspamnotmail.com> - 2013-01-05 08:05 +0800
Re: Java servlet on browsers: dying or kicking ? Lew <lewbloch@gmail.com> - 2012-12-24 11:06 -0800
Re: Java servlet on browsers: dying or kicking ? Robert Klemme <shortcutter@googlemail.com> - 2012-12-24 23:33 +0100
Re: Java servlet on browsers: dying or kicking ? Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-12-24 18:15 -0500
Re: Java servlet on browsers: dying or kicking ? Robert Klemme <shortcutter@googlemail.com> - 2012-12-25 10:43 +0100
Re: Java servlet on browsers: dying or kicking ? Lew <lewbloch@gmail.com> - 2012-12-25 13:21 -0800
Re: Java servlet on browsers: dying or kicking ? Roedy Green <see_website@mindprod.com.invalid> - 2013-01-01 12:29 -0800
Page 2 of 4 — ← Prev page 1 [2] 3 4 Next page →
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2012-12-31 19:33 -0500 |
| Message-ID | <50e22ed0$0$293$14726298@news.sunsite.dk> |
| In reply to | #20838 |
On 12/31/2012 7:08 PM, Arved Sandstrom wrote: > On 12/28/2012 07:02 PM, Arne Vajhøj wrote: >> On 12/28/2012 4:08 PM, lipska the kat wrote: >>> On 28/12/12 20:22, Robert Klemme wrote: >>>> On 28.12.2012 18:50, lipska the kat wrote: >>>>> I spend much of my working life translating a clients business >>>>> processes >>>>> into something that can run on a computer and the trend is now more >>>>> than >>>>> ever away from a strictly web based process and towards systems that >>>>> are >>>>> completely independent of delivery mechanism. >>> >>>> This sounds exactly like the use case JEE was intended for. >>> >>> Well yes, I remember early days writing EJB deployment descriptors by >>> hand. What a hideous nightmare that was. >> >> They could be generate by IDE's. >> >> Or they could be generated by xdoclet. >> >> And they were not that hard to write manually. > [ SNIP ] > > Not _hard_, no, but quite tedious. Hence error-prone. I seem to recall > that back then (10+ years ago) I mostly used JBuilder - I have the vague > memory that it wasn't *that* much fun to do EJBs. :-) Maybe not fun, but you got paid to do it. Arne
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2012-12-28 17:51 -0500 |
| Message-ID | <50de2260$0$293$14726298@news.sunsite.dk> |
| In reply to | #20767 |
On 12/28/2012 12:50 PM, lipska the kat wrote: > What I inevitably end up with is a slightly less that perfect decoupling > but I like to think that eventually, given the appearance of a truly > scalable way to persist entire Object trees I will be able to produce a > business system that will be completely decoupled from earthly > considerations like UI and database I thought a business logic layer by definition was separate from UI layer and data access layer. :-) Arne
[toc] | [prev] | [next] | [standalone]
| From | lipska the kat <lipskathekat@yahoo.co.uk> |
|---|---|
| Date | 2012-12-29 11:37 +0000 |
| Message-ID | <wuadnQYLx9ydS0PNnZ2dnUVZ8nqdnZ2d@bt.com> |
| In reply to | #20782 |
On 28/12/12 22:51, Arne Vajhøj wrote: > On 12/28/2012 12:50 PM, lipska the kat wrote: >> What I inevitably end up with is a slightly less that perfect decoupling >> but I like to think that eventually, given the appearance of a truly >> scalable way to persist entire Object trees I will be able to produce a >> business system that will be completely decoupled from earthly >> considerations like UI and database > > I thought a business logic layer by definition was separate > from UI layer and data access layer. I have this vision of an implementation of a business that exists totally independently of any external influence ... it's just a thought. Anything can query the business ... "Do you have one of these and if so how much is it and do you have any in stock ?" or "I want to buy this, and I want to pay like this" and the business can communicate with it's suppliers in a similar way and the business can > > :-) > > Arne > > -- Lipska the Kat©: Troll hunter, sandbox destroyer and farscape dreamer of Aeryn Sun
[toc] | [prev] | [next] | [standalone]
| From | lipska the kat <lipskathekat@yahoo.co.uk> |
|---|---|
| Date | 2012-12-29 11:39 +0000 |
| Message-ID | <FJCdndCnLLruS0PNnZ2dnUVZ8l2dnZ2d@bt.com> |
| In reply to | #20793 |
On 29/12/12 11:37, lipska the kat wrote: > On 28/12/12 22:51, Arne Vajhøj wrote: >> On 12/28/2012 12:50 PM, lipska the kat wrote: Apologies, I hit the send key by mistake I blame the spouse for waving shortbread under my nose :-) lipska -- Lipska the Kat©: Troll hunter, sandbox destroyer and farscape dreamer of Aeryn Sun
[toc] | [prev] | [next] | [standalone]
| From | Gene Wirchenko <genew@telus.net> |
|---|---|
| Date | 2012-12-29 22:22 -0800 |
| Message-ID | <3bnvd8ttokfjrju48gtqjv5vfmcbrqct6l@4ax.com> |
| In reply to | #20794 |
On Sat, 29 Dec 2012 11:39:31 +0000, lipska the kat
<lipskathekat@yahoo.co.uk> wrote:
>On 29/12/12 11:37, lipska the kat wrote:
>> On 28/12/12 22:51, Arne Vajhøj wrote:
>>> On 12/28/2012 12:50 PM, lipska the kat wrote:
>
>Apologies, I hit the send key by mistake
>I blame the spouse for waving shortbread under my nose :-)
Truly a horrible threat to good USENETting.
I love shortbread, too.
Sincerely,
Gene Wirchenko
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2012-12-29 20:34 -0500 |
| Message-ID | <50df9a2c$0$284$14726298@news.sunsite.dk> |
| In reply to | #20793 |
On 12/29/2012 6:37 AM, lipska the kat wrote: > On 28/12/12 22:51, Arne Vajhøj wrote: >> On 12/28/2012 12:50 PM, lipska the kat wrote: >>> What I inevitably end up with is a slightly less that perfect decoupling >>> but I like to think that eventually, given the appearance of a truly >>> scalable way to persist entire Object trees I will be able to produce a >>> business system that will be completely decoupled from earthly >>> considerations like UI and database >> >> I thought a business logic layer by definition was separate >> from UI layer and data access layer. > > I have this vision of an implementation of a business that exists > totally independently of any external influence ... it's just a thought. > > Anything can query the business ... "Do you have one of these and if so > how much is it and do you have any in stock ?" > > or "I want to buy this, and I want to pay like this" > > and the business can communicate with it's suppliers in a similar way > > and the business can I think you are looking for something loosely coupled - there will always be a dependency on something behind it. Arne
[toc] | [prev] | [next] | [standalone]
| From | Arved Sandstrom <asandstrom2@eastlink.ca> |
|---|---|
| Date | 2012-12-29 08:22 -0400 |
| Message-ID | <JfBDs.90567$2v.68591@newsfe05.iad> |
| In reply to | #20782 |
On 12/28/2012 06:51 PM, Arne Vajhøj wrote: > On 12/28/2012 12:50 PM, lipska the kat wrote: >> What I inevitably end up with is a slightly less that perfect decoupling >> but I like to think that eventually, given the appearance of a truly >> scalable way to persist entire Object trees I will be able to produce a >> business system that will be completely decoupled from earthly >> considerations like UI and database > > I thought a business logic layer by definition was separate > from UI layer and data access layer. > > :-) > > Arne > I do such a heavy combination of SOA and web app work that I like layers that work for both. For my purposes Martin Fowler's Service/Application layer picture (http://martinfowler.com/eaaCatalog/serviceLayer.html) serves nicely as a starting point. In that picture business logic is mostly in the Domain/Model layer, including business rules, and the Service/Application layer consists of operations that cannot be assigned to any one given domain object. I see a good, solid Service/Application layer as being one that actually provides services in the SOA sense. Not web services, but _services_. These then become available for orchestration in different ways. In a web app scenario, and I stress that this is *my* approach, the MVC Model is generally the Fowlerian Service layer (plus everything inside it) + extra stuff that is perhaps best characterized as a view-model. Equally well you can provide a web service endpoint thin layer - basically just the stuff to provide REST or SOAP access to consumers - that exposes the Service Layer. Anything can stitch together (orchestrate) the service layer operations available through either mechanism. I emphatically don't delineate layers by technology used, or even by location. A clean, understandable architectural picture can deal with, and explain, business logic in Javascript on a mobile browser, and also business logic in a DB stored procedure. AHS
[toc] | [prev] | [next] | [standalone]
| From | lipska the kat <lipskathekat@yahoo.co.uk> |
|---|---|
| Date | 2012-12-29 13:00 +0000 |
| Message-ID | <idGdnWAQLIUadEPNnZ2dnUVZ7sudnZ2d@bt.com> |
| In reply to | #20797 |
On 29/12/12 12:22, Arved Sandstrom wrote: > On 12/28/2012 06:51 PM, Arne Vajhøj wrote: >> On 12/28/2012 12:50 PM, lipska the kat wrote: >>> What I inevitably end up with is a slightly less that perfect decoupling >>> but I like to think that eventually, given the appearance of a truly >>> scalable way to persist entire Object trees I will be able to produce a >>> business system that will be completely decoupled from earthly >>> considerations like UI and database >> >> I thought a business logic layer by definition was separate >> from UI layer and data access layer. >> >> :-) >> >> Arne >> > I do such a heavy combination of SOA and web app work that I like layers > that work for both. For my purposes Martin Fowler's Service/Application > layer picture (http://martinfowler.com/eaaCatalog/serviceLayer.html) > serves nicely as a starting point. > > In that picture business logic is mostly in the Domain/Model layer, > including business rules, and the Service/Application layer consists of > operations that cannot be assigned to any one given domain object. > > I see a good, solid Service/Application layer as being one that actually > provides services in the SOA sense. Not web services, but _services_. > These then become available for orchestration in different ways. I see the _service layer_ as aggregating fine grained business methods behind a facade. The facade then exposes what are in effect 'atomic' services that implement a particular subset of the business as seen by the outside world. As far as external clients are concerned the interface to the business is clearly defined. Martin Fowler says "[The] Service Layer defines an application's boundary" My question is how can the orchestration of service layer services outside the system boundary be controlled in a way that would be guaranteed not to potentially break the [business] rules ? [snip] lipska -- Lipska the Kat©: Troll hunter, sandbox destroyer and farscape dreamer of Aeryn Sun
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2012-12-29 20:54 -0500 |
| Message-ID | <50df9ef7$0$284$14726298@news.sunsite.dk> |
| In reply to | #20800 |
On 12/29/2012 8:00 AM, lipska the kat wrote: > I see the _service layer_ as aggregating fine grained business methods > behind a facade. The facade then exposes what are in effect 'atomic' > services that implement a particular subset of the business as seen by > the outside world. As far as external clients are concerned the > interface to the business is clearly defined. Facade pattern > My question is how can the orchestration of service layer services > outside the system boundary be controlled in a way that would be > guaranteed not to potentially break the [business] rules ? You need to have context. Either have client send all context or send a ref to context saved in service layer. Arne
[toc] | [prev] | [next] | [standalone]
| From | lipska the kat <lipskathekat@yahoo.co.uk> |
|---|---|
| Date | 2012-12-30 11:02 +0000 |
| Message-ID | <jOqdnTE_e8PGgn3NnZ2dnUVZ8uydnZ2d@bt.com> |
| In reply to | #20811 |
On 30/12/12 01:54, Arne Vajhøj wrote: > On 12/29/2012 8:00 AM, lipska the kat wrote: >> I see the _service layer_ as aggregating fine grained business methods >> behind a facade. The facade then exposes what are in effect 'atomic' >> services that implement a particular subset of the business as seen by >> the outside world. As far as external clients are concerned the >> interface to the business is clearly defined. > > Facade pattern Your point being ? >> My question is how can the orchestration of service layer services >> outside the system boundary be controlled in a way that would be >> guaranteed not to potentially break the [business] rules ? > > You need to have context. Either have client send all > context or send a ref to context saved in service layer. Unconvinced I'm afraid There are two possible types of actor interaction with a business Stateless and statefull. A stateless interaction for example might be a request for currency conversion, or a free ESTIMATE for goods or services. You may offer these alongside other free services, Clients can mix and match your stateless services all they want and it has no impact on your business. The other type is statefull. These interactions do impact the state of your business, In 20 odd years of designing and implementing business systems I have never come across a situation where a business is happy to allow it's clients to dictate the terms of business in a random and uncontrollable way. Any control exercised over the combination of statefull services effectively extends the system boundary so the whole argument (allowing external orchestration of services) becomes moot. This is not some academic conjecture on my part but hard experience in the real world. I'd be interested to hear what the original responder has to say about this. lipska -- Lipska the Kat©: Troll hunter, sandbox destroyer and farscape dreamer of Aeryn Sun
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2012-12-30 20:33 -0500 |
| Message-ID | <50e0eb51$0$283$14726298@news.sunsite.dk> |
| In reply to | #20814 |
On 12/30/2012 6:02 AM, lipska the kat wrote: > On 30/12/12 01:54, Arne Vajhøj wrote: >> On 12/29/2012 8:00 AM, lipska the kat wrote: >>> I see the _service layer_ as aggregating fine grained business methods >>> behind a facade. The facade then exposes what are in effect 'atomic' >>> services that implement a particular subset of the business as seen by >>> the outside world. As far as external clients are concerned the >>> interface to the business is clearly defined. >> >> Facade pattern > > Your point being ? That this is one of the most widely used patterns. >>> My question is how can the orchestration of service layer services >>> outside the system boundary be controlled in a way that would be >>> guaranteed not to potentially break the [business] rules ? >> >> You need to have context. Either have client send all >> context or send a ref to context saved in service layer. > > Unconvinced I'm afraid > > There are two possible types of actor interaction with a business > Stateless and statefull. > > A stateless interaction for example might be a request for currency > conversion, or a free ESTIMATE for goods or services. You may offer > these alongside other free services, Clients can mix and match your > stateless services all they want and it has no impact on your business. > > The other type is statefull. These interactions do impact the state of > your business, In 20 odd years of designing and implementing business > systems I have never come across a situation where a business is happy > to allow it's clients to dictate the terms of business in a random and > uncontrollable way. Any control exercised over the combination of > statefull services effectively extends the system boundary so the whole > argument (allowing external orchestration of services) becomes moot. > > This is not some academic conjecture on my part but hard experience in > the real world. > > I'd be interested to hear what the original responder has to say about > this. You can't orchestrate on your server without context. Arne
[toc] | [prev] | [next] | [standalone]
| From | Arved Sandstrom <asandstrom2@eastlink.ca> |
|---|---|
| Date | 2012-12-31 19:54 -0400 |
| Message-ID | <5BpEs.20481$tK1.2200@newsfe07.iad> |
| In reply to | #20814 |
On 12/30/2012 07:02 AM, lipska the kat wrote: > On 30/12/12 01:54, Arne Vajhøj wrote: >> On 12/29/2012 8:00 AM, lipska the kat wrote: >>> I see the _service layer_ as aggregating fine grained business methods >>> behind a facade. The facade then exposes what are in effect 'atomic' >>> services that implement a particular subset of the business as seen by >>> the outside world. As far as external clients are concerned the >>> interface to the business is clearly defined. >> >> Facade pattern > > Your point being ? > >>> My question is how can the orchestration of service layer services >>> outside the system boundary be controlled in a way that would be >>> guaranteed not to potentially break the [business] rules ? >> >> You need to have context. Either have client send all >> context or send a ref to context saved in service layer. > > Unconvinced I'm afraid > > There are two possible types of actor interaction with a business > Stateless and statefull. > > A stateless interaction for example might be a request for currency > conversion, or a free ESTIMATE for goods or services. You may offer > these alongside other free services, Clients can mix and match your > stateless services all they want and it has no impact on your business. > > The other type is statefull. These interactions do impact the state of > your business, In 20 odd years of designing and implementing business > systems I have never come across a situation where a business is happy > to allow it's clients to dictate the terms of business in a random and > uncontrollable way. Any control exercised over the combination of > statefull services effectively extends the system boundary so the whole > argument (allowing external orchestration of services) becomes moot. > > This is not some academic conjecture on my part but hard experience in > the real world. > > I'd be interested to hear what the original responder has to say about > this. > > lipska > How to classify orchestration - what layer to put it in, in whatever architectural model you've selected - or whether even to use the term "orchestration" (and by implication to define an orchestration layer), really needs to be established up front. I like using Fowler's model because it's pretty neat, and it's reasonably applicable to both SOA and non-SOA. Without getting religious about it, if I were to assign orchestration a place in Fowler's diagram, I'd have to amend slightly what I said in my previous email in this sub-thread, and consider that the process services that make up the orchestration layer are also in the Service/Application layer. To put it another way, if you have true services being made available (and I actually agree with your description of them as "'atomic' services that implement a particular subset of the business"), then the "stitching together" of them that I alluded to is also in the Service/Application layer. The lower-level more granular services are solution-agnostic; the process services are particular to a given solution. So to touch on your observation, yes, the system boundary (the application boundary) includes the business logic embodied in process services (workflow etc). One other comment - I myself probably wouldn't much use the terms "stateless" and "stateful" at all in this particular discussion. If you did have a process that combined a number of services, the odds are pretty good that each individual service would be stateless, that the process itself would have interaction state, and it would be completely another issue as to whether this process eventually effected any changes in business data (state) or not. AHS
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2012-12-29 20:43 -0500 |
| Message-ID | <50df9c4b$0$284$14726298@news.sunsite.dk> |
| In reply to | #20797 |
On 12/29/2012 7:22 AM, Arved Sandstrom wrote: > On 12/28/2012 06:51 PM, Arne Vajhøj wrote: >> On 12/28/2012 12:50 PM, lipska the kat wrote: >>> What I inevitably end up with is a slightly less that perfect decoupling >>> but I like to think that eventually, given the appearance of a truly >>> scalable way to persist entire Object trees I will be able to produce a >>> business system that will be completely decoupled from earthly >>> considerations like UI and database >> >> I thought a business logic layer by definition was separate >> from UI layer and data access layer. > I do such a heavy combination of SOA and web app work that I like layers > that work for both. For my purposes Martin Fowler's Service/Application > layer picture (http://martinfowler.com/eaaCatalog/serviceLayer.html) > serves nicely as a starting point. > > In that picture business logic is mostly in the Domain/Model layer, > including business rules, and the Service/Application layer consists of > operations that cannot be assigned to any one given domain object. > > I see a good, solid Service/Application layer as being one that actually > provides services in the SOA sense. Not web services, but _services_. > These then become available for orchestration in different ways. The 3 layer model with PL, BLL and DAL are very widely used, but other models are certainly possible. A DL and AL makes perfectly sense to me. But DL and AL will still be separate from PL and DAL just like BLL. > In a web app scenario, and I stress that this is *my* approach, the MVC > Model is generally the Fowlerian Service layer (plus everything inside > it) + extra stuff that is perhaps best characterized as a view-model. That is how I see M as well. > I emphatically don't delineate layers by technology used, or even by > location. A clean, understandable architectural picture can deal with, > and explain, business logic in Javascript on a mobile browser, and also > business logic in a DB stored procedure. Business logic can be put in all tiers. But it may not be equally good design. Arne
[toc] | [prev] | [next] | [standalone]
| From | Arved Sandstrom <asandstrom2@eastlink.ca> |
|---|---|
| Date | 2012-12-31 19:06 -0400 |
| Message-ID | <nUoEs.1$Z03.0@newsfe23.iad> |
| In reply to | #20809 |
On 12/29/2012 09:43 PM, Arne Vajhøj wrote: > On 12/29/2012 7:22 AM, Arved Sandstrom wrote: [ SNIP ] >> I emphatically don't delineate layers by technology used, or even by >> location. A clean, understandable architectural picture can deal with, >> and explain, business logic in Javascript on a mobile browser, and also >> business logic in a DB stored procedure. > > Business logic can be put in all tiers. > > But it may not be equally good design. > > Arne There are several schools of terminology here, Arne. I hold to the school that says that a "tier" is a physical division in a system (hardware/software) architecture, while a "layer" is a logical division in a software architecture. So that's why I said what I said the way I said it, using the words "layers", "technology" and "location" on purpose. I think that as long as your business logic is identifiably in a location where it should be, then you have a sound solution (all other things being equal). In any case we commonly have business logic in the data tier. A subset of business logic is business rules, and one category of business rules is data constraints. And data constraints, as you know, are very often imposed directly in an RDBMS or managed indirectly through JPA or its .NET equivalents, to use just a few examples. Since we - software developers in general - routinely do the above, I see no reason to demonize business logic in stored procedures either. In fact, given the efficiency of a modern RDBMS in handling DML it is frequently the most sensible place to put certain kinds of business logic. To be honest I've been uncomfortable for a long time with the label and concept of a "business logic" layer, as opposed to say DALs or Presentation layers. For example, workflow is a component of business logic - in order to adhere to orthodoxy you have to then maintain that every aspect of workflow in web apps, SOA orchestrations or mobile client apps is still business logic. Which probably it is - in which case why is Javascript business logic a bad thing? I've worked in a bunch of shops where to utter Javascript and "business logic" in the same sentence occasions gasps of horror. :-) And yet many of these same people have methods, that are directly exposed through JSF web pages, also doing business logic. I'm not indicating strongly here what I advocate and what I don't, I'm just saying that business logic permeates every tier we have, so maybe the concept of a "business logic" layer needs some thought. I think at a minimum a developer needs to understand what business logic is - rules and workflow - and needs to adequately manage where it is. I think it's less important what tier it's in. AHS
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2012-12-31 19:29 -0500 |
| Message-ID | <50e22df7$0$293$14726298@news.sunsite.dk> |
| In reply to | #20836 |
On 12/31/2012 6:06 PM, Arved Sandstrom wrote: > On 12/29/2012 09:43 PM, Arne Vajhøj wrote: >> On 12/29/2012 7:22 AM, Arved Sandstrom wrote: > [ SNIP ] > >>> I emphatically don't delineate layers by technology used, or even by >>> location. A clean, understandable architectural picture can deal with, >>> and explain, business logic in Javascript on a mobile browser, and also >>> business logic in a DB stored procedure. >> >> Business logic can be put in all tiers. >> >> But it may not be equally good design. > > There are several schools of terminology here, Arne. I hold to the > school that says that a "tier" is a physical division in a system > (hardware/software) architecture, while a "layer" is a logical division > in a software architecture. That is the definitions of tier and layer I prefer as well. > So that's why I said what I said the way I said it, using the words > "layers", "technology" and "location" on purpose. I think that as long > as your business logic is identifiably in a location where it should be, > then you have a sound solution (all other things being equal). > > In any case we commonly have business logic in the data tier. A subset > of business logic is business rules, and one category of business rules > is data constraints. And data constraints, as you know, are very often > imposed directly in an RDBMS or managed indirectly through JPA or its > .NET equivalents, to use just a few examples. > > Since we - software developers in general - routinely do the above, I > see no reason to demonize business logic in stored procedures either. In > fact, given the efficiency of a modern RDBMS in handling DML it is > frequently the most sensible place to put certain kinds of business logic. SP's are certainly a valid option for business logic. The biggest drawback is the vendor lock-in (unless it is an open source database, which the SP based solutions rarely are - it is almost always Oracle/Microsoft/Sybase). > To be honest I've been uncomfortable for a long time with the label and > concept of a "business logic" layer, as opposed to say DALs or > Presentation layers. For example, workflow is a component of business > logic - in order to adhere to orthodoxy you have to then maintain that > every aspect of workflow in web apps, SOA orchestrations or mobile > client apps is still business logic. > > Which probably it is - in which case why is Javascript business logic a > bad thing? I've worked in a bunch of shops where to utter Javascript and > "business logic" in the same sentence occasions gasps of horror. :-) And > yet many of these same people have methods, that are directly exposed > through JSF web pages, also doing business logic. I'm not indicating > strongly here what I advocate and what I don't, I'm just saying that > business logic permeates every tier we have, so maybe the concept of a > "business logic" layer needs some thought. We need to distinguish between client tier vs app server tier and JavaScript vs other language like Java. Code running in client tier is cooperative not enforcing in nature. I see that as a major problem for business logic in many contexts. It applies equaly to AJAX JavaScript, Java applets, Flash, SilverLight etc.. JavaScript is a different language than Java. I am not convinced that it is a good language for business logic. But other may have different opinions. I will not though that the existence of new languages like Dart and TypeScript shows that I am not the only one with such concerns. That applies equally to client side JavaScript and server side JavaScript (node.js). > I think at a minimum a developer needs to understand what business logic > is - rules and workflow - and needs to adequately manage where it is. I > think it's less important what tier it's in. I don't agree. What tier the business logic is locate in can have huge architectural impact. Arne
[toc] | [prev] | [next] | [standalone]
| From | Martin Gregorie <martin@address-in-sig.invalid> |
|---|---|
| Date | 2013-01-01 01:46 +0000 |
| Message-ID | <kbtf59$4cv$1@localhost.localdomain> |
| In reply to | #20840 |
On Mon, 31 Dec 2012 19:29:41 -0500, Arne Vajhøj wrote: > > The biggest drawback is the vendor lock-in (unless it is an open source > database, which the SP based solutions rarely are - it is almost always > Oracle/Microsoft/Sybase). > I was following, and agreeing with you, until this point. However now I don't understand why you make the OSS vs proprietary distinction. IMO moving a schema and data between PostgreSQL and MySQL would be no easier than moving between Oracle and Sybase. I don't see much inherent difference in stability within a DBMS either: granted that PostgreSQL specs change relatively little between versions, but the underlying low- level structure changes are often big enough to require the DB to be unloaded from the old version and reloaded into the new one. How is this different from, say, Oracle upgrades? Worse, some OSS stuff has insufficient attention paid to feature migration across versions. Leaving aside my bete noir (the egregious 'who cares what the user wants: this is what WE want' attitude shown by the Gnome team), I've bitten twice by the failure of PostgreSQL's pgdumpall utility to prevent confusion between valid data and string delimiters (delimiter characters, which are chosen by pgdumpall, appearing in data and not being recoded as hex to prevent confusion). I bugged it once, got it fixed, and then bugger me, it reappeared two versions later. I expect bugs of this type to get added to regression tests and hence to never reappear. If I can do this, so can any OSS project. The nub of the problem is that, at least with commercial code you generally get notice taken and the bug fixed or documented as a feature but sadly, there are OSS projects out there that just blow you off if their ideas have changed and/or they can't be arsed to do proper regression testing (WINE, I'm looking at you!). -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2012-12-31 21:35 -0500 |
| Message-ID | <50e24b62$0$283$14726298@news.sunsite.dk> |
| In reply to | #20842 |
On 12/31/2012 8:46 PM, Martin Gregorie wrote: > On Mon, 31 Dec 2012 19:29:41 -0500, Arne Vajhøj wrote: >> The biggest drawback is the vendor lock-in (unless it is an open source >> database, which the SP based solutions rarely are - it is almost always >> Oracle/Microsoft/Sybase). >> > I was following, and agreeing with you, until this point. However now I > don't understand why you make the OSS vs proprietary distinction. > > IMO moving a schema and data between PostgreSQL and MySQL would be no > easier than moving between Oracle and Sybase. I don't see much inherent > difference in stability within a DBMS either: granted that PostgreSQL > specs change relatively little between versions, but the underlying low- > level structure changes are often big enough to require the DB to be > unloaded from the old version and reloaded into the new one. How is this > different from, say, Oracle upgrades? > > Worse, some OSS stuff has insufficient attention paid to feature > migration across versions. Leaving aside my bete noir (the egregious 'who > cares what the user wants: this is what WE want' attitude shown by the > Gnome team), I've bitten twice by the failure of PostgreSQL's pgdumpall > utility to prevent confusion between valid data and string delimiters > (delimiter characters, which are chosen by pgdumpall, appearing in data > and not being recoded as hex to prevent confusion). I bugged it once, > got it fixed, and then bugger me, it reappeared two versions later. I > expect bugs of this type to get added to regression tests and hence to > never reappear. If I can do this, so can any OSS project. > > The nub of the problem is that, at least with commercial code you > generally get notice taken and the bug fixed or documented as a feature > but sadly, there are OSS projects out there that just blow you off if > their ideas have changed and/or they can't be arsed to do proper > regression testing (WINE, I'm looking at you!). You are also tied to an open source database, but you are not tied to the vendor. That can make a difference. If you want to get rid of PostgreSQL, then you will have some cost migrating - just like you will have some cost migrating from Oracle. But if Oracle raises their license costs, then you either have to pay them or pay for the migration. With PostgreSQL you do not have that issue. You can always get the same product from somewhere else. If Sybase decides to drop ASE, then you have to pay for a migration. If PostgreSQL team drops it, then somebody else can take over. If you depend on an open source database working, then you should pay for support to get your bugs fixed ASAP. The most common open source databases have companies specializing in support of them. Arne
[toc] | [prev] | [next] | [standalone]
| From | Arved Sandstrom <asandstrom2@eastlink.ca> |
|---|---|
| Date | 2013-01-01 09:22 -0400 |
| Message-ID | <JqBEs.27995$411.18293@newsfe02.iad> |
| In reply to | #20840 |
On 12/31/2012 08:29 PM, Arne Vajhøj wrote: > On 12/31/2012 6:06 PM, Arved Sandstrom wrote: >> On 12/29/2012 09:43 PM, Arne Vajhøj wrote: >>> On 12/29/2012 7:22 AM, Arved Sandstrom wrote: >> [ SNIP ] >> >>>> I emphatically don't delineate layers by technology used, or even by >>>> location. A clean, understandable architectural picture can deal with, >>>> and explain, business logic in Javascript on a mobile browser, and also >>>> business logic in a DB stored procedure. >>> >>> Business logic can be put in all tiers. >>> >>> But it may not be equally good design. >> >> There are several schools of terminology here, Arne. I hold to the >> school that says that a "tier" is a physical division in a system >> (hardware/software) architecture, while a "layer" is a logical division >> in a software architecture. > > That is the definitions of tier and layer I prefer as well. > >> So that's why I said what I said the way I said it, using the words >> "layers", "technology" and "location" on purpose. I think that as long >> as your business logic is identifiably in a location where it should be, >> then you have a sound solution (all other things being equal). >> >> In any case we commonly have business logic in the data tier. A subset >> of business logic is business rules, and one category of business rules >> is data constraints. And data constraints, as you know, are very often >> imposed directly in an RDBMS or managed indirectly through JPA or its >> .NET equivalents, to use just a few examples. >> >> Since we - software developers in general - routinely do the above, I >> see no reason to demonize business logic in stored procedures either. In >> fact, given the efficiency of a modern RDBMS in handling DML it is >> frequently the most sensible place to put certain kinds of business >> logic. > > SP's are certainly a valid option for business logic. > > The biggest drawback is the vendor lock-in (unless it is an > open source database, which the SP based solutions rarely are - it > is almost always Oracle/Microsoft/Sybase). And that's one of the few disadvantages. The big advantage (shared with views) is centralization of data access logic - rather than having every client doing the same D.A. manipulations, you've got complex stuff bundled in one place. This also eases the security problem. On the subject of vendor lock-in, I'm not that worried about it. No matter what software you pick, whether proprietary and $$$, or gratis and open source, once you've invested some application effort into a given product then you have a degree of lock-in. And in my experience substantial underlying systems just aren't swapped out that frequently. >> To be honest I've been uncomfortable for a long time with the label and >> concept of a "business logic" layer, as opposed to say DALs or >> Presentation layers. For example, workflow is a component of business >> logic - in order to adhere to orthodoxy you have to then maintain that >> every aspect of workflow in web apps, SOA orchestrations or mobile >> client apps is still business logic. >> >> Which probably it is - in which case why is Javascript business logic a >> bad thing? I've worked in a bunch of shops where to utter Javascript and >> "business logic" in the same sentence occasions gasps of horror. :-) And >> yet many of these same people have methods, that are directly exposed >> through JSF web pages, also doing business logic. I'm not indicating >> strongly here what I advocate and what I don't, I'm just saying that >> business logic permeates every tier we have, so maybe the concept of a >> "business logic" layer needs some thought. > > We need to distinguish between client tier vs app server tier and > JavaScript vs other language like Java. > > Code running in client tier is cooperative not enforcing in nature. > I see that as a major problem for business logic in many contexts. Maybe I'm obtuse, because I don't see the problem. In fact I haven't wrapped my head around the "cooperative" and "enforcing" labels either. Let's assume a relatively thick client, so that there's some application logic to speak of on the client. That client logic could be as complete as being UI + process logic + a subset of domain logic + an embedded DB for independent operations, or it could be pretty spare and only have some UI and a bit of process logic. Either way, when it communicates across the physical (tier) divide with the server, it's an _internal_ detail. If you've got a proper internal API to handle that physical boundary then what's the problem exactly? > It applies equaly to AJAX JavaScript, Java applets, Flash, > SilverLight etc.. > > JavaScript is a different language than Java. I am not convinced > that it is a good language for business logic. But other may have > different opinions. I will not though that the existence of > new languages like Dart and TypeScript shows that I am not the > only one with such concerns. > > That applies equally to client side JavaScript and server side > JavaScript (node.js). > >> I think at a minimum a developer needs to understand what business logic >> is - rules and workflow - and needs to adequately manage where it is. I >> think it's less important what tier it's in. > > I don't agree. > > What tier the business logic is locate in can have huge architectural > impact. > > Arne If we're talking tiers and not layers, and let's say we think of the client, middleware/server, and database/data access tiers, I am hoping that the decisions to locate business logic in any of those tiers leads to positive architectural impact - otherwise why are you locating logic there? There are known advantages to certain types of logic in any of those 3 tiers. There are also known disadvantages. If the advantages outweigh the disadvantages then why not put the logic where reason argues that it should go? Pure technical arguments aside for why a particular type of logic should be in the client tier, or middle tier, or in the data tier, some of the main things I also look at are maintenance impact and future development flexibility. Are there readily available human resources, now and in future, that can do new work or maintain old work in all the places that business logic has been put, or are you creating operational and maintenance difficulties? Is there a consistent and clear and well-disseminated policy for why certain logic goes where it does? Is it less maintenance effort to take care of certain types of data access logic in the data tier than it would be if it was in the middle tier? It often is. I think what has the most negative, anarchic impact when it comes to where business logic goes is simply lack of detailed thought and communication. AHS
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2013-01-04 19:46 -0500 |
| Message-ID | <50e777de$0$295$14726298@news.sunsite.dk> |
| In reply to | #20852 |
On 1/1/2013 8:22 AM, Arved Sandstrom wrote: > On 12/31/2012 08:29 PM, Arne Vajhøj wrote: >> On 12/31/2012 6:06 PM, Arved Sandstrom wrote: >>> On 12/29/2012 09:43 PM, Arne Vajhøj wrote: >>>> On 12/29/2012 7:22 AM, Arved Sandstrom wrote: >>> [ SNIP ] >>> >>>>> I emphatically don't delineate layers by technology used, or even by >>>>> location. A clean, understandable architectural picture can deal with, >>>>> and explain, business logic in Javascript on a mobile browser, and >>>>> also >>>>> business logic in a DB stored procedure. >>>> >>>> Business logic can be put in all tiers. >>>> >>>> But it may not be equally good design. >>> >>> There are several schools of terminology here, Arne. I hold to the >>> school that says that a "tier" is a physical division in a system >>> (hardware/software) architecture, while a "layer" is a logical division >>> in a software architecture. >> >> That is the definitions of tier and layer I prefer as well. >> >>> So that's why I said what I said the way I said it, using the words >>> "layers", "technology" and "location" on purpose. I think that as long >>> as your business logic is identifiably in a location where it should be, >>> then you have a sound solution (all other things being equal). >>> >>> In any case we commonly have business logic in the data tier. A subset >>> of business logic is business rules, and one category of business rules >>> is data constraints. And data constraints, as you know, are very often >>> imposed directly in an RDBMS or managed indirectly through JPA or its >>> .NET equivalents, to use just a few examples. >>> >>> Since we - software developers in general - routinely do the above, I >>> see no reason to demonize business logic in stored procedures either. In >>> fact, given the efficiency of a modern RDBMS in handling DML it is >>> frequently the most sensible place to put certain kinds of business >>> logic. >> >> SP's are certainly a valid option for business logic. >> >> The biggest drawback is the vendor lock-in (unless it is an >> open source database, which the SP based solutions rarely are - it >> is almost always Oracle/Microsoft/Sybase). > > And that's one of the few disadvantages. The big advantage (shared with > views) is centralization of data access logic - rather than having every > client doing the same D.A. manipulations, you've got complex stuff > bundled in one place. > > This also eases the security problem. > > On the subject of vendor lock-in, I'm not that worried about it. No > matter what software you pick, whether proprietary and $$$, or gratis > and open source, once you've invested some application effort into a > given product then you have a degree of lock-in. And in my experience > substantial underlying systems just aren't swapped out that frequently. > >>> To be honest I've been uncomfortable for a long time with the label and >>> concept of a "business logic" layer, as opposed to say DALs or >>> Presentation layers. For example, workflow is a component of business >>> logic - in order to adhere to orthodoxy you have to then maintain that >>> every aspect of workflow in web apps, SOA orchestrations or mobile >>> client apps is still business logic. >>> >>> Which probably it is - in which case why is Javascript business logic a >>> bad thing? I've worked in a bunch of shops where to utter Javascript and >>> "business logic" in the same sentence occasions gasps of horror. :-) And >>> yet many of these same people have methods, that are directly exposed >>> through JSF web pages, also doing business logic. I'm not indicating >>> strongly here what I advocate and what I don't, I'm just saying that >>> business logic permeates every tier we have, so maybe the concept of a >>> "business logic" layer needs some thought. >> >> We need to distinguish between client tier vs app server tier and >> JavaScript vs other language like Java. >> >> Code running in client tier is cooperative not enforcing in nature. >> I see that as a major problem for business logic in many contexts. > > Maybe I'm obtuse, because I don't see the problem. In fact I haven't > wrapped my head around the "cooperative" and "enforcing" labels either. > Let's assume a relatively thick client, so that there's some application > logic to speak of on the client. That client logic could be as complete > as being UI + process logic + a subset of domain logic + an embedded DB > for independent operations, or it could be pretty spare and only have > some UI and a bit of process logic. Either way, when it communicates > across the physical (tier) divide with the server, it's an _internal_ > detail. If you've got a proper internal API to handle that physical > boundary then what's the problem exactly? > >> It applies equaly to AJAX JavaScript, Java applets, Flash, >> SilverLight etc.. >> >> JavaScript is a different language than Java. I am not convinced >> that it is a good language for business logic. But other may have >> different opinions. I will not though that the existence of >> new languages like Dart and TypeScript shows that I am not the >> only one with such concerns. >> >> That applies equally to client side JavaScript and server side >> JavaScript (node.js). >> >>> I think at a minimum a developer needs to understand what business logic >>> is - rules and workflow - and needs to adequately manage where it is. I >>> think it's less important what tier it's in. >> >> I don't agree. >> >> What tier the business logic is locate in can have huge architectural >> impact. > > If we're talking tiers and not layers, and let's say we think of the > client, middleware/server, and database/data access tiers, I am hoping > that the decisions to locate business logic in any of those tiers leads > to positive architectural impact - otherwise why are you locating logic > there? Yes. My point is that where is important or at least can be important. > There are known advantages to certain types of logic in any of those 3 > tiers. There are also known disadvantages. If the advantages outweigh > the disadvantages then why not put the logic where reason argues that it > should go? I agree. But I was giving specific reasons why a specific type of logic should not be in a specific tier. > I think what has the most negative, anarchic impact when it comes to > where business logic goes is simply lack of detailed thought and > communication. Again very true. But it does not really change anything. Arne
[toc] | [prev] | [next] | [standalone]
| From | "Richard Maher" <maher_rj@hotspamnotmail.com> |
|---|---|
| Date | 2013-01-05 08:22 +0800 |
| Message-ID | <kc7rol$8pu$1@speranza.aioe.org> |
| In reply to | #20836 |
"Arved Sandstrom" <asandstrom2@eastlink.ca> wrote in message news:nUoEs.1$Z03.0@newsfe23.iad... > On 12/29/2012 09:43 PM, Arne Vajhøj wrote: >> On 12/29/2012 7:22 AM, Arved Sandstrom wrote: > [ SNIP ] > >>> I emphatically don't delineate layers by technology used, or even by >>> location. A clean, understandable architectural picture can deal with, >>> and explain, business logic in Javascript on a mobile browser, and also >>> business logic in a DB stored procedure. >> >> Business logic can be put in all tiers. >> >> But it may not be equally good design. >> >> Arne > > There are several schools of terminology here, Arne. I hold to the school > that says that a "tier" is a physical division in a system > (hardware/software) architecture, while a "layer" is a logical division in > a software architecture. > > So that's why I said what I said the way I said it, using the words > "layers", "technology" and "location" on purpose. I think that as long as > your business logic is identifiably in a location where it should be, then > you have a sound solution (all other things being equal). > > In any case we commonly have business logic in the data tier. A subset of > business logic is business rules, and one category of business rules is > data constraints. And data constraints, as you know, are very often > imposed directly in an RDBMS or managed indirectly through JPA or its .NET > equivalents, to use just a few examples. > > Since we - software developers in general - routinely do the above, I see > no reason to demonize business logic in stored procedures either. In fact, > given the efficiency of a modern RDBMS in handling DML it is frequently > the most sensible place to put certain kinds of business logic. > > To be honest I've been uncomfortable for a long time with the label and > concept of a "business logic" layer, as opposed to say DALs or > Presentation layers. For example, workflow is a component of business > logic - in order to adhere to orthodoxy you have to then maintain that > every aspect of workflow in web apps, SOA orchestrations or mobile client > apps is still business logic. > > Which probably it is - in which case why is Javascript business logic a > bad thing? I've worked in a bunch of shops where to utter Javascript and > "business logic" in the same sentence occasions gasps of horror. :-) And > yet many of these same people have methods, that are directly exposed > through JSF web pages, also doing business logic. I'm not indicating > strongly here what I advocate and what I don't, I'm just saying that > business logic permeates every tier we have, so maybe the concept of a > "business logic" layer needs some thought. > > I think at a minimum a developer needs to understand what business logic > is - rules and workflow - and needs to adequately manage where it is. I > think it's less important what tier it's in. I think a perceived problem with your incredibly resonable arguments Arved is that the primary objective in most (certainly .NET) IT depts today is to eliminate SQL altogether and nothing to do with user/business requirements. Your reference to their anathema of Store Procedures and Referential Integrity to enforce business rules and logic would rule out Code-First which is the Holy Grail of OO sites. Technology and fashion is paramount here. Fit-for-purpose can often be a nebulous concept subject to whimsy and subjectivity :-) As for vendor lockin it seems that Microsoft .NET is oft automatically excluded from this category for some reason. And forget about the worry of including business rules in different layers, I regurlary see the same business rules and almost identical classes duplicated in project after solution after application. Code Reuse (like the GAC) just seems to be in the too-hard-basket. Easy-to-code seems to be the overriding requirement, just look at ODATA :-( But let's say they put all the business rules in the Business Layer implemented in a Java or C# class. Who is going to inforce thos rules from PHP Perl or Python access? > > AHS Cheers Richard Maher PS. Applets are alive and well.
[toc] | [prev] | [next] | [standalone]
Page 2 of 4 — ← Prev page 1 [2] 3 4 Next page →
Back to top | Article view | comp.lang.java.programmer
csiph-web