We Keep Coding

How to intercept and validate HTTP requests in a Java EE environment

I'm doing a project and the main concept is to develop an engine for Java EE that validates HTTP requests from the client.
I have looked at one engine related to this and it's the OWASP PROJECT STINGER. My own understanding of this engine is that a developer that uses the STINGER engine sets all the rules or configures everything, like setting regular expressions that are allowed and cookie rule sets by filling out an XML file (which they call an SVDL file).
Now my main question is how will I develop an engine for Java EE? Where will I start?

Well, it is not called J2EE anymore. There has been several years since it was changed to Java EE. Now, Java EE is a compendium of technologies (i.e. JAXB, RPC, EJBs, JSP, JTA, etc., etc., etc.). Implementing a full container is a major task and I doubt this is what you intend. You appear to be talking about implementing an HTTP server, which is probably a small part of what Java EE does.
Now, if you insist in implementing them, the starting point is always reading the Java Specifications for the particular technology you intend to implement. Download the JSRs from the Java Community Process and desing your implementation according to its requirements.
For instance this is the Specification for Servlets

how do java frameworks relate to java platform

I can code in Java, and I'm trying to understand the wiki article on frameworks and how they relate to java. I think java = the platform and the frameworks are things like Java EE, jsp, etc. (I've never used any of those)
I'm trying to see the connection here.... Also, does each framework get its own compiler? Do they all use the JVM?

From my understanding: Java is a programming language (that compiles through the JVM), it is "open source" and can be extended with different APIs. Java EE (Enterprise Edition) is an API of Java SE (Standard Edition), it adds more functionality to the Standard API of Java.
Frameworks are supposed to make programming in languages like Java easier, and decrease development time. For example a framework named "Play" is a pretty popular java framework that helps develop web pages. Frameworks are not seperate from the language, they use the language itself so they don't get their own compiler all it's doing is using the language.
Someone (or a company) just creates their own methods in java and make them available to use for anyone that wants to use it. Anyone can create a framework, you can probably think of a framework as a Lego set where each Lego piece is a method available to build your own program (or website, depending on what the framework was created for), eventually you can build your own program using those methods from the framework. (hope this is making sense, heh)

Strictly speaking Java is a programming language. Just a programming language. It needs an implementation if you are to compile and run programs.
The Java implementation(s) consist of bytecode compilers and related tools, and a runtime platform. The runtime platform consists of an implementation of the Java Virtual Machine (JVM), together with the runtime libraries that contain the standard classes.
There are in three primary Sun/Oracle Java "platform" types ... or Editions as they are called:
Java Standard Edition (SE) is the normal general purpose platform. Unless specified otherwise, this is what most people will be using.
Java Micro Edition (ME) is designed for embedded devices such as smart phones, set-top boxes and the like. It is a very cut-down version of Java, with some significant differences in some area.
Java Enterprise Edition (EE) is an extended platform designed to support enterprise computing. It adds support for web server development, component-based systems (EJB) and other things. (In fact J2EE is a bit more woolly than this, because there are web container distributions out there like Tomcat, Jetty and so on that provide a subset of the Java EE technologies ... on top of a standard Java SE platform.)
A framework is a different idea. Frameworks are typically systems of libraries that support a particular way of designing and implementing software applications. So for instance:
The core Spring Framework supports a style of programming where the system is "wired up" from a bunch of components at start up.
Spring MVC (and other frameworks) support web servers that are implement according to the Model-View-Controller design pattern.
A RESTful web server framework supports web servers that follow the RESTful model.
And so on.
These frameworks typically run on one or more kind of Java platform, depending on what they are doing.
Also, you could make a case that some of the technologies that are in Java EE platform are actually framework technologies. Servlets and EJBs are prime examples.

If you are familiar with jQuery in javascript, well jQuery is a javascript framework. Same goes for framework for java. It just makes programming easier

Why is the play framework not built on top of the Servlet API?

I started playing with the playframework recently and really enjoy the simplicity.
But one nagging question I've had is why it eschews the servlet specification all together? What was the main motivation behind such an architectural decision?

From the FAQ
We are fully aware that we made
choices that are pretty uncommon in
the Java world, and that Play does not
blindly follow all the so-called Java
‘good practices’. But all of the Play
team members are very experienced Java
developers and we are totally aware of
the choices we made and the rules we
broke.
Java itself is a very generic
programming language and not
originally designed for web
application development. It is a very
different thing to write a generic and
reusable Java library and to create a
web application. A web application
itself doesn’t need to be designed to
be reusable. You need less
abstraction, less configuration.
Reusability does exist for web
applications, but through web service
APIs rather than language-level
integration.
When the development time tends to
zero you can concentrate on your
application features and experiment
quickly, instead of trying to abstract
things for future developments.
Play! applications can be deployed as web application on other web server containers, but it is mainly designed as a full stack framework; Play is the platform. And, in my opinion, this is what makes it beautiful and fast.

