Paul Done

Tim had a good point - by offering one vendor platforms these platforms are starting to become commodities - one vendor cannot differentiate their solution sufficiently from another vendor's solution - customers begin to assume that the platform is a given, and the price is forced down. Pretty soon these vendors will have to look at other ways to differentiate their solutions and may begin to look at providing vertical applications (eg. for the Oil industry) and/or horizontal applications(eg. Human Resources) which run ontop of these platforms.
Some vendors already provide vertical and horizontal apps (eg. 'Oracle Financials') but in most cases these are built on old proprietry technology and don't run on their own new flagship platform. eg. Oracle Financials runs on old Developer/2000 (SQL*Forms) technology which is based on PL/SQL and a fat-client/server model, and would have to be completely re-written to run on Oracle's 9i platform.
Whatever happened to IBM's Java based 'San Francisco' project - this was supposed to be a framework and set of Business Components for horizontal applications but in the last few years I've heard nothing about it?
http://www-3.ibm.com/software/ad/sanfrancisco/
Paul

And this is no different for any of the other vendors discussed - this is exactly my point - they all have an umbrella of their own re-branded pre-existing products that they have maybe added a bit more glue to, some maketing story and maybe a cohesive look and feel - they are all claiming to be one vendor solutions. Apart from where highlighted in my previous mail - all the parts of the platform are their own.
Another part of a typical platform I forgot to mention is the Directory Server (eg. for LDAP, etc).
Paul
[ January 19, 2003: Message edited by: Paul Done ]

Many vendors are now making the platform play, having originally come at it from different angles...
eg. Microsoft .NET, Sun ONE, IBM WebSphere, Oracle 9i, Novell One NET.
All have their own O.S. (except Oracle), D.B. (except Sun and Novell), V.M., App Server, IDE, Integration Server and Messaging System, which are now bundled up and marketed under one 'integrated' platform umbrella.
Invariably there's also lots of other stuff in there too such as Portal Frameworks and various other middleware.
Currently each vendor can probably be differentiated by having a slightly different perspective on the 'platform'. Microsoft's slant is probably 'easy-to-use' development tools, IBM's is probably more runtime stability, Sun's slant is 'standards setter', Oracle's is data/information delivery, and Novell's is security/identity.
BEA could probably be included with their Weblogic platform, except they don't have either an O.S. nor a database of their own.
Now the real question is just how integrated the platform is, or is it just a re-branding of different products. Microsoft are as guilty of this as any of the other vendors in the list. .NET actually uses many different pre-existing products such as IIS, MSMQ, MTS, SQL Server, BizTalk, etc..
Paul
[ January 18, 2003: Message edited by: Paul Done ]

This Sun tutorial may help...
http://java.sun.com/docs/books/tutorial/jar/basics/manifest.html
Basically the inclusion of the manifest.mf file is optional depending on what you are try to do. However, many packaging tools often generate one anyway. It can be used for securing a jar, specifying class path dependencies of the jar's contents, specifying the default main class to be able to start the jar app with the command 'java -jar myapp.jar', and other things.
Paul
[ January 16, 2003: Message edited by: Paul Done ]

Also see this topic which talks about accessing mainframes from J2EE....
https://coderanch.com/t/209092/java/java/Java-MainFrame-communication
Also, most J2EE app servers can run on AIX and all have access to DB2 via the JDBC API and DB2's database driver.
Paul

One of the sorts of questions which is probably going to get more opinions than facts. I've done some Perl CGI and J2EE development in the past - so here's my opinions...
J2EE Pros / Perl Cons
---------------------
- Java is a more regimented and elegant programing language where with Perl there is always a '1000' different ways to do the same thing and Perl's syntax can often be a little obtuse. This means that for inexeperienced developers, Java is probably a safer language to use and easier to learn. This does NOT mean that you can't do certain things in Java which you can in Perl; Java now supports Regular Expressions in its standard API, for instance.
- If you are a fan of objected oriented development then Java is the better choise because it is completely object oriented. Perl can be used in an object oriented manner but OO is a lot less natural to it. This also helps if you are using something like UML in you design phase because your diagrams/models will be easier to map to Java constructs than Perl ones.
- J2EE has a very large standardised and rich set of enterprise APIs for accessing databases, Mail, legacy and enterprise information systems, message oriented middleware, and services such as server side security and transactions. Its possible to do a lot of this in Perl, but much of it is non-standardised.
- J2EE has a specific component model for server side programming (eg. servlets & JSPs, EJBs) which is targetted at providing presentation and business logic/integration services specifically.
- Another argument used to be that J2EE was more performant/scalable due to its multi-threaded support whereas typically a native O.S. process was spawned for every request to a Perl script on a web server. However I am not sure whether this is still an argument as things may have improved for Perl and its various Web Server plugins / integration modules since I last used it (Apache for instance).
- In my experience, there are more developers available for recruitment with good 'server-side' J2EE experience than good 'server-side' Perl experience.
Perl Pros / J2EE Cons
---------------------
- You have to run J2EE applications in a J2EE compliant application server, where as most types of Web Servers out there provide support for Perl plugins. That said - it is possible to plug something like Tomcat into IIS.
- Perl is perhaps a bit easier to quickly put together simple dynamicically generated web pages - its maybe a little easier for prototyping your app.
Hope this helps
Paul
[ January 16, 2003: Message edited by: Paul Done ]

