By Frank Cohen
Day 1
Last week I met a managing director for a Tanzanian bank that makes microfinance loans. These are very small loans to entrepreneurs, frequently less than $100. The bank executive made a decision to buy a Java-based software package for $250,000 to handle server-side and client interfaces to the banking management functions. Unfortunately the bank spent another $250,000 on a Java engineer to make the system output the reports they need and integrate with existing bank IT systems. Today at JavaOne I really want to learn about new Java technology and patterns that reduce integration costs.
I sought out enterprise tools and technology supporting SCA, JBI, and enterprise interoperability. Here is what I found.
ActiveMatrix, the first shipping commercial SCA/JBI
Tibco demonstrated ActiveMatrix 1.0. The new product is already in use at Delta Airlines. ActiveMatrix provides a message-based infrastructure and component model to let Java developers write EJB components that are plugged into its message infrastructure. The SCA architecture handles deployment and makes it easy to move a component from one server to another. I wrote a white paper introducing Java developers to the idea of service virtualization earlier this year. Virtualizing the runtime environment makes it easier to govern the applications and to recover from the inevitable operating problems.
Update From Sun on JBI and SCA
I sat down for a conversation with Jim McHugh, VP of Software Infrastructure Marketing at Sun, and Kevin Schmidt, Director of Product Management for SOA/Business Integration at Sun. Kevin came to Sun from SeeBeyond and did most of the talking, and Jim did most of the nodding.
Kevin gave me an update on the JBI efforts at Sun. OpenESB is Sun's reference implementation of JBI. Sun announced JBI 2.0 this week and had its first meeting of the JSR 312 expert group here at the conference. JSR 312 primarily adds better deployment and manageability and makes JBI more complimentary to SCA. Kevin told me OpenESB is more than a Sun initiative in that its open-source community has participation from Imola Informatica and Bostech.
TheServerSide.com attendees who attended the recent Java Symposium may remember Ross Mason, CTO for Mulesource.com, saying Mule is unsupportive of JBI because JBI solves a subset problems for integration application development while Mule solves problems at the messaging level. In Ross' opinion, JBI attempts to standardize a solution to integration solutions, where from Mule's experience, enterprise customers have different and unique needs. Ross stated that Mule will not standardize and provide Mule as a JBI container.
However, Ross did see promise in SCA, which is a way to wire services together in a uniform way. Mason said SCA is a good fit for Mule and that there are plans for Mule configuration to use SCA configuration. Mule is talking with the Tuscany folks to make this happen.
From Kevin's perspective "this is not a JBI versus SCA issue. SCA is more about component metadata and JBI can be the runtime." Sun is a proponent of SCA, joined the SCA group last year, and is participating in its transition to the OASIS standards body. Kevin pointed to proponents of JBI, including IONA, Logicblaze, Tibco, and Sun with its Java Composite Application Suite (JavaCAPS.) Eric Smith, a software architect consultant to Boeing, seems to agree. Eric told me Boeing is specifically looking for JBI solutions to provide portability and avoid vendor lock-in from other ESB-like solutions.
Kevin talked about Sun's efforts to provide application server, identity products, and support for Spring in the OpenESB project. Sun is looking into creating a Spring Service Engine that allows developers to write Plain Old Java Objects (POJOS) with Spring and have them integrated into a JBI container automatically. When I asked him how they will decide on this Spring integration, Kevin said "it's up to the community." Kevin also said the original developer from the JSR 208 reference implementation is working on a special compatibility test (TCK) for JBI applications.
I floated the idea of Sun making a future version of EJB a JBI container. Kevin pointed me at the Java EE Service Engine. He said it enables you to interact with EJBs from JBI in a "very native way".
When I told my experience with the Tanzanian bank Kevin said sympathetically, "historically Java development has not been cheap or easy. We believe we need to make development easier. Integration technologies provide visual tools in NetBeans to orchestrate services and enabled Java to do integration easily, cheaply, and efficiently."
This seems to sum-up where JBI stands today.
Virtualization For Service Deployment Infrastructure
A few developers at JavaOne asked me about using platform virtualization technology to deploy SOA services. Virtualization platforms from Microsoft for Windows, replicate for Windows, and Sun for Solaris let you slice a server into multiple running instances of an operating system. For example, on a multi-CPU Intel Dual Core platform you run what looks like 3 copies of Windows, with the underlying virtualization platform taking care of timeshare slicing the CPUs to service the running applications. I found an emerging train-of-thought here on using virtualization platforms to deploy an SOA infrastructure to run services.
Many people I met at JavaOne are being asked by their organizations to evaluate and make decisions on infrastructure and tools to host composite applications and data services. Every data center I have seen already has facilities to run Web-browser-based applications in what Chris Richardson coined as the Domain Model. The other popular models (ESB model and Web 2.0/Ajax model) deploy services that use XML data for interoperability. My research shows that using the Domain Model for XML-centric applications is not scalable, nor flexible enough for the average company. That's driving enterprises to consider the alternatives:
1) Domain Model – servlets, Web containers (Spring and EJB) model/view/controller, and relational database.
2) ESB Model – write a service and plug it into the bus, the bus handles communication (messaging) to other services on the bus
3) Virtualization Model – run as many copies of the application server as you will and let the virtualization environment worry about load balancing between the underlying CPUs and hardware.
4) Web 2.0/Ajax Model – services speak multiple protocols to multiple backend systems to deliver a rich user experience and highly functional application.
In my experience it is very easy for these platforms to look equal when evaluated, if the use case is written incorrectly. For example, one would realize no difference if a test that favored the domain model architecture is used in an ESB model. This is challenging developers to find new ways to design and build tests to evaluate these models.
Rohit Valia of the network.com group at Sun told me about Sun's utility computing service. The network.com service is a large scale datacenter available for you to run applications by the hour. You actually pay for CPU Hours using PayPal! The datacenter is stocked with hundreds of Sun servers running Solaris N with X64. Sun announced at JavaOne a network.com plug-in for NetBeans to submit applications and data directly. You execute your application as a user and the environment is managed by the Sun Grid Engine. Sun also announced access from 24 countries (formerly US only) and announced APIs to embed into your application so you can send a job to the grid. Sun is offering the first 200 CPU hours with 10 Gbytes of storage free with each new account. The datacenter is in Nevada and Sun charges $1 per CPU Hour.
DWR 2.0 for AJAX
I met Joe Walker of the DWR project hanging around the Tibco booth. He recently shipped DWR 2.0 and looked pretty tired. DWR 2.0 offers three major improvements: dynamic generation of JavaScript from a Java API at runtime, support for asynchronous message transfer from server to the browser, and security features to reduce the possibility of cross-site scripting (XSS) and cross-site request forgery (CSRF.)
JCP Good, Bad, and Ugly
I spoke with Onno Kluyt, senior director and CTO/Labs at Sun, and director of the Java Community Process (JCP) about the good, the bad, and the ugly of the JCP. I pointed out the good in JSR 108 and how many platforms and tools support annotations. He smiled. I pointed out the bad in JSR 102 where JDOM made it past the JSR Review Ballot and the Executive Committee for SE/EE approved the ballot but JDOM never made it into Java. Onno said JDOM never achieved a formal specification. Onno told me that when you submit a JSR it is forward-looking and sometimes the market changes, the developers change, and in the end there is no shame in withdrawing a JSR. Onno said some JSRs don't work out because of the human part of a JSR. He quoted Cameron Purdy at the TSSJS Barcelona JCP panel saying he was surprised to find that the spec lead has to do real work. Onno related a JSR to leading an open source project, "not everyone flocks to you just because you are a JSR."
Then I talked about ugly in the form of JBI. I watched JBI fall apart with IBM and BEA starting as members of the expert group to exit just before the draft specification. From the outside, it looked to me like Sun used its position to control the JCP process in its favor and made me question the open and impartial nature I was expecting of the JCP. Onno told me in this case Sun, BEA, and IBM were members of the JBI expert group and Sun did not push them out. This was a case where the three had competitive products and did not want to create a standard. The JCP community facilitated lots of background conversations to keep JBI moving according to Onno. He pointed to the executive committee approving JBI as evidence that the JCP is not about Sun pushing through its standard.
In a self reflective moment Onno said "The market and the community is larger than any of us." For instance, Onno told me JSR 76 and 78 on RMI were voted down (with much of the work there now moved to JINI.)
Onno told me over the coming year the JCP will begin to allow JSRs to be implemented outside of Java. Sun, HP and IBM and others have customers with very mixed datacenters. For instance, JSR 76 and 78 deliver RMI client and server in Java and some customers need a C, or even a Cobol, implementation.
An Evening With Performance Geeks
Madhu Konda and Scott Oaks led a BOF on JEE performance optimization. JEE originally meant the application server. The definition and their responsibilities have greatly changed to include AJAX, XML bindings, Web 2.0 protocols, and business integration. That sounds pretty daunting to me considering how many variations there are to test for performance.
Madhu and Scott brought out the entire team: Acra does load generation and Web 2.0 on the server side, Charlie Hunt works with SE and EE team, Scott Oaks is tech lead on Glassfish performance and JAX WS performance, Venkana works on server performance, Kim focuses on XML, Venu is lead for dev2.0 on server side, and Murty is an OpenESB architect.
I asked how the Sun performance team keeps track of all the XML binding compilers and parsers. For instance the
BindMark commiter gave up on keeping up to date on the 21 different XML binding compilers and parsers that are out there. The Sun performance team related to the Bindmark experience and said they focus on comparing XML bindings using XMLBeans and JAXB.
One BOF attendee asked "We do a lot of XSLT transformations. We discovered that (in) a single thread approach there is a specific memory leak. The leak is even discussed on the Apache site. What steps would Sun take to prevent it?" The team generally agreed that once they suspect a memory leak they use OptimizeIt to take snapshots over time and compare the snapshots to determine the existence of the leak. They also pointed out the utility in JDK 6's JHat heap analysis tool. They recommended reading Jean-Francois Arcand's Blog.
When asked for performance data that compares Glassfish to other application servers the team noted that they are in the middle of Glassfish 2 development. The Spec organization will not allow them to publish data until they are in an FCS state. On the other hand, they noted that individual team members publish informal blogs that often include performance data. The team said Glassfish 2 is a performance-oriented release.
Madhu noted that Glassfish 1 performance ranking using SpecJAppServer shows Glassfish 15-25% slower than the leader, Oracle, using MySQL DB. They were happy to prove that their open source application server was close to Oracle.
Others on the team talked about how much time XML bindings take to transform documents into objects. For example, they said JAXB 1.1 moving to 2.1 drastically changed the initialization technique and that slows performance.
The performance team offered suggestions on XML optimization. For instance, they noted that some applications use factories that initialize when the JVM loads. Instantiating these factories is very expensive and the team recommended a pooling strategy. They also noted that a lot of the parsers are not multi-threaded and are not cache safe. They said a common mistake they see is to cache a parser that is not thread safe. You want to use factories to create your own parser instance.
The Sun performance team created FABAN, their own performance test tool, out of a need to do testing, modeling, and simulations. The team makes FABAN freely available and they do the maintenance on it. They chose not to use SlamD because they wanted functions that would let them multiple tests over time and compare the results. They found HP LoadRunner to be very linear in its test development technology. If you simulate 1000 users they all tend to be the same. The Sun team needed mixes and timing models that provide randomness. FABAN uses an EJB-like programming model to code tests, including a configuration file for easy tests. FABAN includes no timing code or report generation code.
When asked about performance testing for AJAX applications the group was a little less certain. FABAN tests at the network protocol level without actually instantiating a browser. The Selenium project uses a live browser. That makes it difficult to stage a scalability and performance test when each server needs multiple browsers. I got together with the Selenium leads a couple of weeks ago and figured out how to run Selenium in the PushToTest Version 5 environment. I told the Sun team how I accomplished this so they could consider it for FABAN.
Details are at http://performance.dev.java.net
Dynamic Scripting
I hosted the Dynamic Scripting BOF at JavaOne. The event went off very well with what looked like hundreds of attendees – it could have been the large room! It was an occasion for all of the scripting language proponents to met and discuss the state-of-affairs. It was also a good chance to meet John Rose, the new spec lead for JSR 292, and a very nice guy. Download the slide presentation from my blog site.
Make The UnConference An All Java Long Event
My biggest criticism of JavaOne over the years is how often the conference planners seem to mismatch what I am interested in with the actual program. There are other problems like scheduling snafoos – for instance, planning all of the Spring sessions to be on Tuesday at 1:00 pm in different halls. I wish JavaOne would adopt the UnConference technique and set aside one track on each day just for attendee nominated presentations and discussions. The RedMonk sponsored UnConference during the CommunityOne pre-conference last Monday had the content and attendees I value most and made the JavaOne experience richer for me.
-Frank
Threaded replies
· JavaOne 2007 Day 2 and 3 Coverage by Frank Cohen on Thu May 10 21:00:23 EDT 2007
· Jython 2.2 beta 2 ships by Frank Cohen on Fri May 11 03:13:44 EDT 2007
· FABAN? by Erik Bengtson on Fri May 11 09:51:09 EDT 2007
· Link by Aaron Anderson on Fri May 11 11:08:30 EDT 2007
· Download link by Peter Mularien on Fri May 11 11:27:24 EDT 2007
· Imola Informatica Link by raffaele spazzoli on Fri May 11 18:04:39 EDT 2007
· Oti's Jython Talk slides available by Frank Cohen on Fri May 11 18:31:24 EDT 2007
· Oh No! by Cameron Purdy on Fri May 11 21:13:29 EDT 2007
· JCP and defensive leadership by Frank Cohen on Sat May 12 02:49:44 EDT 2007
2007年5月17日星期四
Priority-based and FIFO-based transaction processing
Owen Taylor from Gigaspaces posted a solution discussion on priority-based and FIFO-based transaction processing. His initial example is that of a set of stock transactions: while customers' orders aren't dependent on each other, and thus can be unordered, a given customer's orders must be processed in a given order.
This type of ordering is referred to as FIFO or First In First Out ordering and is a common requirement in transaction-processing applications or almost any stateful application.
Another type of Ordering is Priority-based ordering. In this case, transactions need to be processed in a specific order based on a priority tag that has been assigned to them. In this scenario some orders must, 'jump the stack', if they expose a higher priority than the others ahead of them.
Parallelization and Ordering (FIFO and/Or Priority) are often seen as contradicting requirements. Indeed, if you look at the way transaction-processing systems are built you will find that in most cases where ordering is required most transactions are routed to a centralized message queue and that queue controls the order in which they are processed. This creates a single-point of contention (or bottleneck) that greatly limits the level of parallelization and scalability that can be achieved by such a system. This is especially true in cases that demand very low-latency or short-lived transactions. Here, where the execution time needs to be a few milliseconds at most, the time it takes to retrieve the transaction from the messaging queue can be greater than the time it takes to actually process the transaction. I consider that a problem.
Solving priority-based queue issues can be quite difficult. Easy solutions, like creating transient queues, aren't necessarily scalable (thousands of temporary queues being used and discarded) or cleanly manageable.
Normally, the JavaSpace model doesn't address this head-on (as matching objects to templates is unordered.) But Gigaspaces has a solution to the issue, through the use of a number of proprietary extensions, including SQL querying (and ordering) of the space. Owen includes an example of how to do a FIFO+Priority Queue in the entry.
As an employee of Gigaspaces, he's not quite neutral (nor would one expect him to be), but it's nice to see the space-based technology move forward.
This type of ordering is referred to as FIFO or First In First Out ordering and is a common requirement in transaction-processing applications or almost any stateful application.
Another type of Ordering is Priority-based ordering. In this case, transactions need to be processed in a specific order based on a priority tag that has been assigned to them. In this scenario some orders must, 'jump the stack', if they expose a higher priority than the others ahead of them.
Parallelization and Ordering (FIFO and/Or Priority) are often seen as contradicting requirements. Indeed, if you look at the way transaction-processing systems are built you will find that in most cases where ordering is required most transactions are routed to a centralized message queue and that queue controls the order in which they are processed. This creates a single-point of contention (or bottleneck) that greatly limits the level of parallelization and scalability that can be achieved by such a system. This is especially true in cases that demand very low-latency or short-lived transactions. Here, where the execution time needs to be a few milliseconds at most, the time it takes to retrieve the transaction from the messaging queue can be greater than the time it takes to actually process the transaction. I consider that a problem.
Solving priority-based queue issues can be quite difficult. Easy solutions, like creating transient queues, aren't necessarily scalable (thousands of temporary queues being used and discarded) or cleanly manageable.
Normally, the JavaSpace model doesn't address this head-on (as matching objects to templates is unordered.) But Gigaspaces has a solution to the issue, through the use of a number of proprietary extensions, including SQL querying (and ordering) of the space. Owen includes an example of how to do a FIFO+Priority Queue in the entry.
As an employee of Gigaspaces, he's not quite neutral (nor would one expect him to be), but it's nice to see the space-based technology move forward.
Lazy, stupid, and evil design for websites
Werner Ramaekers has summed up an interview with Jakob Neilsen on some of the common errors made by web designers. Werner focuses on, in this case, flash intros, apparently finding it to be an easily avoided mistake. Good advice!
That said, a flash intro would be neat for TheServerSide...
Threaded replies
· Lazy, stupid, and evil design for websites by Joseph Ottinger on Sun Jul 10 08:15:34 EDT 2005
· Usability isn't the problem by Adam Spencer on Wed Jul 13 15:15:28 EDT 2005
· Usability isn't the problem - grammar correction by Adam Spencer on Wed Jul 13 15:18:57 EDT 2005
· no flash please by Alexander Jesse on Wed Jul 13 15:30:17 EDT 2005
· no flash please by Adam Spencer on Thu Jul 14 10:01:09 EDT 2005
That said, a flash intro would be neat for TheServerSide...
Threaded replies
· Lazy, stupid, and evil design for websites by Joseph Ottinger on Sun Jul 10 08:15:34 EDT 2005
· Usability isn't the problem by Adam Spencer on Wed Jul 13 15:15:28 EDT 2005
· Usability isn't the problem - grammar correction by Adam Spencer on Wed Jul 13 15:18:57 EDT 2005
· no flash please by Alexander Jesse on Wed Jul 13 15:30:17 EDT 2005
· no flash please by Adam Spencer on Thu Jul 14 10:01:09 EDT 2005
Geronimo gets JBI support from ServiceMix
James Strachan writes that at JavaOne he and the ServiceMix team added a JBI deployer into Geronimo. This means that the standard Geronimo deployer can now automatically detect a JBI deployment unit (any jar which includes META-INF/jbi.xml inside it) and then auto-deploy a JBI component or service assembly. So now Geronimo is now the first J2EE (nearly) certified container which has JBI support!
Read Geronimo does JBI (Java Business Integration) via ServiceMix.
Read Geronimo does JBI (Java Business Integration) via ServiceMix.
Newest Concern on Sun's Open Source Strategy
Jim Driscoll, currently project manager for Glassfish, has blogged "Newest Concern on Sun's Open Source Strategy," addressing concerns over copyright assignment to Sun under the CDDL. His statement is that the dual-assignment is normal for open source.
"Native XML Support in Java not worth it", Gosling says
Val was surprised (read disappointed) to discover that Gosling doesn't consider direct XML support a priority, in a recent eWeek interview. In the meantime, Kirill Grouchnikov, a community lead in the Java WS and XML community, wrote a very nice blog entry on Dolphin's native XML support.
Read "Native XML Support in Java not worth it", Gosling says.
Read "Native XML Support in Java not worth it", Gosling says.
Jody Garnett on "Open-Source Factors of Success"
Jody Garnett, in "Open-Source Factors of Success," documents the three rules to a successful project: Do something worthwhile, accept contributions, make contributions easy. In true blog-style, he lists a fourth important section, "Documentation and Learning Curve."
Most Open Source projects simply have to follow a basic formula:
Do something worthwhile
Accept contributions
Make contributions easy
Now this is only a rule of thumb, you can make something useless and easy to contribute to and still have a good time. There is utility in fun.
I am tempted to list an Open-Development process as essential as well (it seems to be for making a community, but not always required for a project). I am going to put it down as a tool for building trust which goes towards making the decision to contribute easier for people.
Most Open Source projects simply have to follow a basic formula:
Do something worthwhile
Accept contributions
Make contributions easy
Now this is only a rule of thumb, you can make something useless and easy to contribute to and still have a good time. There is utility in fun.
I am tempted to list an Open-Development process as essential as well (it seems to be for making a community, but not always required for a project). I am going to put it down as a tool for building trust which goes towards making the decision to contribute easier for people.
Bhakti Mehta: "JAXB 2.0 and JAX-WS 2.0 are a part of Mustang"
Bhakti Mehta, in "JAXB 2.0 and JAX-WS 2.0 are a part of Mustang," describes some of the new integration features. If you're using Mustang (b40 or later), you can now use xjc, schemagen, wsgen, and wsimport as part of the JDK.
Patrick Lightbody: WebWork 2.2: JSR168 (Portlet) Support!
Patrick Lightbody blogged about the integration of the WWPortlet project into WebWork 2.2, to provide portlet support for WebWork applications, in "WebWork 2.2: JSR168 (Portlet) Support!"
In a related note, TSS found out about WWPortlet when it was still early in development but we apparently missed its 1.0 release. Ouch.
In a related note, TSS found out about WWPortlet when it was still early in development but we apparently missed its 1.0 release. Ouch.
Binod on Lazy Initialization of Application Server Services
Binod has written a blog entry entitled "Lazy Initialization of Application Server Services" to present a sort of FAQ on Sun's use of lazy initialization in Glassfish.
Most of the developers are not going to use all the services in the Application Server. I am not talking about those who develop really complex EE applications all the time, but about developers who download the Application Server and just try out a few samples, or folks who learn one or two technologies at a time or even folks who work on small projects that use only some of the technologies from the Java EE stack. This group of developers would not like to incur the overhead of startup-time/memory for all the services they would not use.
Hence now, the Sun Java System Application Server does not start all the containers during startup. In fact when you install Application Server and start it afresh, there will be only a handful essential services initialized, namely a local JNDI provider, JMX connector (for administration).
Most of the developers are not going to use all the services in the Application Server. I am not talking about those who develop really complex EE applications all the time, but about developers who download the Application Server and just try out a few samples, or folks who learn one or two technologies at a time or even folks who work on small projects that use only some of the technologies from the Java EE stack. This group of developers would not like to incur the overhead of startup-time/memory for all the services they would not use.
Hence now, the Sun Java System Application Server does not start all the containers during startup. In fact when you install Application Server and start it afresh, there will be only a handful essential services initialized, namely a local JNDI provider, JMX connector (for administration).
Tim Bray: In or Out?
Tim Bray, in "In or Out?," talks about the naming of streams for ProcessBuilder, and the confusion about getInputStream (is that the process' input stream or an input stream for the process' caller?)
Hybrid Open Source Business Models
Zach Urlocker discusses how many companies are developing a hybrid open source business model. He uses SugarCRM as an example of a company that has developed a hybrid business model that contains no agenda or suprises.
SugarCRM has an open source offering and a commerical product. The source for the commerical product is avaliable though not licensed as open source. Is this idyllic model workable in the long term? How does this fit in a competitive environment?
SugarCRM has an open source offering and a commerical product. The source for the commerical product is avaliable though not licensed as open source. Is this idyllic model workable in the long term? How does this fit in a competitive environment?
Dan Creswell: JINI vs. SOAP? They aren't competitors.
Dan Creswell, in "JINI vs SOAP," addresses the perception of competition between JINI and SOAP, and says that JINI and SOAP address different things: One is a piece of plumbing the other is a set of blueprints.
Kirill Grouchnikov on Mylar
Mylar, an Eclipse plug-in, provides developers with a view of a workspace that reflects the task context which they are working in. It builds this view by tracking which classes that the developer is editing and adding them to the view. In this way the develop can easily find and revisit those elements of the workspace that were involved in the implementation of said feature or bug fix.
In his blog, Kirill Grouchnikov shares with us how Mylar, an Eclipse plug-in can simplify the task of implementing a feature into a large project. The explanation comes with many screenshots showing a before and after Mylar development path.
Threaded replies
· Kirill Grouchnikov on Mylar by Kirk Pepperdine on Mon Nov 07 07:16:59 EST 2005
· Kirill Grouchnikov on Mylar by Slava Imeshev on Wed Nov 09 03:47:55 EST 2005
· Kirill Grouchnikov on Mylar by Mik Kersten on Wed Nov 09 12:12:31 EST 2005
· Integration with source management system by Torsten Beuck on Mon Nov 14 07:07:19 EST 2005
· Integration with source management system by Mik Kersten on Wed Nov 16 14:50:25 EST 2005
· Mylar 0.4.4 will trash WTP by Rosdi Kasim on Sun Dec 11 12:31:37 EST 2005
In his blog, Kirill Grouchnikov shares with us how Mylar, an Eclipse plug-in can simplify the task of implementing a feature into a large project. The explanation comes with many screenshots showing a before and after Mylar development path.
Threaded replies
· Kirill Grouchnikov on Mylar by Kirk Pepperdine on Mon Nov 07 07:16:59 EST 2005
· Kirill Grouchnikov on Mylar by Slava Imeshev on Wed Nov 09 03:47:55 EST 2005
· Kirill Grouchnikov on Mylar by Mik Kersten on Wed Nov 09 12:12:31 EST 2005
· Integration with source management system by Torsten Beuck on Mon Nov 14 07:07:19 EST 2005
· Integration with source management system by Mik Kersten on Wed Nov 16 14:50:25 EST 2005
· Mylar 0.4.4 will trash WTP by Rosdi Kasim on Sun Dec 11 12:31:37 EST 2005
Log4J a Potential Performance Hit.
If you’ve ever wondered how log4j injects the line numbers of the code generating the debugging information then now you need look no farther then Zarar latest blog entry. In his blog Zarar not only explains how log4j achieves this he also points out that you may want to take care to ensure this feature is turned off in production.
It's all about the Logs
In his blog Joe Savard reminds us of the value of looking through log files when you are involved in trouble-shooting problems.
ALL logs are the unheard screams of your systems, the perverbial grimacing "Ouch!". Instead of going to the code, or the GUI... When there is a problem go to the logs to see what ails your system.
If you've ever gotten so wound up in a problem that you totally miss the easy stuff? Sometimes the "easy stuff" isn’t all that easy. For example why on earth does Tomcat log to catalina.log files anyways?
ALL logs are the unheard screams of your systems, the perverbial grimacing "Ouch!". Instead of going to the code, or the GUI... When there is a problem go to the logs to see what ails your system.
If you've ever gotten so wound up in a problem that you totally miss the easy stuff? Sometimes the "easy stuff" isn’t all that easy. For example why on earth does Tomcat log to catalina.log files anyways?
Euxx: Show me the variables
In "Show me the variables," Euxx shows how to add variables to classes modified by aspect-oriented weaving libraries, by creating debugging information about new variables, so the debugger can match it with the actual state and even if those variables are not in the source code, the user will see them in the debugger.
Bytecode waving is a powerful technique that gained popularity in a last few years. Well known tools are using it with great success, that include Hibernate, CGLIB, AspectWerkz, AspectJ, you name it...
Unfortunately, in many cases these tools introduce additional challenge to developers who need to debug an instrumented code. Waving adds an additional behavior that is not shown in the source code and it may also add additional state that is hard to trace, especially if it is stored in method variables. To solve this, instrumentation could add a debug logging, but it would be additional overhead on the bytecode size, instrumentation and runtime performance. However, with very little effort waving tools could make debugging of the instrumented methods with new variables much easier.
Bytecode waving is a powerful technique that gained popularity in a last few years. Well known tools are using it with great success, that include Hibernate, CGLIB, AspectWerkz, AspectJ, you name it...
Unfortunately, in many cases these tools introduce additional challenge to developers who need to debug an instrumented code. Waving adds an additional behavior that is not shown in the source code and it may also add additional state that is hard to trace, especially if it is stored in method variables. To solve this, instrumentation could add a debug logging, but it would be additional overhead on the bytecode size, instrumentation and runtime performance. However, with very little effort waving tools could make debugging of the instrumented methods with new variables much easier.
MS License: Using Java Could Lead to Death
Have you ever really read the license agreements that come with the software that you use on a daily basis? Yakov Fain did and to his surprise he found that Microsoft warns it's users that using Java maybe fatal.
The software product may contain support for programs written in Java. Java technology is not fault tolerant and is not designed, manufactured, or intended for use or resale as on-line control equipment in hazardous environments requiring fail-safe performance, such as in the operation of nuclear facilities, aircraft navigation or communication systems, air traffic control, direct life support machines , or weapon systems, in which the failure of Java technology could lead directly to death, personal injury, or severe physical or environmental damage.
Is this marketing gone mad or does Microsoft know something that we don't?
Threaded replies
· MS License: Using Java Could Lead to Death by Kirk Pepperdine on Thu Dec 22 08:55:47 EST 2005
· MS License: Using Java Could Lead to Death by bruno chevalier on Thu Dec 22 10:38:04 EST 2005
· License by Kevin Hooke on Thu Dec 22 10:55:03 EST 2005
· Re: License by John Wrynn on Tue Mar 07 17:03:20 EST 2006
· OoOoOoOoh really !!!!!!! by Raken Silberchatz on Tue Dec 27 08:50:41 EST 2005
· Wow.... by Soumen Chatterjee on Tue Dec 27 15:41:48 EST 2005
· You should patent the hair growth solution! by Yakov Fain on Mon Jan 02 16:10:06 EST 2006
· It's based on the java license by Seth Taplin on Tue Jan 03 12:37:27 EST 2006
· Amusing but...here is a quote from Sun's.. by alexander yershov on Tue Jan 03 14:26:00 EST 2006
· JMARS by Shivarajan Varadarajan on Wed Mar 08 03:53:58 EST 2006
· True Life and Death Development Languages by Matt DeC on Wed Mar 08 08:58:57 EST 2006
· really java kills!! by amit b on Fri Dec 23 03:43:04 EST 2005
· MS License: Using Java Could Lead to Death by James Watson on Fri Dec 23 14:09:57 EST 2005
· NO by ahmed ali on Wed Dec 28 05:22:32 EST 2005
· Java kills by S zaidi on Fri Dec 30 02:29:48 EST 2005
· Re: MS License: Using Java Could Lead to Death by Todd Gamble on Tue Jan 03 12:14:55 EST 2006
· Re: MS License: Using Java Could Lead to Death by aditya kakani on Wed Mar 08 12:52:30 EST 2006
· OH NO - WHY DIDN'T SOMEONE TELL ME EARLIER!!! by Ron Chan on Tue Jan 03 12:58:09 EST 2006
· Just some more words ... by Gustavo Nunes Ferreira on Tue Jan 03 13:15:25 EST 2006
· noted by Erick Reid on Tue Jan 03 13:19:35 EST 2006
· MS License: Using Java Could Lead to Death by Christian Vest Hansen on Tue Jan 03 17:12:53 EST 2006
· Switch to .NET by Jayant Kayarkar on Tue Jan 03 22:51:27 EST 2006
· Bread is much more dangerous by Daniel Vermes on Wed Jan 04 05:08:22 EST 2006
· Well that explains alot by Bob Mengert on Wed Jan 04 08:09:18 EST 2006
· MS License: Using Java Could Lead to Death by Jevgeni Kabanov on Thu Jan 05 04:36:23 EST 2006
· Oh well by Alex Shneyderman on Tue Mar 07 16:44:11 EST 2006
· MS License: Using Java Could Lead to Death by Parimal Khedkar on Tue Mar 07 21:01:44 EST 2006
· Maybe MS will kill you by S Sudhindra on Wed Mar 08 00:06:37 EST 2006
· Maybe MS will kill you : Wo wee Robosapien.... by Shivarajan Varadarajan on Wed Mar 08 03:52:12 EST 2006
· You don't say by Gray Phelps on Wed Mar 08 04:13:37 EST 2006
· MS License: Using Java Could Lead to Death by Manoj Khandelwal on Fri Mar 10 10:30:56 EST 2006
The software product may contain support for programs written in Java. Java technology is not fault tolerant and is not designed, manufactured, or intended for use or resale as on-line control equipment in hazardous environments requiring fail-safe performance, such as in the operation of nuclear facilities, aircraft navigation or communication systems, air traffic control, direct life support machines , or weapon systems, in which the failure of Java technology could lead directly to death, personal injury, or severe physical or environmental damage.
Is this marketing gone mad or does Microsoft know something that we don't?
Threaded replies
· MS License: Using Java Could Lead to Death by Kirk Pepperdine on Thu Dec 22 08:55:47 EST 2005
· MS License: Using Java Could Lead to Death by bruno chevalier on Thu Dec 22 10:38:04 EST 2005
· License by Kevin Hooke on Thu Dec 22 10:55:03 EST 2005
· Re: License by John Wrynn on Tue Mar 07 17:03:20 EST 2006
· OoOoOoOoh really !!!!!!! by Raken Silberchatz on Tue Dec 27 08:50:41 EST 2005
· Wow.... by Soumen Chatterjee on Tue Dec 27 15:41:48 EST 2005
· You should patent the hair growth solution! by Yakov Fain on Mon Jan 02 16:10:06 EST 2006
· It's based on the java license by Seth Taplin on Tue Jan 03 12:37:27 EST 2006
· Amusing but...here is a quote from Sun's.. by alexander yershov on Tue Jan 03 14:26:00 EST 2006
· JMARS by Shivarajan Varadarajan on Wed Mar 08 03:53:58 EST 2006
· True Life and Death Development Languages by Matt DeC on Wed Mar 08 08:58:57 EST 2006
· really java kills!! by amit b on Fri Dec 23 03:43:04 EST 2005
· MS License: Using Java Could Lead to Death by James Watson on Fri Dec 23 14:09:57 EST 2005
· NO by ahmed ali on Wed Dec 28 05:22:32 EST 2005
· Java kills by S zaidi on Fri Dec 30 02:29:48 EST 2005
· Re: MS License: Using Java Could Lead to Death by Todd Gamble on Tue Jan 03 12:14:55 EST 2006
· Re: MS License: Using Java Could Lead to Death by aditya kakani on Wed Mar 08 12:52:30 EST 2006
· OH NO - WHY DIDN'T SOMEONE TELL ME EARLIER!!! by Ron Chan on Tue Jan 03 12:58:09 EST 2006
· Just some more words ... by Gustavo Nunes Ferreira on Tue Jan 03 13:15:25 EST 2006
· noted by Erick Reid on Tue Jan 03 13:19:35 EST 2006
· MS License: Using Java Could Lead to Death by Christian Vest Hansen on Tue Jan 03 17:12:53 EST 2006
· Switch to .NET by Jayant Kayarkar on Tue Jan 03 22:51:27 EST 2006
· Bread is much more dangerous by Daniel Vermes on Wed Jan 04 05:08:22 EST 2006
· Well that explains alot by Bob Mengert on Wed Jan 04 08:09:18 EST 2006
· MS License: Using Java Could Lead to Death by Jevgeni Kabanov on Thu Jan 05 04:36:23 EST 2006
· Oh well by Alex Shneyderman on Tue Mar 07 16:44:11 EST 2006
· MS License: Using Java Could Lead to Death by Parimal Khedkar on Tue Mar 07 21:01:44 EST 2006
· Maybe MS will kill you by S Sudhindra on Wed Mar 08 00:06:37 EST 2006
· Maybe MS will kill you : Wo wee Robosapien.... by Shivarajan Varadarajan on Wed Mar 08 03:52:12 EST 2006
· You don't say by Gray Phelps on Wed Mar 08 04:13:37 EST 2006
· MS License: Using Java Could Lead to Death by Manoj Khandelwal on Fri Mar 10 10:30:56 EST 2006
Shing Wai Chan: Troubleshooting Deployment in Glassfish
Shing Wai Chan, in "Troubleshooting Deployment in Glassfish," has documented a few common deployment problems in Glassfish, how to determine if you're suffering from them, and how to fix them.
It's an interesting idea: what other such problems and solutions are available for specific application servers? Perhaps someone should work on a categorical reference. :)
It's an interesting idea: what other such problems and solutions are available for specific application servers? Perhaps someone should work on a categorical reference. :)
Bill Venners on Code Generation
In his blog, Bill Venners talks about Bruce Tate’s latest article on Ruby on Rails Active Records. Bill suggests that the real benefit of RoR is not a question of wrapping vs. mapping but rather it’s about the real benefits of code generation.
Bill never questions the benefits of Bruce’s wrapping argument. Instead he bolsters Bruce’s position by providing examples of where wrapping a code generation in a standard API has proved invaluable.
twice a year I found myself editing the SQL schema file that created the tables and also editing that C file that served as the layer. It dawned on me that all the information needed to generate the C file was contained in the SQL schema file, so I wrote a Yacc/Lex program that parsed the SQL schema file and generated the C file (i.e., it generated the database layer for our application)
Bill provides us with a nice description of the differences between static and dynamic code generation. The technique used by Bill and the one that we typically use in Java is known as static code generation. On the other hand, RoR uses dynamic code generation. This dynamic mechanism gives the appearance of being very light-weight.
To me the important lesson for the Java community to take away from Rails is that you should consider using code generation where appropriate.
Bill also recognized the weakness of code generators in that they often are not able to completely generate all the code needed. Thus is it up the developers to finish the task. Once tinkered with, you often cannot regenerate the code without risk of losing the changes. This has been one of the biggest knocks against GUI generators.
In the end Bill is very positive about how Ruby and Python push developers into creating code generators. However he is equally positive about the ability to achieve the same thing using tools such as JavaCC and Antlr. You can read the entire post and Bill’s references at his blog.
Bill never questions the benefits of Bruce’s wrapping argument. Instead he bolsters Bruce’s position by providing examples of where wrapping a code generation in a standard API has proved invaluable.
twice a year I found myself editing the SQL schema file that created the tables and also editing that C file that served as the layer. It dawned on me that all the information needed to generate the C file was contained in the SQL schema file, so I wrote a Yacc/Lex program that parsed the SQL schema file and generated the C file (i.e., it generated the database layer for our application)
Bill provides us with a nice description of the differences between static and dynamic code generation. The technique used by Bill and the one that we typically use in Java is known as static code generation. On the other hand, RoR uses dynamic code generation. This dynamic mechanism gives the appearance of being very light-weight.
To me the important lesson for the Java community to take away from Rails is that you should consider using code generation where appropriate.
Bill also recognized the weakness of code generators in that they often are not able to completely generate all the code needed. Thus is it up the developers to finish the task. Once tinkered with, you often cannot regenerate the code without risk of losing the changes. This has been one of the biggest knocks against GUI generators.
In the end Bill is very positive about how Ruby and Python push developers into creating code generators. However he is equally positive about the ability to achieve the same thing using tools such as JavaCC and Antlr. You can read the entire post and Bill’s references at his blog.
Stardock's 10 rules for success
In "Stardock's 10 rules for success," one of Stardock's administrators outlines the corporate philosophy. Stardock makes the "WindowBlinds" desktop replacement for Windows, which isn't Java-related per se, but it's excellent advice for developers anywhere.(Although judging from their other product offerings, they left off "Use Christmas themes in as many games as we can" from their list.)
Your next Computer Language
Ever wonder if the next language you learn should be Ruby, Python, or the next latest fad to hit the streets. If so then maybe you should take some advice from Daniel Ostermeier and Jason Sankey.
for me, the single programming language I use most frequently day-to-day, alongside my primary language, is bash scripting. Yep, plain old hackish shell scripts. Yes, that is correct. These guys are recommending that you go and learn how to program in bash. And they are not taking no for an answer.
So, no excuses! Even those of you more inclined to the Windows way of life have easy access to bash (and other shells) via Cygwin.Why do these guys like bash scripting? You can find the answer to that question in their blog. In the meantime maybe you’d like to share your opinions on the usefulness of bash.
for me, the single programming language I use most frequently day-to-day, alongside my primary language, is bash scripting. Yep, plain old hackish shell scripts. Yes, that is correct. These guys are recommending that you go and learn how to program in bash. And they are not taking no for an answer.
So, no excuses! Even those of you more inclined to the Windows way of life have easy access to bash (and other shells) via Cygwin.Why do these guys like bash scripting? You can find the answer to that question in their blog. In the meantime maybe you’d like to share your opinions on the usefulness of bash.
Marc Logemann: Is WSRP Dead?
Marc Logemann has posted "No WSRP Producer example. Is WSRP dead?," asking about the availability of a WSRP service for testing. WSRP is an OASIS protocol for portals to display content hosted on a different server than the portal itself.There are various WSRP implementations in the wild, including an implementation on Java.net (https://wsrp.dev.java.net/) but it's certainly worth wondering how one can successfully test, if services are hard to find.
Threaded replies
·
Marc Logemann: Is WSRP Dead? by Joseph Ottinger on Mon Apr 23 09:50:59 EDT 2007
·
Re: Marc Logemann: Is WSRP Dead? by Peter Moskovits on Mon Apr 23 13:21:34 EDT 2007
·
Silly question by Subbu Allamaraju on Mon Apr 23 14:34:33 EDT 2007
·
No, it's not by Charles Wise on Mon Apr 23 17:23:50 EDT 2007
·
Re: No, it's not by ashok shetty on Mon Apr 23 22:57:46 EDT 2007
·
Valid Question by Karl Banke on Tue Apr 24 05:59:16 EDT 2007
·
Re: Valid Question by Cameron Purdy on Tue Apr 24 07:11:43 EDT 2007
·
Re: Valid Question by Karl Banke on Tue Apr 24 11:37:30 EDT 2007
·
Re: Valid Question by Cameron Purdy on Wed Apr 25 15:32:08 EDT 2007
·
read blogs carefully by Marc Logemann on Thu Apr 26 04:52:48 EDT 2007
·
Re: Marc Logemann: Is WSRP Dead? by Brandon Mailinator on Tue Apr 24 12:50:13 EDT 2007
·
Re: Marc Logemann: Is WSRP Dead? by michael young on Tue Apr 24 21:53:13 EDT 2007
·
Re: Marc Logemann: Is WSRP Dead? by Chris Jolley on Thu Apr 26 13:12:25 EDT 2007
·
Re: Marc Logemann: Is WSRP Dead? by Rickard Oberg on Fri Apr 27 05:09:26 EDT 2007
·
Re: Marc Logemann: Is WSRP Dead? by michael young on Fri Apr 27 15:01:19 EDT 2007
·
Re: Marc Logemann: Is WSRP Dead? by Rickard Oberg on Wed May 02 08:47:17 EDT 2007
·
Sun Interop Server by Rajesh T on Wed Apr 25 02:21:56 EDT 2007
·
Remote portlets are alive at least by Derek Alexander on Wed Apr 25 12:56:24 EDT 2007
Threaded replies
·
Marc Logemann: Is WSRP Dead? by Joseph Ottinger on Mon Apr 23 09:50:59 EDT 2007
·
Re: Marc Logemann: Is WSRP Dead? by Peter Moskovits on Mon Apr 23 13:21:34 EDT 2007
·
Silly question by Subbu Allamaraju on Mon Apr 23 14:34:33 EDT 2007
·
No, it's not by Charles Wise on Mon Apr 23 17:23:50 EDT 2007
·
Re: No, it's not by ashok shetty on Mon Apr 23 22:57:46 EDT 2007
·
Valid Question by Karl Banke on Tue Apr 24 05:59:16 EDT 2007
·
Re: Valid Question by Cameron Purdy on Tue Apr 24 07:11:43 EDT 2007
·
Re: Valid Question by Karl Banke on Tue Apr 24 11:37:30 EDT 2007
·
Re: Valid Question by Cameron Purdy on Wed Apr 25 15:32:08 EDT 2007
·
read blogs carefully by Marc Logemann on Thu Apr 26 04:52:48 EDT 2007
·
Re: Marc Logemann: Is WSRP Dead? by Brandon Mailinator on Tue Apr 24 12:50:13 EDT 2007
·
Re: Marc Logemann: Is WSRP Dead? by michael young on Tue Apr 24 21:53:13 EDT 2007
·
Re: Marc Logemann: Is WSRP Dead? by Chris Jolley on Thu Apr 26 13:12:25 EDT 2007
·
Re: Marc Logemann: Is WSRP Dead? by Rickard Oberg on Fri Apr 27 05:09:26 EDT 2007
·
Re: Marc Logemann: Is WSRP Dead? by michael young on Fri Apr 27 15:01:19 EDT 2007
·
Re: Marc Logemann: Is WSRP Dead? by Rickard Oberg on Wed May 02 08:47:17 EDT 2007
·
Sun Interop Server by Rajesh T on Wed Apr 25 02:21:56 EDT 2007
·
Remote portlets are alive at least by Derek Alexander on Wed Apr 25 12:56:24 EDT 2007
OnJava: Designing Messaging Applications with Temporary Queues
OnJava has published Thakur Thribhuvan's "Designing Messaging Applications with Temporary Queues," an article explaining how to use JMS' temporary queue capability to allow applications to "efficiently scale because you can easily expand the number available at runtime."
Temporary Destinations: An OverviewTemporary destinations (temporary queues or temporary topics) are proposed as a lightweight alternative in a scalable system architecture that could be used as unique destinations for replies. Such destinations have a scope limited to the connection that created it, and are removed on the server side as soon as the connection is closed. Only a single well-known static queue is required for producers/senders to connect with consumers using temporary destinations. The JMS header field JMSReplyTo is always used in conjunction with temporary destinations.Since the identity of the temporary destination is known only by the connection or session that created it, the consumer/receiver cannot know the destination name. The solution is to have the producer/sender send the name of its temporary destination as a header field (JMSReplyTo), as part of a message, sent to a known static queue listened to by the producer/sender.Limitations of Temporary DestinationsThere are a few limitations that must be recognized regarding temporary destinations:
A temporary destination can only be consumed by the connection that created it.
The life span of temporary destinations is only for the duration of the connection where they are created.
When you close the connection that has a temporary destination, the destination is closed and its contents are lost.
You cannot have durable subscriptions to a TemporaryTopic.
Each temporary destination is unique and cannot be copied.
Temporary destinations cannot be routed using an enterprise messaging service.
Threaded replies
·
OnJava: Designing Messaging Applications with Temporary Queues by Joseph Ottinger on Mon Apr 23 10:17:09 EDT 2007
·
Grids? by Konstantin Ignatyev on Mon Apr 23 14:51:13 EDT 2007
·
Re: Grids? by nati shalom on Tue Apr 24 20:22:41 EDT 2007
·
dead horse by Cameron Purdy on Tue Apr 24 23:28:42 EDT 2007
·
Re: dead horse by James Strachan on Wed Apr 25 01:34:27 EDT 2007
·
Re: dead horse by Jan de Jonge on Wed Apr 25 06:45:18 EDT 2007
·
Re: dead horse by Cameron Purdy on Wed Apr 25 16:05:14 EDT 2007
·
Re: dead horse by Will Hartung on Wed Apr 25 16:25:03 EDT 2007
·
Re: dead horse by Will Hartung on Wed Apr 25 16:25:04 EDT 2007
·
Re: dead horse by Shay Banon on Wed Apr 25 10:47:41 EDT 2007
·
Re: dead horse by Shay Banon on Wed Apr 25 10:49:53 EDT 2007
·
Re: dead horse by Cameron Purdy on Wed Apr 25 15:56:06 EDT 2007
·
Re: dead horse by Shay Banon on Thu Apr 26 04:05:34 EDT 2007
·
Re: dead horse by Cameron Purdy on Mon Apr 30 16:12:27 EDT 2007
·
Re: Grids? by nati shalom on Tue May 08 09:45:55 EDT 2007
·
Scaling the number of queues. by Peter Lawrey on Tue Apr 24 11:01:57 EDT 2007
·
Re: OnJava: Designing Messaging Applications with Temporary Queu by James Strachan on Tue Apr 24 12:46:47 EDT 2007
·
Re: OnJava: Designing Messaging Applications with Temporary Queu by Maurizio Turatti on Sat Apr 28 06:58:00 EDT 2007
Temporary Destinations: An OverviewTemporary destinations (temporary queues or temporary topics) are proposed as a lightweight alternative in a scalable system architecture that could be used as unique destinations for replies. Such destinations have a scope limited to the connection that created it, and are removed on the server side as soon as the connection is closed. Only a single well-known static queue is required for producers/senders to connect with consumers using temporary destinations. The JMS header field JMSReplyTo is always used in conjunction with temporary destinations.Since the identity of the temporary destination is known only by the connection or session that created it, the consumer/receiver cannot know the destination name. The solution is to have the producer/sender send the name of its temporary destination as a header field (JMSReplyTo), as part of a message, sent to a known static queue listened to by the producer/sender.Limitations of Temporary DestinationsThere are a few limitations that must be recognized regarding temporary destinations:
A temporary destination can only be consumed by the connection that created it.
The life span of temporary destinations is only for the duration of the connection where they are created.
When you close the connection that has a temporary destination, the destination is closed and its contents are lost.
You cannot have durable subscriptions to a TemporaryTopic.
Each temporary destination is unique and cannot be copied.
Temporary destinations cannot be routed using an enterprise messaging service.
Threaded replies
·
OnJava: Designing Messaging Applications with Temporary Queues by Joseph Ottinger on Mon Apr 23 10:17:09 EDT 2007
·
Grids? by Konstantin Ignatyev on Mon Apr 23 14:51:13 EDT 2007
·
Re: Grids? by nati shalom on Tue Apr 24 20:22:41 EDT 2007
·
dead horse by Cameron Purdy on Tue Apr 24 23:28:42 EDT 2007
·
Re: dead horse by James Strachan on Wed Apr 25 01:34:27 EDT 2007
·
Re: dead horse by Jan de Jonge on Wed Apr 25 06:45:18 EDT 2007
·
Re: dead horse by Cameron Purdy on Wed Apr 25 16:05:14 EDT 2007
·
Re: dead horse by Will Hartung on Wed Apr 25 16:25:03 EDT 2007
·
Re: dead horse by Will Hartung on Wed Apr 25 16:25:04 EDT 2007
·
Re: dead horse by Shay Banon on Wed Apr 25 10:47:41 EDT 2007
·
Re: dead horse by Shay Banon on Wed Apr 25 10:49:53 EDT 2007
·
Re: dead horse by Cameron Purdy on Wed Apr 25 15:56:06 EDT 2007
·
Re: dead horse by Shay Banon on Thu Apr 26 04:05:34 EDT 2007
·
Re: dead horse by Cameron Purdy on Mon Apr 30 16:12:27 EDT 2007
·
Re: Grids? by nati shalom on Tue May 08 09:45:55 EDT 2007
·
Scaling the number of queues. by Peter Lawrey on Tue Apr 24 11:01:57 EDT 2007
·
Re: OnJava: Designing Messaging Applications with Temporary Queu by James Strachan on Tue Apr 24 12:46:47 EDT 2007
·
Re: OnJava: Designing Messaging Applications with Temporary Queu by Maurizio Turatti on Sat Apr 28 06:58:00 EDT 2007
2007年5月15日星期二
Model 1.5
This articles is presenting something quite familiar, but however not well classified and described. It is actually closer to Model2, but lacks its decoupling of the business-layer. So I label it "Model 1.5". It is meant for single developers or small teams.A brief introduction. You will excuse me for once again telling what "MVC" is:Mode1 - a design strategy, where everyting - the presentation and the logic are situated in one jsp/servlet, which often "posts" back to itself when data-manipulation is required.Model2 - using the MVC design pattern:
A presentation (view) consists of jsp's that do not modify the data - just displays it.
A controller which handles all incoming requests, takes care of obtaining all the data from those requests, and directs them to the prespecified model components.
A model which, provided with all the parameters, handles the business-logic (e.g. data manipulation).Even with simplified look over the Model2, it still requires some deeper knowledge, and time, in order to create a proper controller . Let alone the use of a MVC framework.On the other hand, Model1 cannot provide extensibility, flexibility, and even hardly provides reuse of code.The use of Model2 for middle-sized application (say: 10-12 pages) might turn out to be unjustified. Then, what about merging the model and controller into one, pure Servlet? Here are the key points:
JSP's are used only for presentation - no data manipulation. Thus a separation of presentation from logic is achieved. However database-queries can be run from the view provided they just select, and not manipulate data. A little less work for the model.
All forms are posted to a particular Servlet, which handles the request parameters, generates database queries, and then returns the application to a component of the view.
The redirect-after-post principle is thus easily implemented
The business-layer is NOT decoupled from the web-application context, and hence creating other interfaces to it is harder.The advantages are clear: simplicity and flexibility. The disadvantages, of course: unsuitable for large applications, and ones developed by large teams.
A presentation (view) consists of jsp's that do not modify the data - just displays it.
A controller which handles all incoming requests, takes care of obtaining all the data from those requests, and directs them to the prespecified model components.
A model which, provided with all the parameters, handles the business-logic (e.g. data manipulation).Even with simplified look over the Model2, it still requires some deeper knowledge, and time, in order to create a proper controller . Let alone the use of a MVC framework.On the other hand, Model1 cannot provide extensibility, flexibility, and even hardly provides reuse of code.The use of Model2 for middle-sized application (say: 10-12 pages) might turn out to be unjustified. Then, what about merging the model and controller into one, pure Servlet? Here are the key points:
JSP's are used only for presentation - no data manipulation. Thus a separation of presentation from logic is achieved. However database-queries can be run from the view provided they just select, and not manipulate data. A little less work for the model.
All forms are posted to a particular Servlet, which handles the request parameters, generates database queries, and then returns the application to a component of the view.
The redirect-after-post principle is thus easily implemented
The business-layer is NOT decoupled from the web-application context, and hence creating other interfaces to it is harder.The advantages are clear: simplicity and flexibility. The disadvantages, of course: unsuitable for large applications, and ones developed by large teams.
MSN Messenger 7.5.0324 简体版 for XP
软件简介:
MSN Messenger 是微软公司推出的即时消息软件，凭借该软件自身的优秀的性能，目前在国内已经拥有了大量的用户群。使用MSN Messenger可以与他人进行文字聊天，语音对话，视频会议等即时交流，还可以通过此软件来查看联系人是否联机。MSN Messenger 界面简洁，易于使用，是与亲人、朋友、工作伙伴保持紧密联系的绝佳选择。使用您已有一个Email地址，即可注册获得免费的MSN Messenger的登录账号。在使用之前，强烈建议阅读(http://china.msn.com/Messenger/3steps/)三步法，快速启用 MSN Messenger。如果您拥有hotmail 或者MSN的邮件账号，那么，您就可以使用该账号直接登录MSN Messenger ，而无需再申请新的账号了。利用MSN Messenger进行个人的即时通信和群体的群发这些功能将会保留在新的版本中。另外，MSN Messenger 6.0还会加入聊天背景，并可以保存聊天记录。
下载地址
http://99rj.cn/soft/2/31/2006/200621318998.html
MSN Messenger 是微软公司推出的即时消息软件，凭借该软件自身的优秀的性能，目前在国内已经拥有了大量的用户群。使用MSN Messenger可以与他人进行文字聊天，语音对话，视频会议等即时交流，还可以通过此软件来查看联系人是否联机。MSN Messenger 界面简洁，易于使用，是与亲人、朋友、工作伙伴保持紧密联系的绝佳选择。使用您已有一个Email地址，即可注册获得免费的MSN Messenger的登录账号。在使用之前，强烈建议阅读(http://china.msn.com/Messenger/3steps/)三步法，快速启用 MSN Messenger。如果您拥有hotmail 或者MSN的邮件账号，那么，您就可以使用该账号直接登录MSN Messenger ，而无需再申请新的账号了。利用MSN Messenger进行个人的即时通信和群体的群发这些功能将会保留在新的版本中。另外，MSN Messenger 6.0还会加入聊天背景，并可以保存聊天记录。
下载地址
http://99rj.cn/soft/2/31/2006/200621318998.html
订阅：
博文 (Atom)