Checkout Guillaume Bort's blog. (Founder of Play!Framework). He explains it all on his blog.
EDIT : The link has changed, thanks procrastinate_later

Advantages of SCA over Spring?

I have experience developing java web applications with Spring, but not so much with the world of SOA. I was reading about SCA- SCA4J - http://www.service-conduit.org/user-guide.pdf - and alot of this seems very similar to Spring.
I was trying to learn about what situations SCA would be useful, but still dont understand what features / benefits SCA offers over using Spring standalone.
I found this old blog post - http://rajith.2rlabs.com/2007/08/05/sca-vs-spring-a-reply-to-dans-post/ - but nothing really stood out to me from the SOA jargon.
I'd appreciate it if anyone could give an explanation geared more towards a spring developer (who is very green in the world of SOA terminology / methodology).
Thanks

I'm not the most knowledgeable about Spring, but am pretty familiar with SCA from having worked with it in IBM's WebSphere Integration Developer IDE and the environments it deploys to: WebSphere Enterprise Service Bus and WebSphere Process Server.
It really all has to do with abstraction and the thought of allowing developers to focus on what is most important - business logic. We are all familiar with the concept of Object-Oriented Programming and how that abstraction better represents the "real world". Then along comes web services and the service-oriented architecture approach. Web services further abstract our logic by making it less dependent on what language is behind our logic. Now C++ or .Net or Java or even RPG or COBOL or whatever could be behind our web service. We can get languages and systems to talk to each other in a way that doesn't depend on CORBA and libraries and what not.
SCA (Service Component Architecture) attempts to take SOA to the next level. It attempts to abstract the protocol and address used to talk to another system or service. Here's the why: With working with web services, you as a developer still need to work with protocol and write or hook in a LOT of boilerplate code. You have to know if you are http or https. You have to know if you are (in the Java world) JAX-RPC, JAX-WS 2.0, JAX-WS 2.1, JAX-WS 2.2 or even JAX-RS (REST based). You need to know if you are working with JSON, XML, or SOAP and if SOAP, is it 1.0, 1.1, or 1.2? And sometimes you even have to know how the vendor of your application server implements certain things (you shouldn't, but it can be the case). And then what happens if you want your web service to talk to another service. But that second service happens to be messaging based. Does that mean JMS? MQ? JMS over MQ? other? And what about just pure HTTP POST and GET?
This is where SCA comes in. SCA attempts to abstract the end points of your services and hide the protocol implementation from you the developer. When you need a service you just look it up via the SCA API's and then invoke the service (I think the method is execute? At least it is in IBM's extension of SCA). But anyway....Now you do not have to know that the service you are communicating with is JAX-WS 2.1 or REST or even MQ. You don't have to know that you working with SOAP/HTTP or JSON/XML or SOAP/JMS or whatever. SCA hides this all from you. It allows you to connect services of differing implementations to each other so they can all talk to one another via a common "service interface".
As you can imagine, this is another layer of abstraction and technology on top of existing abstracted technologies. But having seen it myself, I believe it is worth looking into. I know IBM and Apache (and I think others that just don't come to mind at the moment) worked on coming up with the SCA standard. (And actually IBM's version of SCA is now built on the open standard that Apache presented. Hopefully other vendors that support SCA do the same.)
I think it is worth taking the time to look at. It can help you to focus not so much on the integration of services based on their protocols, but rather the business logic of the services, which is really the value they bring to the table.

SCA is being standardized through OASIS (Assembly Specification), so you can chose from different implementations (e.g. Apache Tuscany or Fabric3).
SCA defines applications in terms of the following basic building blocks:
interface: defines available operations
component: describes an implementation artifact in terms of which "services" it offers, which "references" it requires, and which configurable "properties" it exposes
binding: declares the communication protocol used by a service or reference
policy: captures non-functional requirements for services, references, or implementations
To build SOA applications, concrete "types" of these entities are assembled into composites. For example:
interface: WSDL port type, Java interface
component implementation: Java class, BPEL process, Python, Spring
binding: JMS, Web Service, RMI/IIOP
policy: transaction, security
In addition, SCA defines unified client APIs to invoke components both synchronously and asynchronously (including one-way). For Java this includes annotation-based reference injection.
Combining these capabilities enables you to easily create distributed applications from heterogeneous technologies and evolve them by adding or swapping binding, implementation, interface, or policy technologies.

