- 浏览: 1921798 次
- 性别:
- 来自: 福建莆田@广州
文章分类
最新评论
-
YuLimin:
关于开发者版本费用等问题请见:Have questions? ...
IBM于2009.06.19推出开发者免费版WebSphere Application Server -
YuLimin:
1、传统WAS : WebSphere Application ...
IBM于2009.06.19推出开发者免费版WebSphere Application Server -
chenlei65368:
咋加啊,总司令
微信JavaEye老炮群的入群标准-2009年之前注册JavaEye的技术人员 -
kkllmey:
怎么进呢。留个群号吧。
微信JavaEye老炮群的入群标准-2009年之前注册JavaEye的技术人员 -
Mr.TianShu:
3792274
微信JavaEye老炮群的入群标准-2009年之前注册JavaEye的技术人员
1. Digest the requirements:
Read the requirements very carefully and understand it. Take at least ten days to digest all the requirements because it is not complete and confusing at times. Grasp everything and have a big picture always. Give yourself a lot of time to understand repeatedly before put your hands on solving the problem. Where ever you have problem understanding or you find that something is missing make a not of it. This will help you make some assumptions later.
2. Class Diagram:
I started the part2 with Class diagram based on the Domain model and identified the Subsystems. I had only one class diagram with 15 classes and 5 subsystems. I was very careful about the Associations, aggregation, composition, navigatability, relationships (Classification, Generalization, Dependency, Realization) and cardinalities. I identified whatever attributes required and its accessibility to have in every class. I did not mention any operations or methods in the class diagram. For some of the classes I did not even give any attributes. I gave all the relationships some name that explains the interactions between the classes. I was very careful in giving the Stereotypes wherever required.
Do not get into too much detail and view everything from high level. That is what is expected for this architect level exam. At the same time make sure that do not lose anything. It is very important that how best you make others understand especially the marker with one class diagram. I have seen others break down the class diagram into more than one class diagram. Detailed class diagram is not necessary at this architecture level and will make others confuse and complicate the things rather than help understand
easily.
Component/Collaboration I cannot advice much here bcos I haven't scored 100%.
3. Component Diagram:
I divided the whole requirement into subsystems and made component diagrams for each subsystems. I have heavily used J2EE design patterns.
4. Sequence Diagram:
I made just one sequence diagram for each use case. Some of the use case may be little complicated to explain within a single page. Better to split the sequence diagram in this case so that it is not cluttered and complete the whole sequence.
5. Deployment diagram:
I had one deployment diagram according to the requirement. The deployment requirement was clear about the physical locations and machines. When I made the deployment diagram I was pretty clear where when the right protocols are being used and how the subsystems, legacy systems interact. Here I mentioned which component goes where and how each type of client accesses the system. Even though providing the deployment diagram is not a requirement I would suggest for your own sake and for the
examiner create a neat diagram.
6. Framework:
Even though I went through Struts and Petstore architecture I did not use any of them. I designed my own framework and used it for the exam. However whatever framework you use it should be portable and should support the non-functional requirements.
7. Consistency:
Once you made all the diagrams check for consistency with all diagrams. Go through each diagram and try to improve the diagrams to satisfy all the functional requirements. Every time you make any changes to any diagram ensure the consistency among all the diagrams and assumptions.
8. Assumptions document:
This is the piece I had little trouble with which many guys had not a problem. I did not know what kind of assumptions and at what level do I need to make assumptions. Out of patience I made 2-3 pages of assumptions. My suggestion is that we don't need to go into too much detail here again.
9. Tools
UML Diagrams: As per the requirement all the diagrams should be UML compliant. I
used MagicDraw for Class Diagram and Component Diagram. When I started sequence diagram this tool did not let me allow drawing more than certain number of objects because I had the evaluation version. So I had to make the sequence diagram in Rational Rose. My suggestion is that adopt a good tool.
Documentation: For documentation use a neat HTML tool like FrontPage. Do not clutter the document with unnecessary fine details; the marker may not have patience to go through the entire document. So make it simple and neat and do not miss any essential points.
10. Service level /Non-functional requirements:
The non-functional requirements in J2EE architecture are performance, scalability, reliability, availability, manageability, extensibility, maintainability and security
11.Uploading the assignment:
Once done with the assignments revisit all the diagrams and assumption document. Try to make it smaller size. I heard that some people had problem uploading because of the fat assignment. I had problem uploading because I did not have access right to upload. I sent a mail to Prometric asking permission and got it the same day luckily. So make sure that you have access right to upload before the Part-III exam.
12. Part-III exam.
Give the Part-III exam ASAP. I uploaded the assignment the evening and gave the exam the next day afternoon during my lunch break. If you have done your architecture assignment according to the J2EE specification yourself Part-III is very simple. The four essay questions are basically to address the Non-functional requirements like performance, scalability, reliability, availability, manageability, extensibility, maintainability and security. Other things might include how are you taking care of your architecture to address transactions, persistence, authentication, authorization, et al. Here again my suggestion is to make it neat and simple. The marker does not need to be
explained with the theory behind transaction. Rather give him clear answer as to how did your design address the transaction.
13. Reading:
1.<SCEA by Mark Cade is a very good book for part-II. I based by level of design on the example given in this book. >
2. <Core J2EE patterns>
3. <Java Petstore Application from the Java blueprint>
4. serveside.com
5. <UML Distilled>
14. Exam Result:
This is the long wait for about 3-weeks to get the result and you cannot do anything but wait.
Read the requirements very carefully and understand it. Take at least ten days to digest all the requirements because it is not complete and confusing at times. Grasp everything and have a big picture always. Give yourself a lot of time to understand repeatedly before put your hands on solving the problem. Where ever you have problem understanding or you find that something is missing make a not of it. This will help you make some assumptions later.
2. Class Diagram:
I started the part2 with Class diagram based on the Domain model and identified the Subsystems. I had only one class diagram with 15 classes and 5 subsystems. I was very careful about the Associations, aggregation, composition, navigatability, relationships (Classification, Generalization, Dependency, Realization) and cardinalities. I identified whatever attributes required and its accessibility to have in every class. I did not mention any operations or methods in the class diagram. For some of the classes I did not even give any attributes. I gave all the relationships some name that explains the interactions between the classes. I was very careful in giving the Stereotypes wherever required.
Do not get into too much detail and view everything from high level. That is what is expected for this architect level exam. At the same time make sure that do not lose anything. It is very important that how best you make others understand especially the marker with one class diagram. I have seen others break down the class diagram into more than one class diagram. Detailed class diagram is not necessary at this architecture level and will make others confuse and complicate the things rather than help understand
easily.
Component/Collaboration I cannot advice much here bcos I haven't scored 100%.
3. Component Diagram:
I divided the whole requirement into subsystems and made component diagrams for each subsystems. I have heavily used J2EE design patterns.
4. Sequence Diagram:
I made just one sequence diagram for each use case. Some of the use case may be little complicated to explain within a single page. Better to split the sequence diagram in this case so that it is not cluttered and complete the whole sequence.
5. Deployment diagram:
I had one deployment diagram according to the requirement. The deployment requirement was clear about the physical locations and machines. When I made the deployment diagram I was pretty clear where when the right protocols are being used and how the subsystems, legacy systems interact. Here I mentioned which component goes where and how each type of client accesses the system. Even though providing the deployment diagram is not a requirement I would suggest for your own sake and for the
examiner create a neat diagram.
6. Framework:
Even though I went through Struts and Petstore architecture I did not use any of them. I designed my own framework and used it for the exam. However whatever framework you use it should be portable and should support the non-functional requirements.
7. Consistency:
Once you made all the diagrams check for consistency with all diagrams. Go through each diagram and try to improve the diagrams to satisfy all the functional requirements. Every time you make any changes to any diagram ensure the consistency among all the diagrams and assumptions.
8. Assumptions document:
This is the piece I had little trouble with which many guys had not a problem. I did not know what kind of assumptions and at what level do I need to make assumptions. Out of patience I made 2-3 pages of assumptions. My suggestion is that we don't need to go into too much detail here again.
9. Tools
UML Diagrams: As per the requirement all the diagrams should be UML compliant. I
used MagicDraw for Class Diagram and Component Diagram. When I started sequence diagram this tool did not let me allow drawing more than certain number of objects because I had the evaluation version. So I had to make the sequence diagram in Rational Rose. My suggestion is that adopt a good tool.
Documentation: For documentation use a neat HTML tool like FrontPage. Do not clutter the document with unnecessary fine details; the marker may not have patience to go through the entire document. So make it simple and neat and do not miss any essential points.
10. Service level /Non-functional requirements:
The non-functional requirements in J2EE architecture are performance, scalability, reliability, availability, manageability, extensibility, maintainability and security
11.Uploading the assignment:
Once done with the assignments revisit all the diagrams and assumption document. Try to make it smaller size. I heard that some people had problem uploading because of the fat assignment. I had problem uploading because I did not have access right to upload. I sent a mail to Prometric asking permission and got it the same day luckily. So make sure that you have access right to upload before the Part-III exam.
12. Part-III exam.
Give the Part-III exam ASAP. I uploaded the assignment the evening and gave the exam the next day afternoon during my lunch break. If you have done your architecture assignment according to the J2EE specification yourself Part-III is very simple. The four essay questions are basically to address the Non-functional requirements like performance, scalability, reliability, availability, manageability, extensibility, maintainability and security. Other things might include how are you taking care of your architecture to address transactions, persistence, authentication, authorization, et al. Here again my suggestion is to make it neat and simple. The marker does not need to be
explained with the theory behind transaction. Rather give him clear answer as to how did your design address the transaction.
13. Reading:
1.<SCEA by Mark Cade is a very good book for part-II. I based by level of design on the example given in this book. >
2. <Core J2EE patterns>
3. <Java Petstore Application from the Java blueprint>
4. serveside.com
5. <UML Distilled>
14. Exam Result:
This is the long wait for about 3-weeks to get the result and you cannot do anything but wait.
=================================================================================
As one or two people have emailed me for advice, I thought I'd pop up a few notes here on my take on how to approach parts 2 and 3 of the Java 2 Architect Certification. Note that I don't cover part 1 - that part is more than adequately covered by Aaron's notes and the messages on this group.
I'm not sure if Aaron or somebody wants to pull these notes out and add them to a document in the files section of some sort?..
What follows is *my* approach to parts 2 & 3. I'm not saying this is how *you* should do it, but all I know is that this approach got me an over 90% score, which is more than good enough (in fact you only need 70% to pass). Please, please do not email with specific questions on design approaches and choices: that's what you are supposed to be doing as part of the certification. Do note, however, that there are many, many ways to 'skin a cat': Sun aren't hung up on you building the 'perfect' solution - it doesn't exist - but they are keen for you to show *why* you made certain decisions, and what the pro's and con's of different approaches you considered were.
Anyway, here goes...
1.
Read all the requirements documents supplied very, VERY carefully. The requirements supplied by Sun are, IMHO, incomplete, contradictory and confusing in places. Give yourself TIME to digest these documents - say at least a couple of weeks. Re-read them over and over again and MAKE NOTES as you go along of any assumptions you make - and YOU WILL have to make some assumptions.
2.
Document your project submission properly. Don't just send off your submission with a quick list of what your diagrams are called and where they are located (you don't need this anyway as you'll HTML anchor them from your readme). Instead, write a proper, long HTML document that explains your approach. I had a section one which was my analysis of the project materials supplied, a section two which was my working assumptions coming out from the analysis (i.e. section one), a section three which was my design approach, and finally a section four which contained a brief description of my diagrams and HTML links to them. Make this document NEAT - get a decent HTML tool (i.e. don't just rely on Word) and TEST the neatness of your layout in at least two browsers. It may sound stupid, but you've no idea how many extra marks good, clean presentation can get you...
3.
Don't get lost in the detail. I can't believe how much 'guess the detail' is exchanged in messages on the group! Remember, the submission is about OVERALL ARCHITECTURE, not how many EJBs/Beans/Servlets/JSPs/Classes/Methods etc., etc. you need, or whether Fly-By-Night should be doing this, or that, or the other. Don't loose sight of the BIG PICTURE - as that's what you are supposed to be presenting: a well-considered, reasonable, flexible architecture that serves the main goals of the requirements.
Just because someone else on the group used an EJB/JSP/Servlet etc. where you used something different doesn't mean that your approach is wrong. Likewise, just because someone else has 50 more classes on their diagrams than you doesn't mean that you are missing something (in fact, I probably had half the number of classes I saw some people coming up with). Ditto the level of detail: don't litter you classes and diagrams with every method/attribute in the world; keep them simple, to the point, and easy to digest (remember, someone you'll never, ever meet has to read them and mark them - the last thing you'll want to do is confuse that individual.)
4.
Books. I used the following three books *only* for part 2 & 3. I don't believe you need any others. Obviously if you don't understand these books when you read them, then you do need some others! However if you can't understand these 3 books, you shouldn't really be attempting the certification in the first place...
Book 1: The Unified Modeling Language User Guide (Addison Wesley) - Booch, Rumbaugh & Jacobson. This book will help you with your diagrams no end. This is a longer book than Martin Fowler's UML distilled (also recommended if you are new to UML and want a quick taste) - and it repeats itself a lot - but it has better coverage of Component diagrams and stereotypes (er, and everything else UML).
Book 2: Designing Enterprise Applications with the Java2 Platform, Enterprise Edition (Sun Microsystems Press). This book is a fairly easy read, and is the SUN BIBLE on architecturing J2EE applications. I would call you A FOOL if your submission did not follow the basic approaches detailed in the book (even if you don't agree with them.) The way I look at it, there is NO WAY Sun can fail your submission when you base it heavily on there own architecture book.
NB. The above book has a final chapter that talks about the Sun Java Petstore demo. Get yourself the latest copy of the code from the Sun site, and note that it has changed a bit from that listed in the book (esp. the use of XML to drive the request, event and screen processing). Study the petsore demo code and the book HARD. This took me weeks to go through in detail, but I learnt a lot. And hey, it's free!
Book 3: Java 2 Platform Enterprise Edition Platform and Component Specifications (Sun Microsystems Press). OK, you don't really NEED this, but I find I can't live without it. It is the printed version of the Servlet/JSP/EJB specs. on the Sun site. I found it more convenient to have them in one book than download everything and print it all out. This book goes into way more detail than you'll need for the project, but it's always good when you want some clarification on low-level detail.
5.
Diagrams. Keep them clean and simple. I used Rational Rose. You can get a demo disk off them or download it from their site. This is the same tool that Sun used for the diagrams they supplied, and it's easy to save your work directly as HTML. Sorry I can't offer any more advice on other UML tools as Rational is the only one I've ever used.
Use UML notes, stereotypes and sensible naming conventions to add clarity to your diagrams. Make sure you document your naming conventions in the document I listed above as part of your submission.
Panic: Just three diagrams for the whole project submission! How on earth do I explain the universe of my submission in just three documents?!!!
Like I said earlier, keep it SIMPLE. Don't put on any extraneous classes. For instance, I didn't put ANY GUI classes (JSP, Swing, etc.) on my Sequence Diagram. Why? Well, they just made the bloody thing too big! At the end of the day the GUI interface is just a 'request generator', so why not just show requests as the start of your sequence diagram elements? Better still, what about translating requests to events? All that machinery could clutter the diagram even further. So, LEAVE IT OFF. Just show events as the entry points on your Sequence diagrams...
You see, in two simple steps you've halved the size of the Sequence diagram, leaving you to concentrate on showing how the Use Case Text's are actually processed by your 'back end' application architecture - and remember that's what you are being marked on: your ARCHITECTURE, not the VASTNESS of your diagrams. (NB. I got 100% for my Sequence diagram, so I must have got something right...)
Follow the same approach for all your diagrams - i.e. make sure they are logically consistent. This is pretty easy in Rose, as all your classes, etc. are stored in a repository, from which you select to place on your diagrams. A simpler tool may not offer this, so make sure you keep the consistency by checking all your diagrams side-by-side (and print them out first).
6.
Follow-up exam. Take it as soon as you make your submission. Take a copy of the document you submitted along with your submission to the test centre and re-read it a couple of times before taking the exam (you won't be able to take this document in with you to the examining room, of course). The aim here is to make sure your exam replies are consistent with your submission.
The exam questions are quite easy and fairly broad. Like the project, Sun wants you to concentrate on higher-level architectural choices, and the pro's and con's of various approachs, particularly the approach you chose for your submission. You will not be asked any detailed questions on EJBs/JSPs/etc., so relax!
The exam should take you no more than 10-15 minutes. I wasted time by not reading all the questions first, and therefore ended up repeating myself and having to go back and cut-n-paste answers around. Do yourself a favour and read all the questions first - I think there are only 4-5 of them anyway. Don't write too much. For detail, refer the examiner to the appropriate sections of the document you submitted.
Spend some (most) of the huge amount of extra time you'll have left over by re-reading your answers and cleaning them up: layout, spelling, consistency and getting the detail balance right. Maybe expand some of your replies by detailing a few alternative approaches to those you used in your submission, and why you rejected them. Maybe also add a few notes on the 'real world' implications of your approach: for instance, if you keep state in stateful EJBs, would this state automatically propagate across clustered servers in a highly scalable solution? If not, what alternative would you suggest in this scenario?
Anyway, that's it. My guide to parts 2 & 3. Really, if you read the books I listed above - especially Book 2 - and spend plenty of time studying the project requirements and the Sun Petstore demo there is no way you should fail. It's all down to plain hard work. How much it will take will vary from person to person, but I put over 100 hours or so, spread over a couple of months or more. Don't rush it, it costs too much money when you fail! Enjoy the experience, and make sure you take away from it much more than just the piece of paper that says you are a Sun Certified Archtiect.
All the best,
Steve Phelan.
I'm not sure if Aaron or somebody wants to pull these notes out and add them to a document in the files section of some sort?..
What follows is *my* approach to parts 2 & 3. I'm not saying this is how *you* should do it, but all I know is that this approach got me an over 90% score, which is more than good enough (in fact you only need 70% to pass). Please, please do not email with specific questions on design approaches and choices: that's what you are supposed to be doing as part of the certification. Do note, however, that there are many, many ways to 'skin a cat': Sun aren't hung up on you building the 'perfect' solution - it doesn't exist - but they are keen for you to show *why* you made certain decisions, and what the pro's and con's of different approaches you considered were.
Anyway, here goes...
1.
Read all the requirements documents supplied very, VERY carefully. The requirements supplied by Sun are, IMHO, incomplete, contradictory and confusing in places. Give yourself TIME to digest these documents - say at least a couple of weeks. Re-read them over and over again and MAKE NOTES as you go along of any assumptions you make - and YOU WILL have to make some assumptions.
2.
Document your project submission properly. Don't just send off your submission with a quick list of what your diagrams are called and where they are located (you don't need this anyway as you'll HTML anchor them from your readme). Instead, write a proper, long HTML document that explains your approach. I had a section one which was my analysis of the project materials supplied, a section two which was my working assumptions coming out from the analysis (i.e. section one), a section three which was my design approach, and finally a section four which contained a brief description of my diagrams and HTML links to them. Make this document NEAT - get a decent HTML tool (i.e. don't just rely on Word) and TEST the neatness of your layout in at least two browsers. It may sound stupid, but you've no idea how many extra marks good, clean presentation can get you...
3.
Don't get lost in the detail. I can't believe how much 'guess the detail' is exchanged in messages on the group! Remember, the submission is about OVERALL ARCHITECTURE, not how many EJBs/Beans/Servlets/JSPs/Classes/Methods etc., etc. you need, or whether Fly-By-Night should be doing this, or that, or the other. Don't loose sight of the BIG PICTURE - as that's what you are supposed to be presenting: a well-considered, reasonable, flexible architecture that serves the main goals of the requirements.
Just because someone else on the group used an EJB/JSP/Servlet etc. where you used something different doesn't mean that your approach is wrong. Likewise, just because someone else has 50 more classes on their diagrams than you doesn't mean that you are missing something (in fact, I probably had half the number of classes I saw some people coming up with). Ditto the level of detail: don't litter you classes and diagrams with every method/attribute in the world; keep them simple, to the point, and easy to digest (remember, someone you'll never, ever meet has to read them and mark them - the last thing you'll want to do is confuse that individual.)
4.
Books. I used the following three books *only* for part 2 & 3. I don't believe you need any others. Obviously if you don't understand these books when you read them, then you do need some others! However if you can't understand these 3 books, you shouldn't really be attempting the certification in the first place...
Book 1: The Unified Modeling Language User Guide (Addison Wesley) - Booch, Rumbaugh & Jacobson. This book will help you with your diagrams no end. This is a longer book than Martin Fowler's UML distilled (also recommended if you are new to UML and want a quick taste) - and it repeats itself a lot - but it has better coverage of Component diagrams and stereotypes (er, and everything else UML).
Book 2: Designing Enterprise Applications with the Java2 Platform, Enterprise Edition (Sun Microsystems Press). This book is a fairly easy read, and is the SUN BIBLE on architecturing J2EE applications. I would call you A FOOL if your submission did not follow the basic approaches detailed in the book (even if you don't agree with them.) The way I look at it, there is NO WAY Sun can fail your submission when you base it heavily on there own architecture book.
NB. The above book has a final chapter that talks about the Sun Java Petstore demo. Get yourself the latest copy of the code from the Sun site, and note that it has changed a bit from that listed in the book (esp. the use of XML to drive the request, event and screen processing). Study the petsore demo code and the book HARD. This took me weeks to go through in detail, but I learnt a lot. And hey, it's free!
Book 3: Java 2 Platform Enterprise Edition Platform and Component Specifications (Sun Microsystems Press). OK, you don't really NEED this, but I find I can't live without it. It is the printed version of the Servlet/JSP/EJB specs. on the Sun site. I found it more convenient to have them in one book than download everything and print it all out. This book goes into way more detail than you'll need for the project, but it's always good when you want some clarification on low-level detail.
5.
Diagrams. Keep them clean and simple. I used Rational Rose. You can get a demo disk off them or download it from their site. This is the same tool that Sun used for the diagrams they supplied, and it's easy to save your work directly as HTML. Sorry I can't offer any more advice on other UML tools as Rational is the only one I've ever used.
Use UML notes, stereotypes and sensible naming conventions to add clarity to your diagrams. Make sure you document your naming conventions in the document I listed above as part of your submission.
Panic: Just three diagrams for the whole project submission! How on earth do I explain the universe of my submission in just three documents?!!!
Like I said earlier, keep it SIMPLE. Don't put on any extraneous classes. For instance, I didn't put ANY GUI classes (JSP, Swing, etc.) on my Sequence Diagram. Why? Well, they just made the bloody thing too big! At the end of the day the GUI interface is just a 'request generator', so why not just show requests as the start of your sequence diagram elements? Better still, what about translating requests to events? All that machinery could clutter the diagram even further. So, LEAVE IT OFF. Just show events as the entry points on your Sequence diagrams...
You see, in two simple steps you've halved the size of the Sequence diagram, leaving you to concentrate on showing how the Use Case Text's are actually processed by your 'back end' application architecture - and remember that's what you are being marked on: your ARCHITECTURE, not the VASTNESS of your diagrams. (NB. I got 100% for my Sequence diagram, so I must have got something right...)
Follow the same approach for all your diagrams - i.e. make sure they are logically consistent. This is pretty easy in Rose, as all your classes, etc. are stored in a repository, from which you select to place on your diagrams. A simpler tool may not offer this, so make sure you keep the consistency by checking all your diagrams side-by-side (and print them out first).
6.
Follow-up exam. Take it as soon as you make your submission. Take a copy of the document you submitted along with your submission to the test centre and re-read it a couple of times before taking the exam (you won't be able to take this document in with you to the examining room, of course). The aim here is to make sure your exam replies are consistent with your submission.
The exam questions are quite easy and fairly broad. Like the project, Sun wants you to concentrate on higher-level architectural choices, and the pro's and con's of various approachs, particularly the approach you chose for your submission. You will not be asked any detailed questions on EJBs/JSPs/etc., so relax!
The exam should take you no more than 10-15 minutes. I wasted time by not reading all the questions first, and therefore ended up repeating myself and having to go back and cut-n-paste answers around. Do yourself a favour and read all the questions first - I think there are only 4-5 of them anyway. Don't write too much. For detail, refer the examiner to the appropriate sections of the document you submitted.
Spend some (most) of the huge amount of extra time you'll have left over by re-reading your answers and cleaning them up: layout, spelling, consistency and getting the detail balance right. Maybe expand some of your replies by detailing a few alternative approaches to those you used in your submission, and why you rejected them. Maybe also add a few notes on the 'real world' implications of your approach: for instance, if you keep state in stateful EJBs, would this state automatically propagate across clustered servers in a highly scalable solution? If not, what alternative would you suggest in this scenario?
Anyway, that's it. My guide to parts 2 & 3. Really, if you read the books I listed above - especially Book 2 - and spend plenty of time studying the project requirements and the Sun Petstore demo there is no way you should fail. It's all down to plain hard work. How much it will take will vary from person to person, but I put over 100 hours or so, spread over a couple of months or more. Don't rush it, it costs too much money when you fail! Enjoy the experience, and make sure you take away from it much more than just the piece of paper that says you are a Sun Certified Archtiect.
All the best,
Steve Phelan.
相关推荐
SCEA认证官方教程(英文)SCEA GUIDE
### Sun公司SCEA认证详解:Java企业架构师必经之路 #### 一、SCEA认证概述 SCEA(Sun Certified Enterprise Architect)认证是由Sun Microsystems公司在2000年首次推出的一项专业认证,旨在评估和认证Java企业级...
### J2EE架构师的SCEA认证经验 #### SCEA认证概述 SCEA (Sun Certified Enterprise Architect for the J2EE Platform) 是由 Sun Microsystems 提供的一项高级认证,主要面向那些希望在 Java 2 Platform, ...
### SCEA Java认证知识点详述 #### 一、SCEA认证概览 **SCEA**(Sun Certified Enterprise Architect)认证是针对那些利用Java 2 Platform, Enterprise Edition (J2EE)技术设计并构建企业级解决方案的专业人士的...
【SCEA资料】是针对SCEA(Sun Certified Enterprise Architect for Java EE)认证的一份重要学习资源。这个认证是Java企业级应用架构师的专业资格,由Oracle公司(原Sun Microsystems)提供,旨在验证专业人士在设计...
### SCEA JavaOne认证详解 #### 标题解析:“SCEA JavaOne” - **SCEA**:Sun Certified Enterprise Architect(SUN认证企业架构师),是Sun Microsystems(太阳微系统公司)推出的针对Java技术栈的企业级架构师...
### 关于准备SCEA(Sun Certified Enterprise Architect)的关键知识点 #### SCEA认证概述 SCEA认证,即Sun Certified Enterprise Architect,是针对Java技术体系内企业级架构师的一项高级认证。该认证主要评估应试...
### SCEA for J2EE Technology Study Guide (2002) 关键知识点解析 #### 标题:SCEA for J2EE Technology Study Guide (2002) 本指南是针对Sun Certified Enterprise Architect (SCEA) 考试的学习资料,主要聚焦于...
《SCEA Study Guide》是针对Sun Certified Enterprise Architect for Java EE (SCEA)认证的一份详尽学习指南。这份指南通常包含多个部分,旨在帮助考生深入理解和掌握Java企业级应用架构设计的关键概念和技术。 ...
sun SCEA 考试指南,想考的下,对考试有很大帮助,不考的学着也不错
Application_Design_Concepts_and_Principles Common_Architectures Integration_and_Messaging Patterns Security
在IT领域,Sun Certified Enterprise Architect(SCEA)认证是Java企业级架构师的重要资格证明,涉及到的知识点广泛且深入。本篇文章将针对给定的部分试题进行解析,重点讲解Active Replication和Server Clustering...
### SCEA Assignment for Big Smoke Shop Site #### 一、项目背景与目标 ##### 1.1 背景概述 BigSmoke Cigar Shop是一家位于佛罗里达州基韦斯特的雪茄店,该店铺拥有自己的雪茄生产线,并且销售其他制造商的产品...
Java认证成功之路第4部分:SCEA.rar
#### 一、SCEA(Sun Certified Enterprise Architect)认证概述 - **SCEA**:Sun公司推出的针对企业级架构师的专业认证,主要面向Java EE平台。 - **目的**:验证专业人员在设计、构建、部署Java EE应用程序方面的...
在SCWCD(Sun Certified Web Component Developer)模拟试题中,我们遇到了多个关于Servlet、HTTP请求以及Web应用交互的问题。以下是对这些题目所涉及知识点的详细解释: 1. Q: 13 - 数据共享与安全性 ...
该书作为第二版,在2010年出版时包含了最新的技术和认证要求,是当时参加Sun Certified Enterprise Architect (SCEA)考试的理想参考书籍。 #### 二、Sun Certified Enterprise Architect (SCEA) 认证 Sun Certified...
### Sun认证企业架构师(SCEA)学习书籍解析 #### 一、SCEA概述与转型 **Sun Certified Enterprise Architect (SCEA)** 是一项由Sun Microsystems在Java技术领域设立的专业认证,专为培养高级Java企业级架构师而...
### Sun认证企业架构师(SCEA)参考书解析 #### 一、SCEA概述与背景 Sun Microsystems(太阳微系统公司)是一家在IT领域内具有重要影响力的公司,其在2010年被Oracle公司收购。Sun Microsystems在软件开发、硬件...
3. **企业级服务**:这包括JTA(Java Transaction API)用于事务管理,JMS(Java Message Service)用于异步通信,JPA(Java Persistence API)和Hibernate等ORM(对象关系映射)工具,以及JNDI(Java Naming and ...