JCA (Java Connector Architecture) and MDB (Message Driven Bean) are completely different things but they can be complementary. You use MDB to listen on a queue or a topic for messages which may be sent to the message oriented middleware by another application. This MDB can then use any of the Java or J2EE APIs (with only a few restrictions which apply to EJBs in general). These APIs could include JDBC for database access, JavaMail for sending emails, etc. Another one of the APIs that the MDB may choose to use is JCA. This is an API and connector architecture to enable J2EE application to access enterprise information and legacy systems (eg. SAP, Peoplesoft, Mainframe systems, etc). However to access a particular legacy system requires a suitable JCA connector (similar in concept to a JDBC driver) to be available for that particular system.
MDBs are often used to enable asynchronous processing. ie. A client can send some information (a message) to another system (eg. J2EE app server) via a queue or topic and continue doing its own work without having to wait for a response. The target app server's MDBs can then choose to process the message in its own time. This is also a good architecture for helping eliminate some single points of failure in your distributed system, where parts of the system may be prone to failure, reboots, etc..
The confusion you may be having is that a newer version of the JCA specification is also likely to support asynchronous processing by back end systems, but this is not part of a finalised J2EE standard yet.
Hope this helps
Paul

If you mean 'can the output of one servlet be included in the output of another servlet?' then the answer is yes. Like JSPs, your servlet can do a 'request dispatch include' to include the output of another servlet. Check the javadoc for ServletContext.getRequestDispatcher().
Paul

You could follow the example set by the Struts framework with its 'html:errors' tag library tag. Throughout your application you could use the convention of putting warnings into a request atrribute called 'warnings' for example. Then in each JSP, in the place where you would like to show warning messages, use your new tag library tag 'mytags:warnings' which looks at the request 'warning' attribute and prints out its contents into the page, if any exist (if none exist, your tag will output nothing and the page will have no warnings on it).
You could then extend this to enable warning messages to be grouped (eg. 'line item warning', 'page warning', etc) and scoped (eg. page, request, session, application) a bit like Struts can for 'errors'. This would enable you to display different types of warnings in different parts of the JSP page, only when they exist.
Paul
[ January 12, 2003: Message edited by: Paul Done ]

Typcially an application server maintains a HTTP thread pool to service the incoming HTTP servlet requests. On server start-up (or on first request depending on vendor), the single shared instance of the servlet is created. Each of the threads can call the service() method of the shared instance of the servlet. The service() (and do*()) methods are multi-threaded by default, therefore you have to be careful to synchronise the usage of members variables and other shared objects which are accessible from the servlet's methods. Many threads can be running in the same method instance.
The exception to this is if your servlet implements the SingleThreadModel marker interface. In these situations the server creates and executes an instance of the servlet object for each user agent session/request (note: some vendors use a pool of servlet instances to reduced memory footprint). In such cases only one thread ever runs in each instance of the servlet service() method at a time.
The server tracks a user's session by using a special JSESSIONID browser cookie or by using URL re-writing (by including a jsessionid parameter on each server url given to the browser in a html page).
Paul
[ January 09, 2003: Message edited by: Paul Done ]

There are various J2EE oriented integration products out there which can integrate with legacy mainframe systems/programs and expose these functions as Web Services, JCA, etc.. (for example: the Composer product from Novell).
Here's a few ways these products integrate with mainframes:

