I found a great resource for people starting out developing Web Services on the WebLogic platform via Jason’s blog. In his blog entry, Jason talks about the two “underground” code repositories maintained by BEA engineers that are not officially sanctioned by BEA’s management. The first link to http://webservice.bea.com/ fails but the second link to Manoj’s page works. Manoj is a BEA engineer and he has created a great site for his Web Services tutorial. If you are new to Web Services in the WebLogic world, you must check out this site. Now why didn’t I know about this site when I was putting together my Web Services class?

Update: (09/03) Ravi – Thanks for the update. It appears that http://webservice.bea.com is working now.

As a recurring feature, I post a list of books that I am currently reading. I am a voracious book collector and (usually) reader as well. With a new baby that’s less than 2 months old, reading time is at a premium and so I’ve built up quite a backlog. Books I am currently reading include:

• Expert One-on-One J2EE Development without EJB by Rod Johnson, Juergen Hoeller
• Tiger: A Developer’s Notebook By David Flanagan, Brett McLaughlin
• Better, Faster, Lighter Java By Bruce A. Tate, Justin Gehtland
• Programming Jakarta Struts, 2nd Edition by Chuck Cavaness
• Enterprise Service Bus By Dave Chappell
• Tapestry in Action by Howard M. Lewis Ship

Some of the non-technical books that I am currently reading (or collecting dust in my new book pile) are:

• Bushworld: Enter at your own risk by Maureen Dowd
• What to Expect the First Year, Second Edition
• Inside the Kingdom : My Life in Saudi Arabia by Carmen Bin Ladin

My blog entry on the WebLogic deployment issue was just posted on the WebLogic Developers Journal site.  Check it out @ http://www.sys-con.com/story/?storyid=46106&DE=1

If you’ve haven’t run into this issue yet, you’ll appreciate this little nugget. I’m not sure if this is a feature or a bug in WebLogic’s deployment infrastructure. I ran into this issue a while back and completely forgot about it, till I ran into it this weekend.

A little background first: Most people that deploy WebLogic in a corporate environment take advantage of the concept of domains, admin and managed servers. A domain is the basic administration unit for WebLogic Server instances and consists of one or more WebLogic Server instances (and their associated resources) that you manage with a single Administration Server. For application deployment mode, WebLogic offers the ability to ‘stage’ your applications on the Administration server, which determines how the deployment files (ear, war, etc) are made available to target servers. WebLogic Server provides three different options for staging files: stage mode, nostage mode, and external_stage mode. I personally prefer and use the stage mode where the admin server first copies the deployment unit source files to the staging directories of target servers. The target (managed) servers then deploy using their local copy of the deployment files using the redeploy feature or via a simple staggered restart. This allows for clean deployment across the cluster and HttpSession replication allows users to failover without taking an outage of the application.

This really works well unless you add another ejb jar or war file to your existing, deployed and targeted application. So I just added a new customer.war file to my existing ear file and modified the application.xml to appropriately list the new web module. You would think that deploying the new ear file with the new war file would work as expected, but alas it doesn’t. WebLogic will redeploy the new ear file but not target and deploy the new war file as it wasn’t explicitly deployed using the WebLogic deploy tool or the console. The managed or target servers will have the new code but the new war or ejb jar just won’t be targeted and deployed on that server. Bizarre, right? I think so but I am not sure if this is a bug or a feature. To correctly target and deploy a new module that’s part of an existing and currently targeted/deployed application, you will need to use weblogic.Deployer tool to tell WebLogic about the new addition to the existing ear file. Sample command:

java weblogic.Deployer -adminurl http://admin:8001 -username xxx -password xxx -deploy -targets customer@app_name -name app_name -source ./applications/app_name.ear

More information about weblogic.Deployer is @ http://e-docs.bea.com/wls/docs81/deployment/tools.html#999152

Thanks Brennan for reminding me – I almost forgot about the upcoming Wisconsin Java Users Group meeting on Wednesday, August 25th. The topic for this meeting is Tapestry and Erik Hatcher will give the talk. The goal of this talk is to introduce Tapestry gently through interactive demonstrations. For the uninitiated, Tapestry is an open-source, all-Java framework that offers true event-driven, component-oriented web development. I am planning on attending this meeting as I am trying to learn more about Tapestry.

So what’s new, right? In typical Sun fashion, Sun asked JDocs to pull off the J2SE, J2ME and J2EE API’s from the JDocs site. According to the JDocs.com Update from Rick Ross, Sun claims that its business interests are not served by allowing them to be included in the JDocs site. Ok – I can that Sun would be afraid if JDocs would keep old and out-dated API’s out there but that wouldn’t be the case here. The update continues to state that Sun is adamant that the javadocs for Sun APIs must be accessible solely and exclusively from sun.com – nowhere else. I wonder if Sun is afraid that people would comment on the APIs?

