|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 25
Messages: 25
Messages: 25
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
New Article: What is an App Server?
For Java developers, app servers have come to mean specifically Java EE servers with specific features. However, in a broader sense an app server is a piece of software that provides services to applications. Joseph Ottinger argues that we should move back to that definition, as there are newer approaches to providing services that are worth considering.
Read Article
|
|
|
Message #267957
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: New Article: What is an App Server?
Interesting question.
An App Server is a programming model, an architectural construct and guide, and a run-time engine.
To get helloworld to work, you have to read the manual/spec and conform to the coding conventions therein.
To be successful with a project you have to learn patterns and imitate the successes of others who came before you.
Picking the best App Server means obtaining the optimum run-time engine - one that will support the patterns you wish to use and provide stability, and performance: both at a cost [licenses, efficiency - heat, electricity, CPU Utilization, I/O] that does not prevent you from being successful from a business or technological perspective.
First and foremost, an AppServer must:
*) Manage transactions
*) Reduce redundant code by providing common services
*) Allow specialists to specialize [Appserver engineers write the TX engine, I will write my business logic]
*) Provide life-cycle management for my components/services
*) Offer a run-time engine that satisfies my needs
*) Simplify my task of providing a software solution to a problem
The last point: simplifying my task is one that is arguable based on the experience of many many people.
Is it simpler to learn the spec, and peculiarities of someone else's general-purpose platform than to write the bits you need yourself?
I argue: Yes- but only after a huge effort!!
-Does that mean the answer is really: no?
This is why there continues to be a booming business surrounding consulting and training. I believe it is a myth that is sometimes wrongly promoted that using an App Server is always easier than solving the problems it solves on your own. One size does not fit all.
Of Course, after the three 5 day courses, the 400 page book, the 4 blueprint examples, the mentoring and refactoring of your code and architecture and a decade of history with a struggling technology to lean on, the next project based on a particular App Server is often easier than starting from scratch. And the investment has as a result, paid off for the industry at large. It is now possible to hire any number of J2EE [or JEE] developers and get a new project going fairly rapidly. We have succeeded in commoditizing developers. You can shop around the world for such skilled laborers and proceed to solve business challenges leveraging talent from such varied locations as Ireland, India, South America, Norway, Russia, and even the USA.
Still, strange goings on go on.
I remember helping to solve a performance problem with a particular Application that was running on the WebSphere platform and during my examination of the application environment it was discovered that the ear file in question contained among many other things: weblogic.jar !!!
How is that for portability?
The challenge to the general solution to all problems is there will always be specific optimizations and capabilities that are offered by one vendor or another.
Now that there are basically two most-likely commercial vendors left that offer the full J2ee stack, you are likely to seek the assistance of a Websphere or Weblogic/Oracle specialist and developers resume's no doubt will express their preference and product of focus.
Will this near monopoly mean that we can expect a more stable future where the differentiation between the vendors offerings lies more in the bundling options offered, or will we see the two behemoths stretch the spec to continue to include product-specific tweaks that demand specialized understanding?
In either case, the majority of the problems solved will leverage the portable aspects of these environments and the reuse of human knowledge towards the solving of new problems will continue.
One could say that at the most abstract level an App Server makes software projects *more likely to succeed* by taking responsibility for the lion's share of the code necessary to enable robust solutions.
Cheers,
Owen.
|
|
|
Message #267959
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: New Article: What is an App Server?
I had to laugh a bit about the Java-centric view here and terms like "J2EE traditionalist". Application servers have been around for about 20 years. The early distributed transaction servers like Tuxedo have all the qualities of an application server. So do CORBA servers. IBM added application server capabilities to CICS and came up with CICSPlex.
My problem with the J2EE application server is that it isn't much different from what came before. It's too monolithic, one size fits all. It doesn't reflect that these days many capabilities we used to need application servers for can be gotten in other ways from the underlying infrastructure or may not be needed. I like the recent trend to more loosely couple and componentize application server capabilities as is evidenced by Spring's application platform and JBoss.
|
|
|
Message #267960
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: New Article: What is an App Server?
The interesting thing is how the App Server has evolved over time. Specifically, the concept that we even NEED an "App Server".
Historically, the operating system WAS the App Server. That's what made some operating systems more valuable than others.
Also, historically, Unix has been pretty much a wasteland of operating system services...beyond having a rather complete micro utility set particularly well suited to working with ASCII files, Unix offered little more than a VM, pipes, and file locking. Later, we got networking "for free", but even that was an option on early Unix systems.
Contrast that to, say, VMS which has just a heap of services out of the box.
The key one, of course, is the transaction server: CICS, Tuxedo, MTS.
Look at Windows today. The OS is the App Server. You don't get transaction services in .NET, for example, it leverages MTS that is already available.
JEE, on the other hand, is monolithic. You get a JEE App Server and it sets up its own little world of services within which you run your application.
JEE is the only free transaction server that I know of, but you tend to be locked in to the Java space to use it. For example, I don't know what the Linux PHP/C++ et al uses for transaction services, if anything (outside of the DB transactions, of course).
Clearly, the rise of JEE and it's free availability has let the Unix folks handwave this requirement away. "Who needs a transaction monitor outside of the DB anyway?"
I don't think you can make an "enterprise app" "for free" on Linux today, unless you go the Java route. Can MySql or Postgres even work with another Transaction Monitor? Or is it all done within the JDBC drivers?
Shame really, the Unix model has a lot going for it in other ways.
|
|
|
Message #267965
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: New Article: What is an App Server?
Arguably, the need for a JEE application server came about in order to maintain some ability to abstract the application away from the underlying OS and its services. The write-once, run-anywhere mantra required this. In reality, many application servers offered proprietary extensions to feature standards that led to the need to configure applications for a specific app server. When will the madness end?
|
|
|
Message #267968
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: New Article: What is an App Server?
Arguably, the need for a JEE application server came about in order to maintain some ability to abstract the application away from the underlying OS and its services. The write-once, run-anywhere mantra required this. In reality, many application servers offered proprietary extensions to feature standards that led to the need to configure applications for a specific app server. When will the madness end?
I'm not sure it ever will. Before J2EE, CORBA promised more portability and interoperability than was ever delivered. One CORBA object in one product could call the other as a client, but never as a full peer. Transactions could not flow across products from different vendors. J2EE has similar problems. Unless you are very very careful, it is very easy to entangle your application with code proprietary and unique to a specific app server. There is too much financial incentive for leading commercial vendors not to allow too much portability or interoperability. NIH egotism also gets in the way for vendors at all positions in the food chain. Besides, it is difficult to write an airtight spec of any complexity and there is always the desire to "innovate" on the implementation.
What we've achieved is mostly some skills portability at the developer level.
|
|
|
Message #267973
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
What does an app server do, anyway?
So, we have several terms on our plate to push around with a fork here and stare at until they get cold:
1) <something> Server:
- App: for J2EE applications
- Transaction: Tuxedo, etc.
- Web: static web pages and CGI apps
- your own variation
This seems to relate to two aspects: it's a container of containers, and provides bootstrap functionality. Or, it's just a stand-alone application that services client requests.
2) <something> Container:
- Servlet
- Security
- JMS
- EJB
- etc.
Provides an execution context for a specific non-functional aspect of an application. Sometimes I call the Spring Context a "Spring Container", because of all the services it provides. But often a "container" uses the Hollywood Principle of "don't call us, we'll call you."
3) <something> Middleware:
- Message-oriented: does messaging, not necessarily JMS
- <blank>: more generic version of an App Server, I guess
This seems to be the most generic of terms, although it does seem to squarely place the execution context somewhere between the client and a datastore or something else. Maybe not so accurate in a P2P or grid/cloud situation.
What do we call software that helps you run a grid application? A grid server? Does it have a grid container? Could it possibly be a "grid app server"? Yuck. What is the OSGi harness? (harness? THAT's a term I skipped over) Is it an OSGi server, or a container within an app server?
I'm ok with letting the people building these things figure out their terminology. To me, an app server has to, at a minimum, support Java EE, and be able to bootstrap the application. Otherwise, it's a <something else> Server. If it's a piece that gets plugged into a <something> Server, then I'm happy calling that a "Container".
Now pass me the creamed corn...
|
|
|
Message #267978
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
App Servers as a Java Operating System
What's currently lacking with App Servers (the ones I know...) is that they use a Java VM that doesn't provide all the security and management features a current operating system is supposed to have. Some companies have already realized, that a VM intended to play applets in a browser might not fit a huge server installation. But in my view we are still far away from all the features a real OS provides.
Why not having:
* separate memory areas for every user and application
-> to know how much they are consuming
-> to restrict the max memory per user/app
-> memory protection between unrelated classloaders
* better thread management
-> to restrict the max CPU time given to a single thread or user
-> to kill threads (giving info on user, app, mem & cpu usage)
Why not making some API of JEE dealing with such low level VM stuff?
Those vendors that have their own VM can implement the features (and the API), while on the standard VM it just gives you the info available.
|
|
|
Message #267981
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: New Article: What is an App Server?
One CORBA object in one product could call the other as a client, but never as a full peer.
Why ? What do you mean with that (full peer) ?
Transactions could not flow across products from different vendors.
Hmm, OMG defined a standard context id to propagate transaction.
Maybe you mean that this level of interoperability was never achieved by vendors.
But this is related to
There is too much financial incentive for leading commercial vendors not to allow too much portability or interoperability.
rather than the OTS spec strictly.
J2EE has similar problems.
for the same reason, obviously :)
Guido
|
|
|
Message #267984
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: New Article: What is a Transaction Server?
The key one, of course, is the transaction server: CICS, Tuxedo, MTS.
I heard of Tuxedo before, never heard of these other two before
Look at Windows today. The OS is the App Server. You don't get transaction services in .NET, for example, it leverages MTS that is already available.
How do developers use the MTS services? .Net API?
JEE is the only free transaction server that I know of, but you tend to be locked in to the Java space to use it. For example, I don't know what the Linux PHP/C++ et al uses for transaction services, if anything (outside of the DB transactions, of course).
Well, I only heard on the term transaction within the context of RDBMS, a transaction is a group of SQl statement, who act as one, so there are either committed all, or none, you can also specify certain data visibility rule for this transaction, for example if the transaction will be serialized and only see committed data etc...
I am also familiar with the term continuation, which might also mean transaction, I dont know! I am not familiar with the term enough explain it in a simple manner thought!
So put it simply, what does a transaction server do?
|
|
|
Message #267985
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: New Article: What is a Transaction Server?
The fact that before today I couldn't imagine that there are people who don't know what Tuxedo, CICS, MTS or a Transaction Manager is, shows that I am getting old and spent far too long time in IT....
However, MTS (Microsoft Transaction Manager) should be known (at least as a name) to anyone who started their IT career before .NET (unless they never developed for windows)
http://www.zois.co.uk/tpm/tuxedo.html gives a brief overview of Tuxedo. Distributed services and transactions is nothing new, so there have been always products around to address these issues but they were always proprietary until J2EE.
|
|
|
Message #267986
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: New Article: What is a Transaction Server?
Should have read the whole post...
"Well, I only heard on the term transaction within the context of RDBMS" - well, you apparently never read the J2EE specification.
The concept of transactions existed long before the relational database was invented. A transaction can span several sql statements, that is true - but it can also span multiple databases and more importantly, multiple systems which in return may or may not have databases behind them.
In trivial applications the only transaction handling might be on the database level, but in enterprise solutions you usually have a lot of other different systems participating in a single transaction - when I say "enterprise solution" I do NOT mean something "trivial" like a corporate website. I am talking about solutions that integrate dozens of different solutions/services that are often distributed across the globe.
|
|
|
Message #267992
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: New Article: What is a Transaction Server?
Well, I only heard on the term transaction within the context of RDBMS, a transaction is a group of SQl statement, who act as one, so there are either committed all, or none, you can also specify certain data visibility rule for this transaction, for example if the transaction will be serialized and only see committed data etc...
Now simply take that concept to include not just the database, but other systems as well. The concept is the same, but instead of several database calls to the same database, the transaction covers several systems.
Here's a simple scenario that's readily duplicated today in any modern JEE container. Take an item in a database, some row of data, then delete that row, and finally forward that data on to a JMS message queue. You can see the desire that you don't want to actually commit the data being deleted unless you're certain that the message was accepted by the JMS queue. But these are two separate services, so you can't simply rely on the database transaction.
A Transaction Server/Manager lets disparate services participate in a single, global transaction. So, in this case, both the JMS server and the database server coordinate their transactions so that both can commit safely.
The database has been the "transaction hammer" many folks use today, simply because of its ubiquity. JEE makes available a broader scope of transaction behavior to folks, both because it too is now ubiquitous, but also because its now very cheap.
|
|
|
Message #267993
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: New Article: What is a Transaction Server?
Yup, we're getting old. Real old. :-)
As you rightfully point out, application servers and transaction servers have been around for over 30 years, and pre-date RDBMSs, Microsoft, and Java. While I never used them, I'm certainly aware of the important role that CICS, IDMS, IMS, and Tuxedo played in the evolution of enterprise computing.
Now, to be fair, I don't recall the CORBA, JEE, and RDBMS community ever claiming to have invented these things.
If you look at the history of CORBA, it was basically an OO wrapper around RPC, with support for distributed transactions thrown into the mix. What it really lacked was a language independent container model.
JEE provided the container model, but it wasn't language independent. CORBA's CCM tried to fill the void, but it was too little, too late, IMHO. The Enterprise Java spec was an attempt to bring the basic features available in the proprietary application servers (e.g. M3) to the masses in the form of a language specific specification.
I credit JEE with helping make the app server a mainstream concept, at least from the perspective of portability. (90% successful).
Where JEE screwed up was in not adopting an accepted standard for distributed communication: CORBA (Well, accepted by everyone but MS, who were still clinging to COM).
Instead, Sun tried to push Java everywhere with RMI, which wasn't going to fly in the MS camp. (Yes, I know it supported IIOP, but that was an afterthought. How many places have actually used EJBs w/ IIOP?).
Thus, we had no interoperability. Seriously, no enterprise was going to chuck its enterprise systems and rewrite them all in Java just to use EJBs and RMI.
In the end, with no acceptable interoperability, we were led down the dreaded HTTP/XML/SOAP/Web Services path, which was primarily pushed by MS as an alternative to CORBA. Blech.
Mark
|
|
|
Message #268014
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Transactional J2EE without Appserver
The interesting thing is how the App Server has evolved over time. Specifically, the concept that we even NEED an "App Server".
Exactly. In a way, the appserver is to development what the mainframe batch compiler was in the early days of computing: a huge performance killer, with lots of late risks discovered only at deployment time. The same thing happens whenever you have a separation of the development and deployment phases.
Personally, I prefer this: J2EE without application server (disclaimer: I wrote that). Once your code becomes the executable, the typical problems of appserver deployment are avoided (no late risks, most problems are found early during development).
Clearly, the rise of JEE and it's free availability has let the Unix folks handwave this requirement away. "Who needs a transaction monitor outside of the DB anyway?"
More and more people do. Processing messages from JMS queues (event-driven architecture) is a natural use case. SOA and EDA are natural allies for transaction monitors.
|
|
|
Message #268015
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Transactional J2EE without Appserver
The interesting thing is how the App Server has evolved over time. Specifically, the concept that we even NEED an "App Server".
Exactly. In a way, the appserver is to development what the mainframe batch compiler was in the early days of computing: a huge performance killer, with lots of late risks discovered only at deployment time. The same thing happens whenever you have a separation of the development and deployment phases.
Personally, I prefer this: J2EE without application server (disclaimer: I wrote that). Once your code becomes the executable, the typical problems of appserver deployment are avoided (no late risks, most problems are found early during development).
Clearly, the rise of JEE and it's free availability has let the Unix folks handwave this requirement away. "Who needs a transaction monitor outside of the DB anyway?"
More and more people do. Processing messages from JMS queues (event-driven architecture) is a natural use case. SOA and EDA are natural allies for transaction monitors.
Guy, it's an interesting paper -- but you built an application with JMS. The function of an application server is to contain services like JMS; I would say that you haven't eliminated the application server, you've just decided not to use much of one. If you're using an app server like Glassfish, you're not even saving much overhead - Glassfish would start the general appserver services, and then JMS, and... that's it.
What's more, you're bound directly via configuration to ActiveMQ; an application server would abstract your JMS connection (via JNDI) to any JMS container, which means your application (and configuration) no longer know or care what your JMS container is - a good thing, IMO.
It's an interesting paper, but I don't think you've accomplished what you'd set out to accomplish: J2EE without an appserver.
|
|
|
Message #268018
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
What goes around comes around
The interesting thing is how the App Server has evolved over time. Specifically, the concept that we even NEED an "App Server.
Maybe not an App Server but we need the services. And I'd like to have them in a nice, consistent, easy to use manageable way, please. And I'd like to want an application abstraction that makes all that stuff available without too much explicit coding but rather declaratively.
This would include transactions, application containers (like EJBs, Corba Servers...), Resource abstraction (Queues, Database Connections). But just as we get to the point that the average JEE Server actually supplies this, we throw most of stuff away for a more "simple" approach, like, say OSGI.
Reminds me of people saying "We won't need Smalltalk since C is so much simpler", "Hey, let's not spend all the money on VMS, let's get Unix Instead, who will ever need memory protection or file versioning in a multiuser system anyway", "Hey, let's not buy this mainframe that comes equipped with a transaction manager and a proper database, let's buy 10.000 PCs instead and wire them all up, put some databases on a couple of more reliable Unix systems, figure out a cool backup solution and - finally - virtualize all the mess, so it can run on the mainframe we did not buy in the first place, since it is that much SIMPLER".
|
|
|
Message #268020
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
made my day
"Hey, let's not buy this mainframe that comes equipped with a transaction manager and a proper database, let's buy 10.000 PCs instead and wire them all up, put some databases on a couple of more reliable Unix systems, figure out a cool backup solution and - finally - virtualize all the mess, so it can run on the mainframe we did not buy in the first place, since it is that much SIMPLER".
ROFL
|
|
|
Message #268025
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Transactional J2EE without Appserver
Guy, it's an interesting paper -- but you built an application with JMS. The function of an application server is to contain services like JMS; I would say that you haven't eliminated the application server, you've just decided not to use much of one. If you're using an app server like Glassfish, you're not even saving much overhead - Glassfish would start the general appserver services, and then JMS, and... that's it.
What's more, you're bound directly via configuration to ActiveMQ; an application server would abstract your JMS connection (via JNDI) to any JMS container, which means your application (and configuration) no longer know or care what your JMS container is - a good thing, IMO.
It's an interesting paper, but I don't think you've accomplished what you'd set out to accomplish: J2EE without an appserver.
I'm currently developing systems using an architecture where we use no app server and use the messaging infrastructure to manage our applications. We have no continually running applications for this architecture.
As messages show up on queues, the queuing infrastructure will start an application as needed. When there are no more messages, the application shuts down. This provides a lot of flexibility, robustness and scalability. I don't worry much about heap sizes, slow memory leaks or how I will affect configuration changes.
It's not a good design for synchronous work because of the overhead of starting up the application but for asynchronous stuff it saves me a lot of hassles and headaches and the throughput is much higher than what we have been able to achieve with app servers solutions on the same (and better) hardware partly because it allows for single-threaded applications which have particular benefits on the target platform.
|
|
|
Message #268031
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: New Article: What is an App Server?
Transactions could not flow across products from different vendors. J2EE has similar problems.
Maybe I'm missing your point, but the Java EE specs. mandate the CORBA / IIOP, OTS, INS, and SOAP / WS-* standards to get the very interoperability you claim EE does not provide. I remember very early days in J2EE where we had a connectathon to get that initial interop addressed. Now it's pretty much mandated.
Unless you are very very careful, it is very easy to entangle your application with code proprietary and unique to a specific app server. There is too much financial incentive for leading commercial vendors not to allow too much portability or interoperability. NIH egotism also gets in the way for vendors at all positions in the food chain.
Give me a break. You think customers will buy a product their .NET clients can't interoperate with? Where's the financial incentive for a vendor to prevent that? What about businesses implementing business processes that must interoperate with their business partners (e.g. supply chain). You think a company will survive if it mandates that all it's partners must run the exact same software as they do? How about ISVs that need to implement a solution that works on their customer's IT environment regardless of whether it's WebSphere, WebLogic, or whatever? Will they survive if they have to build a unique solution for every IT environment?
The issue is not that vendors are purposely trying to cause vendor lockin. The issue is that customers need more than what the standards provide. Standards are always "behind the times". It's the nature of being a standard. Pick whichever "app server" you want to pick. Every single one will offer more than a particular standard or specification requires. It doesn't matter if it comes from a vendor or open source. The nature of the business says that if your customers / community needs something, either you provide it or risk losing that customer or portion of the community. If it happens to be standardized at a later date, so be it.
|
|
|
Message #268033
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: New Article: What is a Transaction Server?
Where JEE screwed up was in not adopting an accepted standard for distributed communication: CORBA (Well, accepted by everyone but MS, who were still clinging to COM).
Instead, Sun tried to push Java everywhere with RMI, which wasn't going to fly in the MS camp. (Yes, I know it supported IIOP, but that was an afterthought. How many places have actually used EJBs w/ IIOP?).
Um, all our (WebSphere) customers do and a significant number are using CORBA clients to access EJBs including some using COM bridges. The only thing wrong with this pattern is using it across firewalls.
Thus, we had no interoperability. Seriously, no enterprise was going to chuck its enterprise systems and rewrite them all in Java just to use EJBs and RMI.
In the end, with no acceptable interoperability, we were led down the dreaded HTTP/XML/SOAP/Web Services path, which was primarily pushed by MS as an alternative to CORBA. Blech.
It's a pretty sweeping claim to say we had no interoperability. The EE platform has interop for anyone that cares about it and it doesn't require rewriting in EJBs to get there. In my opinion, interop is not what drove the SOAP stack (it has more problems with interop than IIOP does). The SOAP stack was driven by a couple of problems:
1) managing access across firewalls
2) handling evolution of request processing compatibility
The last is not a multi-vendor interop statement. It's a statement that says it's difficult to evolve clients and servers independently using the technologies we've had in the past and given the explosion in the number of clients in the past 10 years or so, it's a problem that was growing in complexity.
|
|
|
Message #268034
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Clarification
If you're using an app server like Glassfish, you're not even saving much overhead - Glassfish would start the general appserver services, and then JMS, and... that's it.
Maybe I didn't make the point clear enough: the only model that works to improve productivity is to include ALL jars/libraries/classes into development already. This means that all software has to run from within the IDE or local build environment. Specifically, any container-based model (be it appserver or other) that does NOT allow for embedding is a pain IMHO. Whether or not Glassfish allows this I honestly don't know (and frankly I don't care any more).
More precisely, I consider doomed any deployment model that generates/interprets XML to add either logic or mappings after (and in a manner different from) the development phase.
What's more, you're bound directly via configuration to ActiveMQ;
Not really - what makes you think so? The model presented in the paper is completely JMS provider agnostic - thanks to Spring IoC I should say. It is also agnostic about the database thanks to JDBC/Hibernate.
It's an interesting paper, but I don't think you've accomplished what you'd set out to accomplish: J2EE without an appserver.
If you need HTML serving then you need an embedded servlet engine like Jetty/Webtide (or Tomcat if you like). Besides that, I personally expect that the appserver will mostly disappear in 5 years; IMHO most of the business logic and services will be implemented as SOA/EDA ("reuse in place") with JMS as one of the major protocols.
So: if you mean servlets/JSP then we didn't eliminate that (no need to). Otherwise, I think the light-weight Java movement (including Spring/Hibernate and Atomikos) is on its way towards a bright future.
|
|
|
Message #268035
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: New Article: What is an App Server?
Transactions could not flow across products from different vendors. J2EE has similar problems.
Maybe I'm missing your point, but the Java EE specs. mandate the CORBA / IIOP, OTS, INS, and SOAP / WS-* standards to get the very interoperability you claim EE does not provide.
Maybe you don’t know what is meant by “flowing a transaction”. OTS was supposed to be able to manage a transaction in which CORBA objects hosted in CORBA servers from any arbitrary combination of vendors could participate in. In other words, the commit or rollback automatically applied to all the objects regardless of which product hosted them. That was never implemented by the vendors. They supported only a client/server relationship where a CORBA object in, for example, IBM’s Component Broker, could use IIOP to connect to and interact with a CORBA object on IONA’s broker, but only as a client. The context for any transaction you began in Component Broker would not flow to Iona. You had to write your own logic to make that happen. The same is true with Java EE. JTS does not work across application servers from different vendors.
Unless you are very very careful, it is very easy to entangle your application with code proprietary and unique to a specific app server. There is too much financial incentive for leading commercial vendors not to allow too much portability or interoperability. NIH egotism also gets in the way for vendors at all positions in the food chain.
Give me a break. You think customers will buy a product their .NET clients can't interoperate with? Where's the financial incentive for a vendor to prevent that?
You are confusing a basic level of interoperability with advanced levels that include the integration of services such as what vendors were promising for CORBA and Java EE, but have never delivered. Sure, I can call one from the other. I can send messages, requests and responses between them. The market demands that. However, my code is not 100% portable between two commercial application servers. My container services do not communicate across application servers from different vendors. My administration is different, etc.
Companies have a financial incentive not to go too far with standards. The bigger and more dominant the company, the greater the incentive to “innovate” or augment the standard in some way. They call it “differentiation”. Vendors talk about adherence to open standards, etc., but why would you pay $17,000 or $40,000 per CPU for a license for something you can get for free? Why pay $4000 per seat for Rational development tools when there are free and cheap ones that are as good or better? If everything was so compatible that it was interchangeable, they couldn’t sell as many licenses.
|
|
|
Message #268036
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: New Article: What is a Transaction Server?
Where JEE screwed up was in not adopting an accepted standard for distributed communication: CORBA (Well, accepted by everyone but MS, who were still clinging to COM).
Instead, Sun tried to push Java everywhere with RMI, which wasn't going to fly in the MS camp. (Yes, I know it supported IIOP, but that was an afterthought. How many places have actually used EJBs w/ IIOP?).
Um, all our (WebSphere) customers do and a significant number are using CORBA clients to access EJBs including some using COM bridges. The only thing wrong with this pattern is using it across firewalls.
Thus, we had no interoperability. Seriously, no enterprise was going to chuck its enterprise systems and rewrite them all in Java just to use EJBs and RMI.
In the end, with no acceptable interoperability, we were led down the dreaded HTTP/XML/SOAP/Web Services path, which was primarily pushed by MS as an alternative to CORBA. Blech.
It's a pretty sweeping claim to say we had no interoperability. The EE platform has interop for anyone that cares about it and it doesn't require rewriting in EJBs to get there. In my opinion, interop is not what drove the SOAP stack (it has more problems with interop than IIOP does). The SOAP stack was driven by a couple of problems:
1) managing access across firewalls
2) handling evolution of request processing compatibility
The last is not a multi-vendor interop statement. It's a statement that says it's difficult to evolve clients and servers independently using the technologies we've had in the past and given the explosion in the number of clients in the past 10 years or so, it's a problem that was growing in complexity.
OK, I was somewhat joking about the IIOP/EJB thing. I know it can be done, and is done. But generally speaking, IIOP support was added to J2EE as an afterthought, and it's quite rare to find it in actual use. I don't believe IIOP was defined in version 1.0 of the spec.
Yes, I agree that the OMG dropped the ball on the firewall issue. However, tunneling through port 80 via HTTP is not a real solution to the problem, now is it?
As for evolution of the request processing, this isn't solved by SOAP. We've been evolving our IDL interfaces for close to 10 years with little difficulty. Yes, there may be a few types of changes that are easier to do with XML, but it doesn't handle every possible scenario. In the end, the adage "don't change an interface, create a new one" pretty much handles everything.
The way I see it, in the late 90's MS was scared by Java, as its write-once, run-anywhere philosophy threatened the MS OS money tree. MS's counter to Java was that Sun was trying to force a single language on everyone, whereas they allowed you to pick your language, and interoperate via COM. Of course, it more-or-less was limited to Windows only.
Sun gave us OS independence, but at the cost of language selection. Interoperability in JEE was 2nd class.
Thus, MS saw XML/HTTP/SOAP as a way to counter RMI. Of course, all these things are protocols, and not containers. It turns out that JEE is a decent way to implement the Web Services.
On top of that, MS didn't have a viable app server ready to sell, as .Net was a few years away. This gave the JEE vendors plenty of time to hop on the web services bandwagon.
Again, I feel that if Sun had adopted CORBA from the beginning as the basis for its distributed model, and focused on a) the internals of the app server, and b) fixing the things in CORBA that needed fixing, we wouldn't have spent the past 8+ years reinventing the wheel with "Web Services".
It's funny, but in 1997 Netscape was visionary enough to embed the first Java ORB inside their web browser. They realized that the future of the web was not going to be limited to HTTP/HTML. Instead, users would download "rich" clients, i.e. Java applets, and the applications would use IIOP (Internet Inter-Operable Protocol :-) to communicate across the internet with various CORBA-based services.
Of course, MS more-or-less destroyed Java on the desktop and in the browser by hijacking it, so applets faded away. However, the desire for rich clients never went away, and today we have Flash, AJAX, and a host of contenders in the browser.
Mark
|
|
|
Message #269713
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Web Services Application Server?
Traditionally, app server meant J2EE app server. This notion has been changing since lately. Like it was mentioned, more and more people agree that "an application server provides an environment where applications can run, no matter what the applications are or what they do". Such an environment generally should provide the infrastructure for security, transactions, reliability & scalability. WSO2 Web Services Application Server (WSAS) is a good example for such an environment, even though it is not a "traditional" app server. It is an app server for Web service applications, is devoid of any J2EE baggage (overhead) & treats Web services as "first class citizens". It embeds Apache Axis2. The interesting thing is, it supports not only Java Web services, but logic written in a variety of scripting languages & even rules (as in Rules Engines) & shell scripts can be deployed as Web service applications on WSAS. Therefore, clearly, the words "App Server" have not been limited to Java hosting environments. High availability & scalability have been provided through an Apache Tribes based clustering implementation. Also there is ongoing work in making WSAS autoscale on Amazon EC2. In such a deployment, the number of instances running identical pieces of the app server grow & shrink based on the actual load experienced by the system.
For more details on how a Web Services App Server can fit into an enterprise deployment architecture, see Where does WSAS fit into your enterprise deployment?
Afkham Azeez
|
|
|
Message #271808
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
You said it!
100% agree with your starting point...ie ..the operating system WAS the App Server. Indeed. When you go back to the 60s and 70s, if we write a Genesis of online applications..things will be clearer and simpler. Let's start.
In the beginning there was only batch programming! One program at a time. Then there was interactive programming. HP calculators supporting Basic code was amazing compared to card reader based huge IBM 370s. Well let's jump. Oen could run oonline applications under the operating system. IBM departed from this when they gave CICS (IMS-DC too was there). CICS in a way masked the operating system from you! One talked about CICS COBOL (online) code, maps and interactions, terminals etc Not bothered about the OS (MVS or DOS/VSE) - CICS code was more or less the same.
Even here database support was separate though in a way integrated with CICS. So DL1 COBOL code ran in CICS. (I am sure Unix modern guys might be wondering...what I am talking about!) IBM mainframe saw powerful environments from 3rd parties like IDMS DB/DC which supported 100% online and database applications, where one could almost forget the OS features or code or JCL! These were the thru application servers! Some terminology classified CICS and IDMS-DC as mini-operating systems within the OS because they had all the features of an OS (multitasking, timeslicing, storage and memory management, dispatching of tasks, interrupt handling, and own terminal management ...)
But in the modern world, client server simplified or complicated things, depending upon how you look at it. Server handled the db. windows became the client. There indeed was nothing like an application server. ie the application code ran on different 'client' machines. The server basically handled the database locking and update.
Well, Java changed the things again. Where do you run the Java code? You can run it similar to the above..On your client side ... but soon it was clear that this was not enough. Application servers like Websphere and Weblogic were born. Java applications needed this. Web too required a central server. JSP, Servlet etc necessitated such a server. Basically for old mainframe person, this was re-inventing the wheel! Weblogic, Tomcat, Websphere etc effectively take the spot occupied previously by CICS or IDMS-DC on IBM/370.
But Java guys didn't stop there. Our people have complicated things with jargons and buzzwords. JDBC, JMS and even MQ are only mechanisms which should have been anyway part of an application server.
Recently a Java seminar had a presentation which claimed "the application server is dead"! Also this article wondering what an application server is, raises serious questions about the understanding of transaction processing, in the modern world - even among the experts!!!
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
