Section 1: XML Web Service Standards
* 1.1 Given XML documents, schemas, and fragments determine whether their syntax and form are correct (according to W3C schema) and whether they conform to the WS-I Basic Profile 1.1.
* 1.2 Describe the use of XML schema in Java EE Web services
Section 7: Java EE Web Services
* 7.4 Describe the role of the WS-I Basic Profile when designing Java EE Web services.
Section 2: SOAP 1.2 Web Service Standards
* 2.1 List and describe the encoding types used in a SOAP message.
* 2.2 Describe the SOAP Processing and Extensibility Model.
* 2.3 Describe SOAP Message Construct and create a SOAP message that contains an attachment.
Section 5: REST, JSON, SOAP and XML Processing APIs (JAXP, JAXB and SAAJ)
* 5.7 Create and use a SOAP message with attachments using the SAAJ APIs.
Section 9: Developing Web Services
* 9.5 Implement a SOAP logging mechanism for testing and debugging a Web service application using Java EE Web Service APIs.
* 9.6 Given a set of requirements, create code to handle system and service exceptions and faults received by a Web services client.
Section 11: General Design and Architecture
* 11.3 Describe how to handle the various types of return values, faults, errors, and exceptions that can occur during a Web service interaction.
Section 3: Describing and Publishing (WSDL and UDDI)
* 3.1 Explain the use of WSDL in Web services, including a description of WSDL's basic elements, binding mechanisms and the basic WSDL operation types as limited by the WS-I Basic Profile 1.1.
* 3.2 Describe how WSDL enables one to separate the description of the abstract functionality offered by a service from concrete details of a service description such as "how" and "where" that functionality is offered.
* 3.3 Describe the Component Model of WSDL including Descriptions, Interfaces, Bindings, Services and Endpoints.
Section 9: Developing Web Services
* 9.3 Given an XML schema for a document style Web service create a WSDL file that describes the service and generate a service implementation.
Section 4: JAX-WS
* 4.1 Explain JAX-WS technology for building web services and client that communicate using XML
* 4.2 Given a set of requirements for a Web service, such as transactional needs, and security requirements, design and develop Web service applications that use JAX-WS technology
* 4.3 Describe the Integrated Stack (I-Stack) which consists of JAX-WS, JAXB, StAX, SAAJ
* 4.4 Describe and compare JAX-WS development approaches.
* 4.5 Describe the features of JAX-WS including the usage of Java Annotations.
* 4.6 Describe the architecture of JAX_WS including the Tools SPI that define the contract between JAX-WS tools and Java EE.
* 4.7 Describe creating a Web Service using JAX-WS.
* 4.8 Describe JAX-WS Client Communications Models.
* 4.9 Given an set of requirements, design and develop a Web service client, such as a Java EE client and a stand-alone client, using JAX-WS.
* 4.10 Given a set of requirements, create and configure a Web service client that accesses a stateful Web service.
Section 5: REST, JSON, SOAP and XML Processing APIs (JAXP, JAXB and SAAJ)
* 5.1 Describe the characteristics of REST Web Services.
* 5.2 Describe the characteristics of JSON Web Services.
* 5.3 Compare SOAP web services to REST Web Services.
* 5.4 Compare SOAP web services to JSON Web Services.
* 5.5 Describe the functions and capabilities of the APIs included within JAXP.
* 5.6 Describe the functions and capabilities of JAXB, including the JAXB process flow, such as XML-to-Java and Java-to-XML, and the binding and validation mechanisms provided by JAXB.
Section 3: Describing and Publishing (WSDL and UDDI)
* 3.4 Describe the basic functions provided by the UDDI Publish and Inquiry APIs to interact with a UDDI business registry.
Section 6: JAXR
* 6.1 Describe the function of JAXR in Web service architectural model, the two basic levels of business registry functionality supported by JAXR, and the function of the basic JAXR business objects and how they map to the UDDI data structures.
* 6.2 Create JAXR client to connect to a UDDI business registry, execute queries to locate services that meet specific requirements, and publish or update information about a business service.
Section 7: Java EE Web Services
* 7.1 Identify the characteristics of and the services and APIs included in the Java EE platform.
* 7.2 Explain the benefits of using the Java EE platform for creating and deploying Web service applications.
* 7.3 Describe the functions and capabilities of the JAXP, DOM, SAX, StAX, JAXR, JAXB, JAX-WS and SAAJ in the Java EE platform.
Section 9: Developing Web Services
* 9.2 Given a set of requirements, develop code to process XML files using the SAX, StAX, DOM, XSLT, and JAXB APIs.
Section 8: Security
* 8.1 Explain basic security mechanisms including: transport level security, such as basic and mutual authentication and SSL, message level security, XML encryption, XML Digital Signature, and federated identity and trust.
* 8.2 Identify the purpose and benefits of Web services security oriented initiatives and standards such as Username Token Profile, SAML, XACML, XKMS, WS-Security, and the Liberty Project.
* 8.3 Given a scenario, implement Java EE based web service web-tier and/or EJB-tier basic security mechanisms, such as mutual authentication, SSL, and access control.
* 8.4 Describe factors that impact the security requirements of a Web service, such as the relationship between the client and service provider, the type of data being exchanged, the message format, and the transport mechanism.
* 8.5 Describe WS-Policy that defines a base set of constructs that can be used and extended by other Web specifications to describe a broad range of service requirements and capabilities.
Section 9: Developing Web Services
* 9.1 Describe the steps required to configure, package, and deploy Java EE Web services and service clients, including a description of the packaging formats, such as .ear, .war, .jar, annotations and deployment descriptor settings.
Section 11: General Design and Architecture
* 11.1 Describe the characteristics of a Service Oriented Architecture (SOA) and how Web services fit to this model.
* 11.2 Given a scenario, design a Java EE web service using Web Services Design Patterns (Asynchronous Interaction, JMS Bridge, Web Service Cache, Web Service Broker), and Best Practices.
* 11.4 Describe the role that Web services play when integrating data, application functions, or business processes in a Java EE application.
Section 9: Developing Web Services
* 9.4 Given a set of requirements, create code to create an XML-based, document style, Web service using the JAX-WS APIs.
Section 12: Endpoint Design and Architecture
* 12.1 Given a scenario, design Web Service applications using information models that are either procedure-style or document-style.
* 12.2 Describe the function of the service interaction and processing layers in a Web service.
* 12.3 Design a Web service for an asynchronous, document-style process and describe how to refactor a Web Service from a synchronous to an asynchronous model.
* 12.4 Describe how the characteristics, such as resource utilization, conversational capabilities, and operational modes, of the various types of Web service clients impact the design of a Web service or determine the type of client that might interact with a particular service.
Section 10: Web Services Interoperability Technologies
* 10.1 Describe WSIT, the features of each WSIT technology and the standards that WSIT Implements for each technology and how it works.
* 10.2 Describe how to create a WSIT client from a Web Service Description Language (WSDL) file.
* 10.3 Describe how to configure web service providers and clients to use message optimization.
Section 10: Web Services Interoperability Technologies
* 10.4 Create a Microsoft Windows Communication Foundation (WCF) client that accesses a Java web service.
* 10.5 Describes the best practices for production and consumption of data interoperability between WCF web services and Java web service clients or between Java web services and WCF web service clients.
SCJP 6.0 - 88%, SCWCD 5 - 79%, SCJA - 96%, SCSNI - 68%, SCBCD 5 - 95%
BURN THE SOAP ON YOUR HEAD! Learn all the possible forms of message's structure, the name of the elemnts. Valid and inavlid SOAP messages. SOAP faults.
Originally posted by Sim Kim:
MZ,
When are you going for the test ?
Originally posted by Mikalai Zaikin:
Scheduled on 21st
SCJP, SE 1.4<br />SCWCD, EE 5
Originally posted by Elder Cris�stomo:
Man, are you going to release study notes for this new version?
(for moderator: no, i am not posting any specific question nor any specific answer, just saying what candidates should expect)
SCJP, SCWCD.
|Asking Good Questions|
Originally posted by Victor Williams Stafusa da Silva:
I ASK TO EVERYONE WHO WILL TAKE THE TEST TO LEFT A COMMENT PROTESTING AGAINST THE .NET QUESTIONS, IN THE HOPE THAT THEY WOULD BE DISCARDED IN THE DEFINITIVE VERSION OF THE TEST! LET'S REFUTE THE OBJECTIVES 10.4 AND 10.5!
If you're out there today building a web service and you're not downloading the other platform and working with that as part of your test leads, if you're building a Java web service, you have to download the .NET framework, you have to download NUnit and you have to write your unit tests as NUnit .NET unit tests. If you don�t want to learn C# that�s fine. Visual J# is actually very approachable for many Java programmers, so you can just write your tests in NUnit J# and you don�t have to learn any of the .NET plumbing because all you're trying to do is test it to make sure it works, but if you're not doing that you're fooling yourself. You're just checking off the marketing check box that says, �Oh, we�re a web service,� can�t do that. You have to go into this with this mindset that says, �I care about interoperability.� If you just want to do CORBA with angle brackets, fine, you can do it, but don�t be surprised when partners come to you and say it doesn�t work and when you tell them, �Well, that�s because the problem is on your end� don�t be surprised if they walk away and sever the partnership. That�s really what we have to do from a practical perspective to make this web services stuff come to fruition. Beat the vendors into line, beat the developers into line, and we can be successful.
SCJP 6.0 - 88%, SCWCD 5 - 79%, SCJA - 96%, SCSNI - 68%, SCBCD 5 - 95%
Originally posted by Mikalai Zaikin:
Anybody can comment on vrsion of SOAP specification tested ?
Originally posted by Peer Reynders:
If you access a SOAP web service that is not under your control there is a good chance that it will be implemented in .NET. For testing you need a faux-service that is under your control. To ensure that the faux-service behaves as close as possible to the real thing you should implement it on the same platform (same version of .NET) as the original.
If you plan to expose a business critical SOAP web service to the "outside" then you better make sure that it is .NET friendly because you do not want to alienate business partners that happen to use .NET - that is just bad for business. So to test your Java SOAP web service your are going to have to build some .NET test clients to ensure "that your web service contract can be easily digested".
Originally posted by Peer Reynders:
I for one applaud the people at Sun Education/Certification for being this open-minded - they are simply being realistic. Yes, it makes the certification harder but the SCDJWS (1.4) was always one of the harder ones but it made you learn something useful, made you more competent and it's good to see that this continues in the SCDJWS 5.
SCJP 6.0 - 88%, SCWCD 5 - 79%, SCJA - 96%, SCSNI - 68%, SCBCD 5 - 95%
Originally posted by Victor Williams Stafusa da Silva:
Just because Microsoft did it in some way that makes portability weak, and a lot of people uses .NET, this does not means that the java world should be conformed with this and accept blindly whatever microsoft defined that .Net should do.
Note to those who didn't attend the session: you didn't hear me say it, so I'll repeat it: I hate WSDL almost as much as I hate Las Vegas. Ask me why sometime, or if I get enough of a critical mass of questions, I'll blog it. If you've seen me do talks on Web Services, though, you've probably heard the rant: WSDL creates tightly-coupled endpoints precisely where loose coupling is necessary, WSDL encourages schema definitions that are inflexible and unevolvable, and WSDL intrinsically assumes a synchronous client-server invocation model that doesn't really meet the scalability or feature needs of the modern enterprise. And that's just for starters. I hate WSDL.
It's depressing to think that SOAP started just about 10 years ago and that now that everything is said and done, we built RPC again.
Originally posted by Victor Williams Stafusa da Silva:
Java spirit was always of platform independence and portability
SCDJWS is being infected with these microsoft things.
If so, the "Sun Certified Developer for Java Web Services" certification should be renamed to "Sun Certified Developer for Java Web Services with .NET integration".
Because this is unfair and against Java's spirit!
Originally posted by Victor Williams Stafusa da Silva:
Your argument simply says ".NET won and .NET is better"
If some .NET tool vomits some SOAP or WSDL that is almost intragable for any non-.NET thing, this does not means that we should be .NET-friendly
but the big problem is that .NET-friendship thing defeats completely the centrals purpose of web services: platform independence and vendor neutrality.
I just thinks that this hurts the credibility of the Sun Education/Certification.
Originally posted by Victor Williams Stafusa da Silva
SCWCD does not includes JSF even if it is very important, defined by JSR, and most of the real web developers should know it. SCWCD does not includes Struts 2 too, which is a very popular web framework and most a lot of real web developers should know too.
SCJP, SCWCD.
|Asking Good Questions|
Moreover Struts is not a Sun technology.
SCJP, SCWCD.
|Asking Good Questions|
Originally posted by Sim Kim:
but we should not have questions related to Visual Studio as such !
Good job on the other parts of your original post by the way!
So that fallacy is entirely yours.
A lot of the hype around web services was always about "interoperability" - so "web services" implies "integration of heterogeneous systems".
I think you actually mean "vendor independence" and portability.
Sorry, the software development world does not revolve around Java. Even Sun has seen the light and making it easier for other languages to run on the JVM.
SCJP 6.0 - 88%, SCWCD 5 - 79%, SCJA - 96%, SCSNI - 68%, SCBCD 5 - 95%
Originally posted by Victor Williams Stafusa da Silva:
However .Net is not vital to the development of java webservices and is not a sun technology either.
Based on my own experience (and others), I recommend that you have a basic set of fundamental types that you can compose to other types (structures, records) and sequences (arrays). Be careful with enumerations (an anachronism from the time when each byte did count - use strings instead), inheritance and polymorphism (even when XML supports it).
heterogeneous yes, but again .NET != non-java.
And again, THEY went wrong using convenience over correctness, and now SCDJWS is going to glorify that by asking questions pushing java in the .Net way to be.
The problem is not that. The problem is all the vendor lock-in thing.
ChintanRajyaguru.com
SOADevelopment.com - Coming soon!
Originally posted by Chintan Rajyaguru:
About .NET: Like I mentioned in my other post, WSIT is all about interoperability with .NET (WCF) web services so questions about .NET, WCF can be expected. Questions about Vistual Studio is little too much but I suspect they may have taken help from microsoft people to design those questions and a tool question might have slipped through the cracks. I highly doubt it will be counted. I also believe Netbeans questions shouldn't be there nor should there be any ANT questions. Are you sure they were ANT questions and not APT questions? APT = Annotation Processing Tool, which generates code from web service source code and may be in scope of the exam.
I said early in this topic:
It is hard to tell exactly the problem in the test about Visual Studio, ant, and netbeans without posting too much details about the questions and answers.
There are not questions focusing this things, however some questions cite them in a way that you will need to know enough about their behavior to judge some answers as true or false.
Originally posted by Chintan Rajyaguru:
IMO, Sun should stick to the standards and specifications - after all that's what made other certifications popular. APT, wsgen etc. are vendor provided utilities so they shouldn't be on the exam. Similarly, jaxws-commons is Sun's extension of JAX-WS under which it provides JSON binding etc. so that shouldn't be on the exam either. General questions about various bindings (including JSON) comes under design and architecture considerations so they can be included. This is just my $0.02 but I strongly believe each candidate should leave comments and help shape the exam, after all, that's the whole point of having beta exams.
SCJP 6.0 - 88%, SCWCD 5 - 79%, SCJA - 96%, SCSNI - 68%, SCBCD 5 - 95%
Don't MAKE me come back there with this tiny ad:
Gift giving made easy with the permaculture playing cards
https://coderanch.com/t/777758/Gift-giving-easy-permaculture-playing
|