240 likes | 364 Views
EE557: Server-Side Development. eXtensible Stylesheet Language (XSL). XSL is the language that describes how XML documents are displayed XSL developed by the W3C Working Group Consists of three parts - XSLT (XSL Transformations) - XSL Formatting Objects (XSL-FO) - XPath
E N D
EE557: Server-Side Development eXtensible Stylesheet Language (XSL) • XSL is the language that describes how XML documents are displayed • XSL developed by the W3C Working Group • Consists of three parts • - XSLT (XSL Transformations) • - XSL Formatting Objects (XSL-FO) • - XPath • XSLT – is the language that specifies the conversion of a document from one • format to another, where the XSL stylesheet defines the means -> typically • used for for textual transformations, such as HTML or WML from XML • XSL-FO – formatting objects used when converting XML into binary formats • such as PDF files, or Word Documents. This part is not covered by JAXP or here • XPath – allows you to specify the part of the structure you are talking about • It allows you to distinguish between <name><title> and <qualification><title> • -> We can describe different transformations for different <title> elements
EE557: Server-Side Development xslexample1.xml <?xml version='1.0'?> <?xml:stylesheet type='text/xsl' href='xslexample1.xsl'?> <personnel> <person> <firstname>David</firstname> <lastname>Molloy</lastname> </person> <person> <firstname>John Peter</firstname> <lastname>Smith</lastname> </person> <person> <firstname>Jane</firstname> <lastname>Grogan</lastname> </person> </personnel>
EE557: Server-Side Development xslexample1.xsl <?xml version='1.0'?> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0"> stylesheet is the top level element -> root of the XSL stylesheet tree <xsl:template match="/"> associates the template with the root of the doc <HTML> <BODY bgcolor="wheat"> <xsl:for-each select="personnel/person"> works like a ‘for’ loop selects the value of the <person> tag within the <personnel> root element <BR/><H2>Employee</H2> <B>Firstname: </B> <xsl:value-of select="firstname" /><BR/> <B>Lastname: </B><xsl:value-of select="lastname" /> <BR/><BR/> </xsl:for-each> </BODY> </HTML> </xsl:template> </xsl:stylesheet>
EE557: Server-Side Development Client-Side/Server-Side Transformations
EE557: Server-Side Development Client-Side/Server-Side • Internet Explorer 5.0+ goes a long way towards implementing client • side transformations of XML • Non standards compliant in many ways with some omissions/changes • Perform a client transformation example • Many advantages in performing a manual transformation on the server • - works across multiple browsers (HTML) • - lightweight clients • - transformations are performed in advance – quicker • java –classpath .;xalan.jar org.apache.xalan.xslt.Process • –IN xslexample1.xml –XSL xslexample1.xsl -OUT xslexample1.html • Work through second example in the notes xslcustomers.xml/.xsl
EE557: Server-Side Development XSLT and JAXP • Often need to perform transformation real-time with dynamic data • Eg. XML to browser-specific HTML • XML to Wireless Markup Language (WML) for mobile phones • Personalized webpages/documentation • JAXP contains four packages responsible for handling XSLT • - javax.xml.transform • - javax.xml.transform.dom • - javax.xml.transform.sax • - javax.xml.transform.stream
EE557: Server-Side Development XSLT and JAXP • Steps: • 1) Import javax.xml.transform package classes and other classes • such as DOM packages if you use DOM • 2) Instantiate a TransformerFactory object • TransformerFactory tFactory = TransformerFactory.newInstance() • 3) Create a Transformer, in which we can define a set of transformation • instructions. In our example, we supply an XSL StreamSource • 4) Perform the transformation on the input (which can be created • from a SAX reader, a DOM or an input stream) – in our example, we • provide a DOMSource. The transform method takes a second • argument, which in our example is a File (via a FileWriter) • 5) Handle the possible exceptions • Work through the example in the notes
EE557: Server-Side Development Messaging with Java • Most common form of message is eMail • This is person-to-person or server-to-person messaging, not • application to application messaging • Email is made up of a Header and Content • Each header attribute has its own line, with attributes split by a ‘:’ • Eg. • Precedence: bulk • From: “David Molloy” molloyda@eeng.dcu.ie • Show full email message from the notes
EE557: Server-Side Development Messaging with Java • Email messages are stored or sent using one of a number of • different protocols • - Simple Mail Transfer Protocol (SMTP) • - Post Office Protocol (POP3) • - Internet Message Access Protocol (IMAP4) • IMAP4 typically considered more advanced than POP3, since it • supports folders and status flags (among other features)
EE557: Server-Side Development JavaMail API • J2EE developer does not need to understand underlying protocols • JavaMail API includes providers for the most commonly used protocols • JavaMail sits on top of the electronic mail vendor’s systems • Provides a standard, independent framework for Java client • applications to use electronic mail • Can use JavaMail to: • - Compose messages (including multi-part messages with attachments) • - Send messages to particular servers • - Retrieve and store messages in folders • When using JavaMail, the application needs network access to a • mail service that can send messages to the destination (dialup or • network service)
EE557: Server-Side Development JavaMail API • JavaMail is contructed with an Open Architecture, so can support • future protocols and standards • Two different types of protocols providers can implement: • - Transport: is the service which sends messages to the destination • Most commonly used transport is SMTP • - Store: the service that provides access to messages that have been • delivered to a mailboc. Most commonly used is POP3 but IMAP4 • is considered better and becoming more common • JavaMail relies heavily on the Java Activation Framework (JAF). JAF • designed to work in a standard way with different types of data • When an application needs to work with a particular data type, • these JAF objects can be “activated” and used to process data • (mail.jar, activation.jar, J2EE standard inclusion)
EE557: Server-Side Development JavaMail API • javax.mail.Session class is starting point for JavaMail. Allows the • specification of properties, such as the transport mechanism and • the mail server • Using the Session we can create a new MimeMessageObject • We then set the properties for the email message, such as the • sender, recipient, subject and contents of the message • Finally, we use Transport.send(message) to open up a new • connection to the mail service and send the message • Show the example code -> issues with running application • (local access only etc.) - demoMail.java
EE557: Server-Side Development Java Message Service (JMS) • JavaMail is an API for Messaging using email • Java Message Service (JMS) is an API for Messaging between • applications • Developed by Sun Microsystems as part of the Java 2 Enterprise Ed. • Provides a common way for Java programmers to create, send, • receive and read an enterprise messaging system’s messages • “A message is a unit of data that is sent from a process running on • one computer to other processes running on the same computer or • a different computer” • Messages can be simple text, or more complicated structures such as • Java Hashtables or other serializable Java objects • Object is serializable if it can be transmitted across a network as a • series of bytes and re-created into a copy of the original object
EE557: Server-Side Development Java Message Service (JMS) • MOM is a specialized type of middleware that coordinates the sending • and receiving of messages • Provides dependable mechanisms that enable applications to create, • send, and receive messages asynchronously in an enterprise environ. • Numerous examples of MOM: • - IBM MQ Series • - Fiorano Message Server • - Progress SonicMQ • - SilverStream JbrokerMQ • -> JMS provides a standard interface to these MOM products • Frees developers from having to write low level infrastructure code, • also known as “plumbing”, allowing them to build solutions quicker • JMS is used and integrates with other components of J2EE • (eg. JDBC used for persisting messages, JMS used in MDBs)
EE557: Server-Side Development Java Message Service (JMS) • Two primary communication modes: • Synchronous Communication: conducted between two parties, both • parties must be active and must acknowledge receipt of a message • (known as a blocking call) before proceeding • - easily affected by hardware, software and network failures, resulting in • delayed messages and traffic backups • - if hardware capacities are exceeded information is typically lost • - Example: chat application • Asynchronous Communication: all parties are peers and can send • messages at will. Does not require real-time acknowledgement of messages. Requester can continue with other processing once it sends the • message (known as a non-blocking call) • - Example: Email. Even though your e-mail client may not be running on • your PC, people can still send multiple messages to you. • - Example: internet-based purchase ring tone system -> return feedback • to browser, mobile phone turned off/no signal?
EE557: Server-Side Development Java Message Service (JMS) • Using messaging for exchanging data provides for: • Easy integration of incompatible systems • Asynchronous communications • One-to-many communications • Guaranteed messaging • Transactional messaging (all or none, commit/abort) • JMS supports two message models known as Point-to-Point (PTP) • and Publish/Subscribe (Pub/Sub) • Both models can deliver messages synchronously or asynchronously
EE557: Server-Side Development Point-to-Point Model (PTP) • Sends messages to a receiver on a one-to-one basis, such as in • instant messaging, or sending an order to another system • Message delivered to a queue -> processed on FIFO basis • Only one receiver can process each message (regardless of number of • receivers) • Receiver can look through messages in a Queue (eg. To count them) but • must process them FIFO
EE557: Server-Side Development Publish/Subscribe Model • Applications can publish messages on a one-to-many or many-to-many • basis. Eg. Sending news stories to interested parties, stock prices to traders • Messages are published to a Topic -> one or more publishers can • publish messages to a Topic -> clients must subscribe to receive • messages -> typically must be subscribed in advance • If no clients subscribed, messages are typically destroyed
EE557: Server-Side Development JMS API Programming Model • Firstly, we set up a QueueConnectionFactory or a • TopicConnectionFactory for use in our JMS applications • We achieve this by using the Sun Application Server Admin Console • (or whatever console is appropriate for the application server we are • using). • The steps to add the ConnectionFactory are detailed in the notes • At beginning of JMS application, we perform a JNDI API lookup of the • connection factory. Eg. • Context ctx = new InitialContext(); • QueueConnectionFactory queueConnectionFactory = • (QueueConnectionFactory) ctx.lookup(“myQueueConnectionFactory”);
EE557: Server-Side Development JMS API Programming Model • We also need to define a ‘destination’, which will be either a Queue • or a Topic. It defines the target of messages it produces and the • source of messages it consumes • Again we create this resource using the Admin Console • In our Java application we perform a JNDI lookup for our destination: • Queue myQueue = (Queue) ctx.lookup(“MyQueue”); • Topic myTopic = (Topic) ctx.lookup(“MyTopic”); • Obtain a QueueConnection/TopicConnection to the provider by using • the QueueConnectionFactory or TopicConnectionFactory • Obtain a QueueSession/TopicSession with the provider by using • the QueueConnection/TopicConnection
EE557: Server-Side Development JMS API Programming Model • Create a QueueSender or QueueReceiver (TopicPublisher or • TopicSubscriber) via the QueueSession (TopicSession) for the • required Queue (Topic) • Send and/or receive messages (Publish and/or subscribe messages) • Close the QueueConnection (automatically closes QueueSender/Receiver, • and the QueueSession). For Pub/Sub, close the TopicConnection, • TopicPublisher/Subscriber and TopicSession
EE557: Server-Side Development JMS API Programming Model
EE557: Server-Side Development JMS Messages • Typically formatted data (such as a request, event or status) passed • between applications. • Message can contain simple or complex data types, including • Serializable Java objects • JMS message is made up of 1 required component and 2 optional: • - A header(required) – used for identifying and routing messages, • setting expiration,priority etc. – many settable by clients • - Properties(optional) – extra header information • - A body(optional) – one of 5 different formats • ByteMessage,ObjectMessage,TextMessage,StreamMessage and • MapMessage (hashtable type) • message = queueSession.createTextMessage(); • for (int i = 0; i < NUM_MSGS; i++) { • message.setText("This is message " + (i + 1)); • System.out.println("Sending message: " + message.getText()); • }
EE557: Server-Side Development Point-to-Point Example • SimpleQueueSender.java • SimpleQueueReceiver.java Publish/Subscribe Example • SimpleTopicPublisher.java • SimpleTopicSubscriber.java • TextListener.java