3270 Screen Scraping - the integration tool simulates a real user by interacting with the system at the screen level and 'scrapes' the results. Not as ideal as going into the system at the business transaction level but often is the only way.

CICS-RPC - If the logic is in a CICS managed transaction processing environment. This uses CICS's External Call Interface, often through IBM's CICS Java gateway. This is more ideal than screen scrapping because integration occurs at the business logic level.

As mentioned before you may be able to use JMS to integrate with MQSeries which in turn may integrate with the mainframe programs. Again, this is a good option because it operates at the business logic level and also it may provide some extra fault tolerance and resilience if the mainframe goes down for a period, for instance.

Hope this helps
Paul

Also take a look at the Value List Handler pattern from Sun's J2EE Core Design Patterns. This can be used together with the Primary Key query approach to enable lazy loading of pages of data, with forward, back buttons, etc.. I would minimise the usage of a ResultSet and never hold onto it longer that the initial JDBC queries.
Paul
[ January 09, 2003: Message edited by: Paul Done ]

If you have the remote client's IP address, could you not use InetAddress.getByAddress(ip) and then call getHostName() on the result? However this may try to do a reverse DNS lookup - if that fails then there is probably no way to get the remote clients' name - in fact the remote client may not have a public name at all?
Paul

Unfortunately I don't have the orginal buildscripts at hand - this was done for a customer last year - however I have found the XSL which I called from the XLS/Style ant task in the master buildfile - not sure if this is any help?....
<!DOCTYPE stylesheet [ <!ENTITY dollar "$" ><!-- dollar-sign --> <!ENTITY lbrace "{" ><!-- left-brace --> <!ENTITY rbrace "}" ><!-- right-brace --> ]> <xsl:stylesheet version = '1.0' xmlns:xsl='http://www.w3.org/1999/XSL/Transform'> <xsl :-o utput indent="yes" method="xml"/> <xsl:template match="*|text()|@*"/> <xsl:template match="/dynamic-projects"> <project name="GeneratedPortalMerge" default="package"> <target name="init" unless="TSTAMP"> <tstamp/> <echo>Build of ${ant.project.name} started at ${TSTAMP} on ${TODAY}</echo> </target> <target name="package" depends="init"> <echo>Running ${ant.project.name} to generate super portal war from seperate portal subprojects</echo> <xsl:apply-templates select="project"/> </target> <target name="clean" depends="init"> <xsl:apply-templates select="project"/> </target> </project> </xsl:template> <xsl:template match="project[@type='web']"> <xsl:element name="ant"> <xsl:attribute name="dir">../<xsl:value-of select="."/></xsl:attribute> <xsl:attribute name="target">${subproject.target}</xsl:attribute> </xsl:element> </xsl:template> </xsl:stylesheet>
...which generated the buildfile....
<?xml version="1.0" encoding="UTF-8"?> <project default="package" name="GeneratedPortalMerge"> <target unless="TSTAMP" name="init"> <tstamp/> <echo>Build of ${ant.project.name} started at ${TSTAMP} on ${TODAY}</echo> </target> <target depends="init" name="package"> <echo>Running ${ant.project.name} to generate super portal war from seperate portal subprojects</echo> <ant dir="../DirectorWebProj1" target="${subproject.target}"/> <ant dir="../DirectorWebProj2" target="${subproject.target}"/> <ant dir="../DirectorWebProj3" target="${subproject.target}"/> </target> <target depends="init" name="clean"> <ant dir="../DirectorWebProj1" target="${subproject.target}"/> <ant dir="../DirectorWebProj2" target="${subproject.target}"/> <ant dir="../DirectorWebProj3" target="${subproject.target}"/> </target> </project>
Not sure if this helps because its very specific to the problem at the time. Basically I was creating a large WAR web component from lots of smaller ones developed by different developers in source control. Each sub project had its own buildfile, but there was not way to automate the build of the master web component from these smaller web components until I used this method (a single web component was required for production, rather than an EAR containing multiple WARs, because the servlet context needed to be shared). In fact, this example didn't use a deployment descriptor as input to the XSL, it used a custom XML config file that was also source controlled - but the principle is the same.
Paul

I prefer to use JMS rather than spawning my own threads to achieve asychronous processing. From the servlet (or a filter if you want to seperate out concerns fully) I would use JMS to put the mail information into a message and onto a queue, before processing the rest of the servlet. Create a seperate Message Driven Bean which listens to this queue and processes the messages in its own time, using Java Mail.
Paul