I am attending a training course where they presented the following graphic as the Anatomy of a Typical Java Web Application. Is it too sweeping of a statement, or is it largely accurate?
Here it goes:
(Disclaimer: My experience is drawn mostly from non-Java platforms, though I have some limited experience with Java - but mostly I'm not a fan)
It's accurate - but only for applications using that architecture - which makes this statement somewhat of a tautology.
I'll break it down:
Service Consumer Perspective
A "service consumer" is also more commonly known as a client.
"Service interface files" are not needed to build a client.
I assume by "interface files" it's referring to things like a SOAP WSDL document or Swagger file for REST services. These files are not generally used by clients at runtime but are used to automatically create client class-libraries at design-time - but you can always build a client without any code-generation or reuse of Java interface types.
If it is referring to the reuse of the server/application's Java interface types then the diagram is only accurate for client+server applications that are all-Java and are both designed/created at the same time (which is an old practice from the days of SOAP). Thesedays everything made in the past 5-10 years is RESTful and returns JSON data, but Java interface types are insufficient to model unstructured data like JSON (given you can't model discriminated-unions without concrete classes... in exception handlers, egods, and discriminated-unions are an important tool to model JSON in OOP languages).
Service Provider Perspective
I disagree with the use of the term "Front controller" being used to refer to what is commonly known as a back-end web-service controller, Servlet, or Spring Controller as "front-end" generally refers to the user-facing UI/UX, such as the rendered HTML+JS, an SPA front-end, or rich-client/fat-client (granted, this would be the "service consumer").
You don't need "service metadata" to have a web-application or a web-service - though if you're shipping a web-service designed to be consumed by disparate or non-first-party clients then its a good idea to make a WSDL, Swagger, or whatever metadata or service-description system your platform uses so that your consumers can generate their own strongly-typed clients.
"Service implementer perspective"
So this is my biggest objection: this diagram assumes that the web-service will be 3-tier and the controller/Servlet code is only a thin layer in front of "application" types located elsewhere in the system. While this is common in large-scale and complicated applications where you'll have host-agnostic application code that is designed to be able to run in, for example, an integration-test or unit-test host - or as a desktop application, in my experience I estimate most projects lump all application logic inside the host-specific (i.e. Spring, Servlets, etc) code because it simplifies things greatly (and because those hosts often support testability anyway - and the idea of reusing application code libraries as-is for desktop or mobile applications just doesn't work out well in reality given the massive differences between the disconnected and stateless model of web-service requests compared to the needs of stateful in-process client applications).
In summary: it's not wrong, but I don't believe it accurately describes the majority of (Java) web-applications I've personally dealt with... but this is my subjective opinion and I know that Java web-application and web-service frameworks like Spring and Java EE are designed for and encourage 3-tier architecture, I wouldn't describe them doing-so as an example of the pit-of-success - I feel this is partly due to shortcomings in the Java language design (and the fact these frameworks were designed over 20 years ago before things like generics were added to the language).
Related
I spent the last couple of days figuring out what development stack to use for the interactive student platform I'm planning to build.
I figured out that the MEAN stack may suit the job very well. However, I face a dilemma whether to use Node.js as backend technology for the application:
Reasons to consider Node
The backend will mainly consist of realtime components. E.g. collaboration tools, notifications, etc.
These components will handle this data concurrently
It will scale better than a conventional server-side programming language such as PHP
Exposing the data with REST for e.g. a mobile applications will be a breeze
Having one data format (JSON) in the front- and backend will speed up development.
Doubts
Some components require computation. Although not that complex, it may slow down the application.
Although the application is mostly a single page application, the application will (in a later stage have some features that Node seems not typically suited for. E.g. a payment workflow.
I already made the switch from a previous approach, so this time I want to be sure to choose the right approach. Will Node.js be the right choice for this application, or will a, for example, PHP backend with Laravel suit the job better as the application matures?
I think there's a whole range of possibilities you're not considering, for example it's a perfectly valid approach to use Node for some of the back-end (e.g. connections to third parties, managing the UI, handling concurrent users) while delegating some of the back-end to other components that are more suited (e.g. components that require heavy computation).
That said, I don't see anything you describe in your 'doubts' as being particularly non-nodish. The computation stuff you say will be lightweight, but my recommendation there is to treat it like any other async task, then if you decide later that it is a problem (e.g. slows down the app) it's pretty trivial to extract that out into either a separate Node process (therefore not blocking your main app's event loop) or use a component built in your language of choice (Java, .NET, C, Perl, whatever) as described above.
I don't understand why you suggest a workflow isn't something Node is suited for. I've seen and built a number of them in Node and other frameworks, it's no less suited for it than any other framework, and better than some.
What is difference between rpc frameworks like thrift or gSoap and build-in MS RPC if we talk about security configurations. MSDN describes on http://msdn.microsoft.com/en-us/library/windows/desktop/aa379441(v=vs.85).aspx some aspects, so I can presume that there is support from Microsoft in rpc. Does this mean that if i would like to use different frameworks than MS, I need to take care of security by myself?
This is a very broad question. I'm not quite sure what you really expect, but I'll try to do my best to answer your question.
First, of course you have to take care of the security of whatever you are writing, be it server or client code. Security with regard to RPC services is a wide field, and any sophisticated security feature made available to you by a framework is still just a tool, and still only one part of the overall security concept of your service. To put it in another way: Using SSL will not protect your server from SQL-Injection.
Next, Thift , SOAP and MS-RPC each have different design goals. Thrift is designed with performance and portability in mind. Thrift is more focused on the basic RPC to provide efficiency and portability to any application, for any purpose, in the simplest possible way that works. Of course this approach implies, that there are not much higher-level features, because this is considered being out of the scope of Thrift and left to the user. However, for some of the languages TLS (SSL) transports are available.
In contrast, SOAP is a much richer protocol, based on XML as an machine-readable, standardized and extendable format which can be extended to support higher level features like WS-Security, WS-ReliableMessaging and so on. The downside is, that I have seen many frameworks and development tools which - despite the fact that SOAP has been standardized years ago - are still not able to deal with SOAP in the simpest fashion correctly, let alone supporting WS-Security. Yet, even in spite of this and even in spite of the fact, that SOAP messages tend to produce a lot of traffic and give bad performance, SOAP is still widely used in the industry.
MS-RPC as one of the foundations of DCOM is bound very much to the Windows environment and to Windows development tools. If you can live with that limitation and want to use DCOM, then DCOM offers a very high-level abstraction with good and proven support in today's IDEs.
What is the difference between the next terms, it can help a lot in interviews and general understanding.
Framerwork
Library
IDE
API
Framework
Some predefined architecture that a developer has chosen and which dictates how the application will be written. It usually already includes many concepts which helps the developer to concentrate on the domain of the application instead of the plumbing. This plumbing is provided by the framework. For example the .NET framework provides out-of-the-box tools that would allow you to talk to web servers, without even knowing the internals of the TCP/IP protocol (actually it helps knowing the internals but you get the point).
Library
A reusable compiled unit that can be redistributed and reused across various projects. Well not necessary compiled in case of dynamic languages.
IDE
It's the development environment where you create the other three parts (usually text editor), it might also include compiler and the possibility to execute, debug and see the output of the program in order to speed up the development process.
API
Application Programming Interface. This could mean many things but usually it is a set of functions given to the disposition of the developer and which perform specific tasks and work only in a specific context.
IDE is a tool for fast, easy and flexible development
An API is provided for an existing software. Using these third party applications can interact with main/primary application.
A framework or library are typically same. They are a common set of functionality for other software to use.
Ref: wiki for Framework, API
Framework: a collection of libraries and programming practices to provide general functionality for a program, so that it doesn't have to be rewritten. Typically a framework for an application program will handle user display and input, among other things. The intent is usually to hide the more complex functionality of an application, and to encourage a certain style.
Library: A piece of software to provide certain functionality to other programs that call it. Typically designed to be reusable and modular, so that a library can be distributed and be useful without its source code.
Integrated Development Environment: A integrated set of tools to write programs and turn them into finished products, usually including at least an editor, compiler, linker, and debugger. IDEs sometimes provide support for frameworks.
Application Programming Interface: A set of function calls and sometimes variable accesses available to a program, typically being the public interface of one or more libraries.
I'm in the beginning phases of a Blackberry/J2ME project -- and along with other limitations that come with this wonderful platform, the lack of support for reflection and 1.3 language level mean that the vast majority of existing IoC containers are unusable. (Google has Guice for Android with no AOP, but even that requires support for annotations).
So the space of IoC containers on J2ME is pretty limited. The one framework that has caught my attention is called Signal Framework, and it looks pretty promising. It tries to stay conceptually close to Spring Framework's IoC, implementing a small subset of its functionality, and does so without relying on bytecode-modification or causing runtime xml parsing. Instead, it processes configuration XMLs at build-time to generate java code which implements this IoC functionality.
Generally speaking, code generation at build time seems like a very wise approach for mobile applications -- and if my app has to do less XML parsing on user's device, that's great too!
So, what have your experiences been with implementing IoC on J2ME/CLDC, and how were you able to extinguish that bitter taste in your mouth?
We used Spring ME at TomTom. It worked out pretty well.
In J2ME you need to reduce the number of classes you use as much as possible to reduce the size of jar files. This leads to many design compromises not least of which is flexibility.
It is not easy to adjust to J2ME development when you have to throw must of what you hae learnt (and come to value highly) about OO out the window. The truth is if you want apps that can run on a large range of phones you need to be very sensitive to the constraints of the devices.
As such I do not think an IoC framework will match many people's needs for J2ME development.
You might be interested in checking out FallME. Even though I haven't used it personally, it seems like a no non-sense framework built specifically for the J2ME platform.
I came across Spring ME during a Dutch JUG conference (have no experience with it whatsoever).
Signal Framework it is.
Update: unfortunately, Signal is very undercooked right now, so I'm going with Israfil IOC with custom additions.
I have a mixed UI (Win App, WPF App, and soon an ASP.NET MVC App) setup, so far I'm using Client Application Services for security. I know how to programmatically get a user authenticated and doing so is working beautifully. However...
I want to implement some cross cutting that basically checks to see if the user is authenticated all the time. Since everything will be accessing web services I want to enable this as a standard execution for pretty much everything the UI does. So far I'm thinking the PIAB - Policy Injection Application Block - will serve that function. What I'm wondering is two things;
1 Will the PIAB cover that needed functionality? Verifying authentication at every practical step if used against the UI?
...and...
2 Are there alternatives out there besides the PIAB? I'm curious to do a comparison of aspect oriented policy injection frameworks.
I'm not really familiar with Client Application Services but from my experience, most AOP frameworks wrap interfaces in order to implement the cross-cutting functionality. If CAS uses interfaces, you could probably just wrap them with what ever functionality you require.
Alternative AOP frameworks:
Spring.NET
Castle Dynamic Proxy
Spring.NET and Dynamic proxy seem to work in much the same way and have much the same performance in my Hello World type tests (about half-way between direct calls and invoking through reflection). PIAB is significantly slower than both these frameworks and I found bit more verbose. It does have the ability to be configurable via xml and I'm not sure if that's a good thing or not. Not sure if the other frameworks provide that. It does of course have the MS stamp of approval though :P.