Aurelio Calegari

Hi,

Just to share I passed Part I yesterday (25 June) with 85%. I bought the study guide PDFs from The Open Group and also TOGAF Pass 4 Sure test simulator.

What I found out:
- The PDFs came with bonus questions besides the two full tests in the Foundation Study guide;
- Pass 4 Sure appears to have copied most of the questions from the official material. Was a bit of a waste of money.
- I have done the three sample exams on the openarch site. They are slightly harder than the PDF samples and the actual exam.

I studied for 4 weeks, average 1h a day. Now, started preparing for part II.

I noticed that the Open Group directory has already many people listed who have passed the test on the 25/6 but haven't seen me there neither received any email from the Open Group. They do say it might take up to 6 working days though. What's the average time to get contacted to complete the certification?

Cheers
Aurelio

Hello,

I'm trying to access the AppManagement MBeam through WebSphere Soap facilities. Here's the code:

//Setup security/conn props... Properties connectProps = new Properties(); connectProps.setProperty(AdminClient.CONNECTOR_TYPE, AdminClient.CONNECTOR_TYPE_SOAP); connectProps.setProperty(AdminClient.CONNECTOR_HOST, "remote_host..."); connectProps.setProperty(AdminClient.CONNECTOR_PORT, "remote_port..."); connectProps.setProperty(AdminClient.USERNAME, "wasadm"); connectProps.setProperty(AdminClient.PASSWORD, "my_secret"); connectProps.setProperty(AdminClient.CONNECTOR_SECURITY_ENABLED, "true"); connectProps.setProperty("com.ibm.SOAP.ConfigURL", "file://.../soap.client.props"); connectProps.setProperty("javax.net.ssl.trustStore", dir+"DummyClientTrustFile.jks"); connectProps.setProperty("javax.net.ssl.keyStore", dir+"DummyClientKeyFile.jks"); connectProps.setProperty("javax.net.ssl.trustStorePassword", "WebAS"); connectProps.setProperty("javax.net.ssl.keyStorePassword", "WebAS"); //Get Client AdminClient adminClient = AdminClientFactory.createAdminClient(connectProps); //Get AppManagement AppManagement appMgmt = AppManagementProxy.getJMXProxyForClient(adminClient);

When code reaches line:
AppManagement appMgmt = AppManagementProxy.getJMXProxyForClient(adminClient);

It blows up a big fat AdminException:
com.ibm.websphere.management.exception.AdminException: ADMA0089E: The AppManagement MBean is not found.
at com.ibm.websphere.management.application.AppManagementProxy.<init>(AppManagementProxy.java:131)
at com.ibm.websphere.management.application.AppManagementProxy.getJMXProxyForClient(AppManagementProxy.java:75)

What's weird is that there's no "AppManagement" MBean available for this application. If I execute the following code:

Set s = adminClient.queryNames(null, null); for(Object o : s){ ObjectName discoverybean = (ObjectName) o; System.out.println(discoverybean.getKeyProperty("type")); }

I see many object types available, including "ApplicationManager", but cannot find AppManagement MBean.

My system config is:

IBM WebSphere Application Server - ND, 6.0.2.23
Build Number: cf230739.19
Solaris OS
Cluster of 6 nodes

Does anybody have any idea on how to "install the AppManagement MBean" or making it available somehow?

Thank you very much!

Aurelio

Hi,

Take a look at this article http://www.onjava.com/pub/a/onjava/2005/06/29/spring-ejb3.html

It's a bit old (2005) but still a thing for non-standard enthusiasts to think about. The performance depends on how you architect and develop your systems. Of course that small systems do not require a standard deployable and distributalbe component for services such as EJB. That's true EJB brings overheads over spring, but it's designed for huge load and scalable systems. It makes your application natively service oriented. Other applications built with Java tech can easily reuse those deployed components. Other applications written in other platforms can also access EJB exposed as WS.

Regards

Aurelio

Originally posted by Srikanth Nittala:
Mine is a classic JEE application with this flow ( JSF + EJB + Oracle) on OC4J.

That's a robust environment. Also consider using JPA over Toplink. Is it OC4J 10g 10.1.3.3? Be aware there are a few bugs on OC4J in regard of EJB3, but nothing that would compromise the application.