This is just another in a series of many boneheaded moves by Sun. Not the first and won’t be the last. Come on Hani – Ready, Set, Bile!!! 

Just got an email from BEA announcing something called BEA dev2dev Live! BEA dev2dev Live! is an online technical event center bringing together live webinars and both downloadable and on-demand training events. BEA dev2dev Live is focused on educating and training developers, architects, and administrators with key tips, tricks, best practices, and in-depth “how-to” sessions from top BEA engineers and customers. Looks pretty interesting at first glance – Another one for the bookmarks.

The landscape of application frameworks, especially in the web tier has really matured and grown where they are many quality choices available for the developer. My team and I are in the process of starting some major development work on a bunch of new J2EE applications and I’m sticking my head up and trying to look at what’s available in terms of frameworks in the web-tier.

Most of the applications that we are going to write or re-write are going to consume existing services that encapsulate business logic, integration, persistence, etc. In my company, I’ve standardized on the use of ‘services’ and I use the word loosely, to enable loosely coupled application and reuse of business logic. Most of our services are stateless, built using EJB’s (no entity beans, CMP or otherwise) and these services isolate the consumer from all of the transactional, integration type of stuff. All of these services are exposed directly via the EJB interface. Some services are also enabled as Web Services with things like JAX-RPC, Axis and WebLogic’s EJB to Web Services Ant tasks. All of the Web Services interfaces or methods are custom coded methods that return a String of XML as it’s output. From the Java side, the object graph is serialized to XML and the client can consume the XML being returned using the Schema provided, if they choose to do so. If not, the XML can be deserialized back into Java using XStream or XMLBeans. Non-Java clients can also consume these services and parse the returned XML using their own mechanisms. These services have enabled loose coupling and clean integration by .NET clients to our Java/J2EE backend.

Back to the web tier – My first Java application at this company was written in mid 1999. This was a transaction trading system deployed under WebLogic 4.5, written as a bunch of servlets communicating to a stateful EJB in the backend. Since then, our application development has gotten a little more complicated with things like Broadvision and other personalization and portal technologies. Most of our web development today is done using Struts with a good mix of JSTL, interacting with our backend services. As I look to design and architect our next applications, I am starting to look around and wonder if Struts is still the best way to go or should I really explore some other frameworks. To answer my question, I’ve spent a little time of the last few weeks digging into my choices are here are some of my choices.

1. Struts – This is a known entity and my team has extensive experience in building Struts applications and probably a safe choice, but Struts has its issues. (That’s another blog entry )
2. Struts + Tiles – I am not a fan of Tiles and it’s probably because I haven’t given Tiles enough time but the integration with Struts is nice and the ability to have templating, multi-channels support, layout control and reuse is pretty powerful.
3. Struts + SiteMesh – I’ve only briefly read about SiteMesh but everything I read makes it look attractive enough where I should take a critical look at it and give it a deeper look. SiteMesh is another web-page layout and decoration framework that integrates with Struts.
4. Tapestry – Tapestry is another framework I’ve heard great things about but haven’t given it any time. Just bought Tapestry in Action, written by Howard Lewis Ship, the creator of Tapestry and I am hoping it will help me get more information. The issue of learning curve also comes into play with anything new and I’m trying to balance the benefits the new framework provides and the learning curve required to get proficient in the framework and its subtleties.
5. WebWork – I knew I would get yelled at if I didn’t mention WebWork in this list. Rossi, are you happy now? The same issue of learning curve comes into play here.
6. Spring – Spring includes a configurable MVC web framework that’s very similar to Struts and I love the idea of lightweight containers and IoC but going with Spring, like other framework includes the standard learning curve. I’ve personally played around with Spring a lot and feel that the learning curve isn’t as steep when compared to other frameworks, but there is time required to come up to speed.
7. JavaServer Faces – I attended 2 sessions by David Geary earlier this year at the local No-fluff-just-stuff Java symposium and I didn’t walk away with a warm-n-fuzzy feeling about JSF. It’s an option, but I think I am probably not going to explore this option.

I know I am leaving out tons of other choices like Turbine, Velocity, WebLogic Workshop and Page Flow among other frameworks.

I’ve narrowed down my choices and have gotten down to Struts/SiteMesh, Tapestry and Spring as my final choices. I am in the process of creating some proof-of-concept applications using each of the frameworks to get a better understanding of the strengths and weakness of each framework as well as create some blueprint apps for my team to use as a starting point for their development effort.

I would love to hear from anyone that has any thoughts and opinions on my choices above and any jewels that you can share before we jump in and start our development effort.

My daughter is only 4 weeks old today and she already has her own blog. Kids today Check it out @ http://www.katiesblog.com