OOOHHH, now that's enterprisey



  • With apologies, I think I stole this title from an old front page post.

    So I've got an application developed offshore, and they've asked me to take it over the finish line.

    It's actually two applications. "The UI and the back end." Two separate WARs. UI doesn't involve Java or the DB at all.

    How, you ask? Well the UI pops up a loading screen and then AJAX's the information from the other application into tables/etc.

    OK, seems simple enough.

    At first I said "Nobody ever told these guys you can put UI and business logic in the same war." Then I asked the PM about it. She had the same questions as me and the architect told her, "Well, what if we make it a mobile application? There are standards, you know."

    I think this is the definition of enterprisey. Thinking about the uber future before you see what's in front of your face.


  • FoxDev

    Separating the front-end from the back-end? That's pretty normal, last time I checked; I don't see the :wtf:



  • Seconded. Sure, you can hack and mix things together, but that generally turns out to be a massive technical debt later on.

    I had to work with code that generated the UI in the database. As in, the actual HTML elements came out of stored procedures. Let's just say it wasn't a pretty sight...



  • You realize that we're not just talking about separating the front-end and back-end code into separate projects?

    These are two entirely separate web applications both installed on the same web server.

    This is as opposed to, say, my current project that has data classes that are compiled into a .jar that then lives inside our web application.



  • Separate into different files, sure. Nobody throws SELECT statements into their JSP files. But completely different applications?



  • @powerlord said:

    You realize that we're not just talking about separating the front-end and back-end code into separate projects?

    These are two entirely separate web applications both installed on the same web server.

    I don't speak Javanese, but isn't a WAR like a C#'s assembly or project (in that you can and should separate business and UI logic at that level?)

    If those are two separate apps, well, that is a little freaky. And probably cross-origin-problematic. I've seen worse, though...


  • FoxDev

    @powerlord said:

    These are two entirely separate web applications both installed on the same web server.

    Again, not unusual. In fact, it's a good idea; it means you can take, say, an old Silverlight UI, and replace it with an ASP.NET MVC UI. What's more, you can do this in stages. And since both UIs talk to the same back-end, you don't lose any data, or end up with weird inconsistencies.

    TL;DR: I still don't see the :wtf:



  • Would I get the WTF if I knew what a WAR was?

    If it's a shared library, then... yeah, this is perfectly normal. Even if it's a web API it's not too weird.



  • @powerlord said:

    You realize that we're not just talking about separating the front-end and back-end code into separate projects?

    No.

    @powerlord said:

    These are two entirely separate web applications both installed on the same web server.

    Ok? Still not too unusual. The main app I work on has an API in C# and a front-end in Angular. So it's "two entirely separate web applications both installed on the same web server." LE GASP!



  • @Maciejasjmj said:

    I don't speak Javanese, but isn't a WAR like a C#'s assembly or project (in that you can and should separate business and UI logic at that level?)

    If those are two separate apps, well, that is a little freaky. And probably cross-origin-problematic. I've seen worse, though...


    I don't speak .NET-anese, but let me explain this way:

    /appui fires up AJAX client and then goes and asks for data from the /appbackend application, and populates it through DOM manipulation. Standard stuff, but absolutely zero reason it should be a separate application.

    I'm sure Facebook and Google do this all over, but they've got more than the 20 users this has.


  • FoxDev

    @blakeyrat said:

    Would I get the WTF if I knew what a WAR was?

    Maybe? I think I've found what a WAR is; seems to be essentially the same thing as an ASP.NET webapp, just in a single archive.



  • Maybe if someone explained WHY this is (or they perceive it to be) a WTF.

    Does it make installation significantly more difficult? Development? Does it consume too many server resources?



  • @RaceProUK said:

    you can take, say, an old Silverlight UI, and replace it with an ASP.NET MVC UI

    What if I told you this had a small user base and wasn't a public application?


  • FoxDev

    @belgariontheking said:

    What if I told you this had a small user base and wasn't a public application?

    I'd say
    @RaceProUK said:
    In fact, it's a good idea; it means you can take, say, an old Silverlight UI, and replace it with an ASP.NET MVC UI. What's more, you can do this in stages. And since both UIs talk to the same back-end, you don't lose any data, or end up with weird inconsistencies.



  • @Maciejasjmj said:

    I don't speak Javanese, but isn't a WAR like a C#'s assembly or project (in that you can and should separate business and UI logic at that level?)

    If those are two separate apps, well, that is a little freaky. And probably cross-origin-problematic. I've seen worse, though...

    jar files are similar to a C# assembly.

    A war file is a single web application whose META-INF/lib directory will contain a bunch of jar files the web application uses as its dependencies1. It's pretty common to have jar files that contain your other application layers.

    There is also the rare ear file which can contain multiple war files... or a war file and some configuration files for it. Note that the latter is a definite wtf and the former is highly discouraged.

    1Java build systems also have provided dependencies for things that are needed for compile time but are provided by the J2EE server itself. They also have runtime dependencies for things that are needed at runtime and not compile time, like DB drivers for server managed connection pools.



  • @RaceProUK said:

    it means you can take, say, an old Silverlight UI, and replace it with an ASP.NET MVC UI.

    You can do this by just replacing the project in the solution, though (well, maybe not Silverlight, I don't know, but Webforms-to-MVC is perfectly doable).

    @belgariontheking said:

    /appui fires up AJAX client and then goes and asks for data from the /appbackend application, and populates it through DOM manipulation.

    Is /appui a client-side application (in which case it's a trendy and fairly sane webservice-style design), or a server-side application (in which case it is admittedly somewhat WTFy to have two apps hosted side-by-side communicate via web channels, but... meh)?

    @blakeyrat said:

    Maybe if someone explained WHY this is (or they perceive it to be) a WTF.

    Does it make installation significantly more difficult? Development? Does it consume too many server resources?

    Well if those are two server-side apps, deployed on the same server, it's kinda WTFy for them to communicate via AJAX requests.



  • @RaceProUK said:

    I'd say
    ...

    And I would say "that's enterprisey,"



  • @Maciejasjmj said:

    Well if those are two server-side apps, deployed on the same server, it's kinda WTFy for them to communicate via AJAX requests.

    Slightly. But ... still. Even Amazon AWS won't bill you for localhost accesses. So what's the harm?

    I honestly don't get the WTF here.


  • FoxDev

    @belgariontheking said:

    And I would say "that's enterprisey,"

    Two-tier architecture ≠ enterprise; two-tier architecture ≡ normal



  • @Maciejasjmj said:

    Well if those are two server-side apps, deployed on the same server, it's kinda WTFy for them to communicate via AJAX requests.

    This. When they can just as easily communicate by being in the same application. So much easier to just define a bean (Object that contains state, for you .NETers), populate it, and slurp it up than to define a bean, populate it, slurp it up, define a webservice, consume the webservice, and populate a table via DOM manipulation.



  • @blakeyrat said:

    So what's the harm?

    Probably none, it's just kinda pointless for two components you have full control over not to live in the same solution and be able to refer to each other's functions directly. Instead you need to wrap them up in a webservice handler, probably go through JSON screwing with your data, etc, etc.



  • @RaceProUK said:

    Two-tier architecture ≠ enterprise; two-tier architecture ≡ normal

    No one is arguing two tiered architecture, but making them this separate in a small, internal only application is thinking too far forward. Thus, enterprisey.


  • FoxDev

    @Maciejasjmj said:

    Probably none, it's just kinda pointless for two components you have full control over not to live in the same solution and be able to refer to each other's functions directly. Instead you need to wrap them up in a webservice handler, probably go through JSON screwing with your data, etc, etc.

    Depends; if the back-end takes a long time to start up, do you want to have to restart it every time you tweak a bit of UI code?



  • Yeah, encapsulation and sane APIs are pointless.

    I'm getting a headache.



  • @belgariontheking said:

    This. When they can just as easily communicate by being in the same application. So much easier to just define a bean (Object that contains state, for you .NETers), populate it, and slurp it up than to define a bean, populate it, slurp it up, define a webservice, consume the webservice, and populate a table via DOM manipulation.

    Ok, first of all: "slurp it up"? What the fuck is wrong with you? (Object that contains state? So... literally every object in every programming language ever? Why do you have a new word for that!)

    Secondly: unless you're language is really WTF "define a webservice" is like 4 lines of code. It's trivial shit. Then again, you're using Java so it's probably closer to 50,000 lines.



  • unless you're language is really WTF "define a webservice" is like 4 lines of code. It's trivial shit.

    Right. It's not like they designed a custom networking protocol and reinvented 15 wheels. They just thought ahead and used sensible tools to achieve a goal.



  • No, it's not just "any object." Maybe I'm not explaining it well.

    So if you have an object that contains the user's name and address, that's a bean.
    In my (other) application, I have controller classes that define where redirects go, etc. Those aren't beans.
    I have objects that I use to access the database. Those aren't beans.

    So your JSP (Java Server Page, html-generating class) can fire up a bean and start pulling data from it. You can define beans with whatever scope you like. A big universal lookup bean might have an application scope, where your user's name and address bean would have a session scope.

    I hope that helps.

    Also, you're ignoring the consumption and DOM manipulation. Even 4 lines of unnecessary code is still unnecessary code.



  • In Java, a Bean is just a class with a public no-argument constructor that uses public getter and setter methods.

    The public getters and setters are used to fake properties in JSP pages in case you're wondering.



  • @blakeyrat said:

    Why do you have a new word for that!

    JavaBeans, from what I gather, are kinda like POCOs, except more conventionalized, so that it's easier, for example, for a library to reflect on them since it can make assumptions on the names. Or something.

    @Captain said:

    They just thought ahead and used sensible tools to achieve a goal.

    A sensible tool is what the language gives you - a solution, package, or whatever. Using a webservice for that is kinda like hammering a nail with a screwdriver.



  • It sounds more like using a nailgun where a hammer will do. Which is pretty much fine.



  • @belgariontheking said:

    So if you have an object that contains the user's name and address, that's a bean.

    Ok. So it's an object. The entire point of an object is that it can store data and functions related to that data in a single unit, so saying it has two bits of data is kind of redundant-- that doesn't make it not-an-object.

    @belgariontheking said:

    In my (other) application, I have controller classes that define where redirects go, etc. Those aren't beans.

    What makes one object a bean and another not-a-bean? Just because the controller class doesn't store state?

    @belgariontheking said:

    So your JSP (Java Server Page, html-generating class) can fire up a bean and start pulling data from it.

    It initializes an object.

    @belgariontheking said:

    You can define beans with whatever scope you like. A big universal lookup bean might have an application scope, where your user's name and address bean would have a session scope.

    So it's an object either inside an application-level cache, or a session-level cache.

    @belgariontheking said:

    I hope that helps.

    Not at all!

    @belgariontheking said:

    lso, you're ignoring the consumption and DOM manipulation. Even 4 lines of unnecessary code is still unnecessary code.

    I'm not ignoring it, I just don't think it's a big deal.

    @powerlord said:

    In Java, a Bean is just a class with a public no-argument constructor that uses public getter and setter methods.

    Right; I just don't get why that thing has a name.



  • @Captain said:

    using a nailgun where a hammer will do.

    A nailgun is a convenient tool for hammering nails, it does it faster, more efficiently, and requires little to no preparation.

    None of those really apply to a webservice - neither for hammering nails, or passing data.

    @blakeyrat said:

    I just don't get why that thing has a name.

    So that:

    a) if you're told "this function returns a bean with fields Name and Address", you don't need further docs to know that the getter is getAddress() and the setter is setAddress(), and that it's serializable, etc, etc.
    b) if you use a library that expects a bean, you can just define which fields your object has and the library can work out on the assumptions on how the rest of your object looks like. So you don't need to say, for example, that getAddress() is a getter for Address.

    More useful or less useful, but it warrants having a name to me.



  • I... guess? Whatever.

    Java is weird and dumb.



  • I'm not here to defend Java.

    However.

    I kinda missed you blakey, in a "citric acid in my eye" kinda way.


  • FoxDev

    This would be why C# doesn't have a name for it; it uses properties, instead of some freaky getter/setter bullshit…



  • @RaceProUK said:

    This would be why C# doesn't have a name for it; it uses properties, instead of some freaky getter/setter bullshit…

    Someone long ago decided that public variables in Java were a no-no. Therefore, everything is private and accessed via setter/getter. It makes no difference as far as I can see, but it is what it is.



  • And those are even better for reflection, because reflection knows what properties are.

    @belgariontheking said:

    Someone long ago decided that public variables in Java were a no-no. Therefore, everything is private and accessed via setter/getter. It makes no difference as far as I can see, but it is what it is.

    That's how C# works too, kid. Didn't Aunt Pol teach you anything?


  • ♿ (Parody)

    I think there's more to it when you get into the J2EE realm. The description above sounds like an entity bean, which is basically some domain object you have:

    Then you get into enterprise beans

    Without getting into eye glazing particulars:

    Enterprise JavaBeans is intended to handle such common concerns as persistence, transactional integrity, and security in a standard way, leaving programmers free to concentrate on the particular problem at hand.



  • A nailgun is a convenient tool for hammering nails, it does it faster, more efficiently, and requires little to no preparation.

    None of those really apply to a webservice - neither for hammering nails, or passing data.

    Wow, really? A webservice isn't a good option for passing data? Whatever they smoke in Estonia must be good.


  • FoxDev

    @boomzilla said:

    Without getting into eye glazing particulars:

    Enterprise JavaBeans is intended to handle such common concerns as persistence, transactional integrity, and security in a standard way, leaving programmers free to concentrate on the particular problem at hand.


    C# has the same abilities. However, instead of inventing a whole new can of terminology, you just decorate your classes with a handful of attributes, and let the .NET Framework do the heavy lifting.


    Seriously? Even that style of quote is broken inside quotes? Fuck.



  • Between apps living on the same server and being components of the same overall application? Not really.

    Do you send postcards to your wife in the other room to tell her to come over?


  • ♿ (Parody)

    @RaceProUK said:

    C# has the same abilities. However, instead of inventing a whole new can of terminology, you just decorate your classes with a handful of attributes, and let the .NET Framework do the heavy lifting.

    In practice, that's mostly what it comes down to. But there's a whole standard, etc, and multiple implementations.

    @Maciejasjmj said:

    Do you send postcards to your wife in the other room to tell her to come over?

    Of course not. I send my calling card with the servant, you savage.



  • Between apps living on the same server and being components of the same overall application? Not really.

    And you can guarantee that they will always be on the same server? And that the cost of refactoring whatever shitty class-based solution into a web service will be lower than just doing it in the first place?

    I probably would not send a post card. But a text message could be sensible.


  • ♿ (Parody)

    @Captain said:

    And you can guarantee that they will always be on the same server?

    @belgariontheking sounds pretty confident. I didn't pick you for an Enterprisey kind of guy.



  • I'm more of a cost-benefit guy. And I don't see what makes a web service have such a high cost that we're still discussing an architectural choice.


  • ♿ (Parody)

    It seems like overkill to me. It's making the developers' lives more difficult for (presumably) little benefit. If they had plans to do all those crazy things, then OK. But let's be honest here, YAGNI.



  • @boomzilla said:

    In practice, that's mostly what it comes down to. But there's a whole standard, etc, and multiple implementations.

    Multiple standards.

    My understanding is that JPA started out as part of EJB before becoming independent.

    Edit: Actually, JPA replaced Entity Beans as of EJB 3.


  • ♿ (Parody)

    Well, yeah...it's been long enough that they've proliferated like hell. I don't honestly understand most of it, though I work with it every day. Pretty much, I just put in some annotations and do my job.



  • @boomzilla said:

    Well, yeah...it's been long enough that they've proliferated like hell. I don't honestly understand most of it, though I work with it every day. Pretty much, I just put in some annotations and do my job.

    I've never dealt with EJBs directly. These days, I either deal directly with bullshit POJOs or use JPA decorated classes.

    Incidentally, .NET has its own version of JPA.



  • That being said, NOT_A_WTF

    Before I get blakeyranted at, I just want to point out that google put Web Application Archive as my third result, sorry for the dickweedery.


Log in to reply