Originally posted by Srikanth Nittala:
In the EJB3 books and Sun's JEE5 tutorial i ve read so far, they always have an EJB ( Session bean) thats filled with business logic and calls to DB via Entity Manager(injecting it) .
But is it a good practice to have business logic and DB calls in EJB that way? Now if you add service class(using Spring) or an DAO ( that does DB calls for each entity) you lose the power of injections and container-managed Entity managers. And I dont see the use of Spring services here as i think it is an overhead code for a simple flows like CRUD.
So in short i guess my question is " Is it ok to have all the business logic in session facade EJB itself? Isnt the facade EJB supposed to be neat and clean just doing security and transactions? What are the best practices for JEE architecture?

It's not good practice to keep business logic withing EJB. Regarding where to place the business logic, I would recommend you to place them in POJOs realizing, thus, the Application Service J2EE pattern. EJB is a thin application layer. EJB is rather a way to expose services to the outside world. You may inject the EntityManager within EJB and pass it as an argument of the Application Service POJO. Take a look at the J2EE Core Patterns 2nd Ed. Study the Application Service Pattern.

You don't need DAOs if you're using App Service + JPA, because JPA is itself a domain store. You may want to use DAOs when you're encapsulating access to legacy systems either through using raw JDBC directly or emulating a screen scraper. You may want to combine App Service + JPA for trivial stuff and App Service + DAO to run stored procedures, for example.

Don't forget to set up TWO connection pools. One for the JPA other for the DAOs itself.

Regards

Hello,

I'm using EJB3 and the systems I have architected so far present good performance, scalability and extensibility along with other non-functional desirable qualities.

The thing about EJB is that, as stated before, it's a specification and no matter what's your Java EE infrastructure is (JBoss, WebSphere, OC4J, etc). All of them must comply with that specification. Every single developer who wants formal education on Java EE will learn how to use EJB. Every single person who want a certication on Java EE will have to learn EJB. So, by choosing EJB you're always choosing a long term technology that we know will be out there for years and there will be always qualified people to work on that system.

Even those ones who want to get certified in EJB3 must learn how to interoperate them with previous EJB versions. So, it makes EJB choice even safier. EJB3 brings all advantages the EJB model enforces plus guarantee it won't be forgotten.

The server guys (server providers) who build WebSphere, JBoss and so on spend a great deal of time, effort, and money on the EJB container. They try to make the best EJB container for us: LET'S USE IT! The thing is who you architect your solution. For huge systems you might want to sperate presentation from biz phisically, and then you go for remote interfaces. It'll bring some delay and overhead, but in the big picture, your system will scale even more and will be ready to serve thousands of users.

That's all my personal opinion. I have nothing against Spring or hibernate. But the closer we stay the specification, the safier it'll be for finding qualified people in the future to maintain that system. What's more, the system will also address functional and systemic qualities. All depends on how it's build.

Thanks!

Scott,

Thanks for your contribution. Yes, I believe that there are even worse J2EE architectures: Mankind has unlimited capacity to come up with good things and bad things.

Regards,

Aurelio

Hello All,

Well, I have here a case I'd like to discuss with you all. Recently I start working in a new project for a huge insurance company. My company is one among a number of companies that were hired to work in a huge and ambicious downsizing project.

We have received an architectural document which we are required to follow strictly. The thing is that they are enforcing the use of EJBs in every single tier. They exploded the business and application tier into sub-tiers and within these tiers they have a number of EJBs, one calling another.

Let me first draw the basic structure proposed:

Presentation tier (WAR):
JSP -> Action -> Delegate (so far so good)

Business tier split into (no problem at all for now):

Application tier, and

Component tier

Integration tier
DAOs

That's all pretty plain classic and known architecture, but then they define what the componets are:

ApplicationFacadeEJB ---> ComponentFacedeEJB --> ComponentEJB --> DAOEJB --> JPA Entity

Where:

ApplicationFacadeEJB: Will expose business services for presentation tier. This is the application tier and is accessed by a business deleagete (so far so good).

ComponentFacadeEJB: Will expose business component service. If presentation tier want to access biz components, it'll happen passing through this component facade...

ComponentEJB: This guy is also an EJB and is the biz rules hoster. So... what's the point??? It alredy has a "component facade" that IS an EJB... Ok, let's go on...