It is worth looking at Spring Integration (http://www.springsource.org/spring-integration) as opposed to basic Spring when comparing to SCA, since Spring Integration offers a very nice framework for transparently wiring together remote components.

What is the difference between API & Framework [duplicate]

Now, this may be a silly question but sometimes the terms Framework and API are used interchangeably. The way I see it is that a Framework is a bigger more generic thing, containing many API's, that could be used for various programming tasks (for example, the .NET Framework.) An API is smaller and more specialized (for example, the Facebook API.) Anyone want to share their insights on the matter?
And take for instance that Microsoft call .NET a Framework whereas Sun calls theirs a Platform ... so could it be also a business/marketing decision as to how call a "collection of libraries."?

Design Patterns provide the following definitions:
toolkits: "often an application will incorporate classes from one or more libraries of predefined classes called toolkits. A toolkit is a set of related and reusable classes designed to provide useful, general-purpose functionality".
frameworks: "a framework is a set of cooperating classes that make up a reusable design for a specific class of software".
The key here is that while toolkits (APIs) can be useful in many domains, frameworks are geared to solve issues for specific classes of problems, that can be customized "by creating application specific subclasses of abstract classes of the framework".
Moreover, and maybe more importantly, "the framework dictates the architecture of your application": Inversion Of Control is one of the characteristics of frameworks (see Martin Fowler on this); instead of having your application call specific APIs to implement a specific behavior, it's the framework that calls your code.

I've always thought the framework was the whole thing, internal code, API's, etc.
While the API is just the bit you use when you want to make use of the framework.
In other words, the .NET framework consists of the .NET libraries, all the languages and so on. The API is just the way you call the functions.

A framework does introduce the notion of inversion of control
(i.e. the overall program's flow of control is not dictated by the caller, but by the framework)
When you are referring to language frameworks (such as Java Framework or .Net Framework), you actually including more than just libraries and their APIs (which would be more limited a Software Framework if those libraries provide an inversion of control).
A Language Framework includes the development and execution environments which will call your code (to compile it or to execute it).
That is why .Net Framework is a "Framework".
Java may refer to its Frameworks (JDK, JRE) as a "Java Platform" in order to emphasize its "platform independent" programming language feature.
From About the Java Technology
A platform is the hardware or software environment in which a program runs. (including Microsoft Windows, Linux, Solaris OS, and Mac OS).
Most platforms can be described as a combination of the operating system and underlying hardware.
The Java platform differs from most other platforms in that it's a software-only platform that runs on top of other hardware-based platforms.
The Java platform has two components:
The Java Virtual Machine
The Java Application Programming Interface (API)

As its name suggests (Application Programming Interface) the API is just the interface of the framework.

From my understanding, an API is basically a way of interfacing with an existing app (like Facebook), whereas a framework is basically a tool for building your own app from the ground up.

Software Framework: Is a re-usable design for a software system (or subsystem). A software framework may include programs, code libraries, a scripting language, other software to help develop and glue together the different components of a software project. Various parts of the framework maybe exposed through an API.
API (Application Programming Interface): Is a set of routines( AKA methods, functions), data structures, object classes, and/or protocols provided by libraries and/or operating system services in order to support the building of applications.
More details along with other
Link to this particular topic is
http://aprogrammersday.blogspot.com/2009/02/difference-between-framework-and-api.html

API (application programming interface): like his name means, is an interface for externe programs to interact with your inter program or library without having direct access. for example, the google map API and Facebook API give you the interface to interact with their program and library without having direct access.
In the other hand:
Framework : is a collection of libraries that can help you to build an application. you can imagine the framework as a "skeleton" where the application defines the "meat", so you can't take a human skeleton to build a hors body, so you have to choose the good framework before start programing. this is why we said : You call Library. Framework calls you.

I'd like to think that an API is a subset of a framework

In my experience, a framework often includes two things (at least) that an simple API doesn't:
Extensibility: you can compose or subclass framework components to extend or customize its functionality.
Tools for code-generation, administration, or diagnostic tasks related to application development.

A framework is basically a collection of classes that abstract away the development process and promote code reuse for example you might have database, session, and pagination classes that are independent of the application you are building. But an API is source code interface that allows two or more components of different systems to interact, for example adding the Google Maps API to your website, you and Google are two different systems, Google coded the underlying interface for incorporating its products to your website/application. All in all just go with a framework work when building your system, then develop an API when you offer extensions for other people like Facebook and Google.

I know this is an old thread and that it really doesn't matter, but I just can't help but to chime in with my own views. An API (e.g. device driver API, Windows API, etc.) provides the basic and essential functions for a platform such that a programmer can exercise his creativity and do something with the platform - yes, including using it to build a framework. A framework is higher level in function and abstraction, and provide a set of reusable and convenient functions/classes/conventions to facilitate the development of applications that share certain common attributes (e.g. iPad apps, web services, etc.)

A framework implements a very important option called IoC (Inversion of Control) which means in a nutshell that your code has, no more, things in hand.
While in an API your code calls other codes (libraries), when you use a specific framework, it's the framework who is in control of the application flows.