DAOEJB: A simple CRUD guy who uses JPA to dumbly insert, update, retrieve, delete... They say it must also be an EJB.

What are the practices I have learned from industry:

Business Rules should be placed on POJOs, preferrebly. The J2EE pattern Application Services comes to the rescue.

Data Access Objects are generally also pojos, and once they are accessed internally the application there's no need to make it EJB. If we're using JPA already I see no need for DAOs, as long as we won't run any stored procedures or any other kind of integration.

A Facade, generally a Session Facade is an EJB who would expose services to an external environment. Then all the dependend pojos would have EJB transaction, security and so on inherited, because they are called by that EJB. I see no problem with the ComponentFacade. It's my understanding that a ComponentFacade would be nice idea if you want to expose services to components from outside the VM that comes from other business tiers...

Other modules were built and they have by now more than 900 EJBs... When they try to deploy they get a big fat OutOfMemoryError. EJB container will create a pool of each type of EJB, and thus that explains a lot the memory problem, and I tell you: the problem is not Horse Power.

My first thought is that EJB is being used naively. They could optimize resources by simply reducing the nnumber of EJBs being used. For example, to display a sigle name in the screen, it has to go at least 4 EJBs to get to the database.

I'd like to here from you what you think.

Thanks in advance.

Aurelio

Hi Peer,

Excelent article. Thanks for the information.

Aurelio

Hello Web Service Gurus,

Could you please help me with this topic [within Web Services forum in javaranch]

Thanks in advance!

Aurelio

Hey Web Services Gurus,

I'm almost positive that web services have better performance over the network compated to EJB Remote calls.

Can anyone confirm that or point if I'm wrong? Do you know a web site or article which compare their performance ?

Thanks very much in advance

Aurelio

I forgot to mention I'm using ICEFaces...

Hello All,

I'm having troubles to work with datables that are within another datatable and each nested datatable has its own datapaginator. Here's a sample code:

<ice:dataTable value="#{parentGroup.itens}" var="item" cellpadding="0" width="550px" columnClasses="leftColumn,middleColumn,rightColumn" id="data" rows="10"> <!-- contract/expand column --> <ice:column> (...) </ice:column> <!-- Detalhamento --> <ice:column> <f:facet name="header"> <ice:outputText value=" "/> </f:facet> <ice:panelGroup styleClass="#{item.rowStyleClass}"> (...) <!-- Itens.... --> <ice:panelGrid columns="1" cellspacing="0px"> [B]<!-- NESTED DATATABLE -->[/B] <ice:dataTable value="#{item.expandedChildren}" var="itemChild" cellpadding="0" width="336px" columnClasses="leftColumn,middleColumn,rightColumn" id="dataChild" rows="4"> <ice:column> <ice:panelGrid columns="1" cellspacing="0px" cellpadding="0px" width="20px"> (...) </ice:column> <ice:column> (...) </ice:column> </ice:dataTable> [B]<!-- PAGINATE NESTED TABLE -->[/B] <ice:panelGrid columns="1" styleClass="scrollerTableChild2" columnClasses="standardTable_ColumnCentered" visible="#{item.expanded}"> <ice:dataPaginator id="test1" for="dataChild" fastStep="10" pageCountVar="pageCount" pageIndexVar="pageIndex" paginator="true" paginatorMaxPages="9" > <f:facet name="first" > <ice:graphicImage url="css/xp/css-images/arrow-first.gif" style="border:none;"/> </f:facet> <f:facet name="last"> <ice:graphicImage url="css/xp/css-images/arrow-last.gif" style="border:none;" /> </f:facet> <f:facet name="previous"> <ice:graphicImage url="css/xp/css-images/arrow-previous.gif" style="border:none;" /> </f:facet> <f:facet name="next"> <ice:graphicImage url="css/xp/css-images/arrow-next.gif" style="border:none;" /> </f:facet> <f:facet name="fastforward"> <ice:graphicImage url="css/xp/css-images/arrow-ff.gif" style="border:none;" /> </f:facet> <f:facet name="fastrewind"> <ice:graphicImage url="css/xp/css-images/arrow-fr.gif" style="border:none;" /> </f:facet> </ice:dataPaginator> <ice:dataPaginator id="test2" for="dataChild" rowsCountVar="rowsCount" displayedRowsCountVar="displayedRowsCountVar" firstRowIndexVar="firstRowIndex" lastRowIndexVar="lastRowIndex" pageCountVar="pageCount" pageIndexVar="pageIndex" > <ice:outputFormat value="P�gina {4} / {5}" styleClass="standard" > <f:param value="#{rowsCount}" /> <f:param value="#{displayedRowsCountVar}" /> <f:param value="#{firstRowIndex}" /> <f:param value="#{lastRowIndex}" /> <f:param value="#{pageIndex}" /> <f:param value="#{pageCount}" /> </ice:outputFormat> </ice:dataPaginator> </ice:panelGrid> </ice:panelGrid> </ice:panelGrid> </ice:panelGroup> <f:facet name="footer"> <ice:outputText value="#{grupoDeItensManager.sum}" style="text-align: right;"> <f:convertNumber maxFractionDigits="2" groupingUsed="true" currencySymbol="R$ " maxIntegerDigits="7" type="currency"/> </ice:outputText> </f:facet> </ice:column> </ice:dataTable> </ice:panelGrid> [B]<!-- PAGINATE PARENT -->[/B] <ice:panelGrid columns="1" styleClass="scrollerTable2" columnClasses="standardTable_ColumnCentered" > <ice:dataPaginator id="scroll_1" for="data" fastStep="10" pageCountVar="pageCount" pageIndexVar="pageIndex" paginator="true" paginatorMaxPages="9" > <f:facet name="first" > <ice:graphicImage url="css/xp/css-images/arrow-first.gif" style="border:none;"/> </f:facet> <f:facet name="last"> <ice:graphicImage url="css/xp/css-images/arrow-last.gif" style="border:none;" /> </f:facet> <f:facet name="previous"> <ice:graphicImage url="css/xp/css-images/arrow-previous.gif" style="border:none;" /> </f:facet> <f:facet name="next"> <ice:graphicImage url="css/xp/css-images/arrow-next.gif" style="border:none;" /> </f:facet> <f:facet name="fastforward"> <ice:graphicImage url="css/xp/css-images/arrow-ff.gif" style="border:none;" /> </f:facet> <f:facet name="fastrewind"> <ice:graphicImage url="css/xp/css-images/arrow-fr.gif" style="border:none;" /> </f:facet> </ice:dataPaginator> <ice:dataPaginator id="scroll_2" for="data" rowsCountVar="rowsCount" displayedRowsCountVar="displayedRowsCountVar" firstRowIndexVar="firstRowIndex" lastRowIndexVar="lastRowIndex" pageCountVar="pageCount" pageIndexVar="pageIndex" > <ice:outputFormat value="P�gina {4} / {5}" styleClass="standard" > <f:param value="#{rowsCount}" /> <f:param value="#{displayedRowsCountVar}" /> <f:param value="#{firstRowIndex}" /> <f:param value="#{lastRowIndex}" /> <f:param value="#{pageIndex}" /> <f:param value="#{pageCount}" /> </ice:outputFormat> </ice:dataPaginator> </ice:panelGrid>

The result is that I can only navigate through the pagination of the FIRST nested element. I can also navigate through the pagination of the parent datatable. If I try to navigate through the pagination of any other nested datapaginator that's not the first one, it does not work.

Any thoughts?

Thanks in advance.

Aurelio

Hi Jim,

Please, read the thread from the begining. They'll be available only on Sept 19-20 on that site.

Thanks

Aurelio

Hi Prav,

I have used the Rational Software Architect 6.0 - That's a nice one. Good luck!

Thank you

Aurelio

Hi Ajaz,

Part III is really piece of cake. Pretty easy if you really built your solution well and addressed the requirements. I spent arround 45 minutes writing for the 4 questions.

My suggestion before you go for the essay exam:

Make sure you understand very well the 8 non-functional requirements : scalability, security, performance, etc.

Make sure you have a clear understanding on the persistence approach you have chosen for your solution.

Make sure you know how to handle user session and so as well as you're able to justify your solution

You must have a very good understanding on how your system works and how client tiers talk to business tier. You should never save time on thinking your solution over and over. The more you think it over, the more you'll be able to refine and understand what you're doing.

There's no big deal with part III - The success on part III depends only on how well you have addressed the requirements as well as you understand both JEE and your approach.

Hope this helps

Regards

Aurelio