J2ee Frameworks at Leonsoft
Complexity, economy and scale in the prevailing software industry scenario necessitate the need for robust & flexible solutions. Leonsoft employs best-in class J2EE / Java Application Development to meet these challenges, and offer you stable & effective solutions.
Leonsoft dips into its extensive library of Java components and robust Java application framework to deliver you applications with high security, performance and scalability requirements. We have successfully completed numerous J2EE architecture based solutions with a team of highly skilled and experienced J2EE software professionals. This enables our team to jump-start into development right away, without worrying about the intricacies behind database connectivity, File I/O, error handling, session and application management.
we at Leonsoft , focus on all the aspects of managing a project. we use our years of experience and the latest development technologies and tools. We consistently deliver creative, scalable, reliable, consistent designs and development solutions that reflect the personality, needs, and vision of our clients.
We Provide following J2ee Frameworks working Architectures :
- Servlets - Jsp - Jstl - El - Jdbc
- Struts 1.3 - Hibernate - Jquery - Ajax
- Struts 2.0 - Hibernate - Dojo - Ajax
- Java Server Faces - Hibernate - RichFaces - Dojo
- Spring ( Mvc - Webflow ) - Hibernate - Ajax - Dojo
- Liferay Portal - Hibernate - Ajax
Java Platform, Enterprise Edition
Java Platform, Enterprise Edition or Java EE is Oracle's enterprise Java computing platform. The platform provides an API and runtime environment for developing and running enterprise software, including network and web services, and other large-scale, multi-tiered, scalable, reliable, and secure network applications. Java EE extends the Java Platform, Standard Edition (Java SE), providing an API for object-relational mapping, distributed and multi-tier architectures, and web services. The platform incorporates a design based largely on modular components running on an application server. Software for Java EE is primarily developed in the Java programming language. The platform emphasizes Convention over configuration and annotations for configuration. Optionally XML can be used to override annotations or to deviate from the platform defaults.
Standards and Specifications
Java EE is defined by its specification. As with other Java Community Process specifications, providers must meet certain conformance requirements in order to declare their products as Java EE compliant.
Java EE includes several API specifications, such as JDBC, RMI, e-mail, JMS, web services, XML, etc., and defines how to coordinate them. Java EE also features some specifications unique to Java EE for components. These include Enterprise JavaBeans, Connectors, servlets, JavaServer Pages and several web service technologies. This allows developers to create enterprise applications that are portable and scalable, and that integrate with legacy technologies. A Java EE application server can handle transactions, security, scalability, concurrency and management of the components that are deployed to it, in order to enable developers to concentrate more on the business logic of the components rather than on infrastructure and integration tasks.
Java EE application
A Java EE application or a Java Platform, Enterprise Edition application is any deployable unit of Java EE functionality. This can be a single Java EE module or a group of modules packaged into an EAR file along with a Java EE application deployment descriptor. Java EE applications are typically engineered to be distributed across multiple computing tiers.
Enterprise applications can consist of combinations of the following :
- Enterprise JavaBean (EJB) modules (packaged in JAR files);
- Web modules (packaged in WAR files);
- connector modules or resource adapters (packaged in RAR files);
- Session Initiation Protocol (SIP) modules (packaged in SAR files);
- application client modules;
- Additional JAR files containing dependent classes or other components required by the application;
- Java Server Pages - JSTL - EL :
JavaServer Pages :
JavaServer Pages (JSP) is a technology that helps software developers create dynamically generated web pages based on HTML, XML, or other document types. Released in 1999 by Sun Microsystems, JSP is similar to PHP, but it uses the Java programming language.
To deploy and run JavaServer Pages, a compatible web server with a servlet container, such as Apache Tomcat or Jetty, is required.
The JSP Model 2 architecture.
Architecturally, JSP may be viewed as a high-level abstraction of Java servlets. JSPs are translated into servlets at runtime; each JSP's servlet is cached and re-used until the original JSP is modified.
JSP can be used independently or as the view component of a server-side model - view - controller design, normally with JavaBeans as the model and Java servlets (or a framework such as Apache Struts) as the controller. This is a type of Model 2 architecture.
JSP allows Java code and certain pre-defined actions to be interleaved with static web markup content, with the resulting page being compiled and executed on the server to deliver a document. The compiled pages, as well as any dependent Java libraries, use Java bytecode rather than a native software format. Like any other Java program, they must be executed within a Java virtual machine (JVM) that integrates with the server's host operating system to provide an abstract platform-neutral environment.
JSPs are usually used to deliver HTML and XML documents, but through the use of OutputStream, they can deliver other types of data as well. The Web container creates JSP implicit objects like pageContext, servletContext, session, request & response.
A JavaServer Pages compiler is a program that parses JSPs, and transforms them into executable Java Servlets. A program of this type is usually embedded into the application server and run automatically the first time a JSP is accessed, but pages may also be precompiled for better performance, or compiled as a part of the build process to test for errors.
Some JSP containers support configuring how often the container checks JSP file timestamps to see whether the page has changed. Typically, this timestamp would be set to a short interval (perhaps seconds) during software development, and a longer interval (perhaps minutes, or even never) for a deployed Web application.
Comparison with similar technologies
JSP pages are similar to PHP pages and ASP.NET Web Forms, in that all three add server-side code to an HTML page. However, all three terms refer to a different component of the system. JSP refers to the JSP pages, which can be used alone, with Java servlets, or with a framework such as Apache Struts. PHP is itself a programming language, designed for dynamic Web pages. ASP.net is a framework comparable to Struts or JavaServer Faces that uses pages called Web Forms.
While JSP pages use the Java language, ASP.NET pages can use any .NET-compatible language, usually C#.
ASP.NET is designed for a Microsoft Windows web server, while PHP and Java server technologies (including JSP) are fairly operating system agnostic.
Caching to improve performance
The popularity of JavaServer Pages has meant that it is being used quite frequently in developing high-traffic web apps. And, this is causing performance bottlenecks as you try to add more users and transaction load on your JavaServer Pages application. Although, JavaServer Pages application can scale very nicely to multiple web servers, the database server cannot. The main reason for the database becoming a bottleneck is that while you can add more and more servers to the JavaServer Pages application server farm, you cannot do the same at the database tier. This results in limited scalability at the data tier. You can remove these JavaServer Pages Servlets performance bottlenecks by using a distributed cache for storing the frequently used data.
JavaServer Pages Standard Tag Library
The JavaServer Pages Standard Tag Library (JSTL), is a component of the Java EE Web application development platform. It extends the JSP specification by adding a tag library of JSP tags for common tasks, such as XML data processing, conditional execution, database access, loops and internationalization. JSTL was developed under the Java Community Process (JCP) as Java Specification Request (JSR) 52. On May 8, 2006, JSTL 1.2 was released.
JSTL provides an effective way to embed logic within a JSP page without using embedded Java code directly. The use of a standardised tag set, rather than breaking in and out of Java code, leads to more maintainable code and enables separation of concerns between the development of the application code and user interface.
Database tag library are supported with tags for querying, creating and updating database table.
- In addition to JSTL, the JCP has the following JSRs to develop standard JSP tag libraries:
- JSR 128: JESI - JSP Tag Library for Edge Side Includes (inactive)
- JSR 267: JSP Tag Library for Web Services
Unified Expression Language
The Java Unified Expression Language is a special purpose programming language mostly used in Java web applications for embedding expressions into web pages. The Java specification writers and expert groups of the Java web-tier technologies have worked on a unified expression language which is now part of the JSP 2.1 specification (JSR-245). While the expression language is part of the JSP specification, it does not depend on the JSP specification and therefore it is available for a variety of technologies.
The expression language started out as part of the JavaServer Pages Standard Tag Library (JSTL) and was originally called SPEL (Simplest Possible Expression Language), then just Expression Language (EL). It was a scripting language which allowed access to Java components (JavaBeans) through JSP. Since JSP 2.0, it has been used inside JSP tags to separate Java code from JSP, and to allow easier access to Java components (than in Java code).
Over the years, the expression language has evolved to include more advanced functionality and it was included in the JSP 2.0 specification. Scripting was made easier for web-content designers who have little or practically no knowledge of the core Java Language. This scripting language made JSP a scripting language in the true sense. Before EL, JSP consisted of some special tags like scriptlets, expressions etc. within which Java code was written explicitly. With EL the web-content designer needs only to know how to make proper calls to core Java methods.
EL also liberated the programmer from having to know the particularities of how the values are actually accessed: object.property can mean (depending on what the object is) either object.get("property") or object.getProperty("property") or object.getProperty() etc.
During the development of JSP 2.0, the JavaServer Faces technology was released which also needed an expression language, but the expression language defined in the JSP 2.0 specification didn't satisfy all the needs for development with JSF technology. The most obvious limitation is that its expressions are evaluated immediately. And also, the JSF components need a way to invoke methods on server-side objects. A more powerful language was created with the following new features:
- Deferred expressions, which are not immediately evaluated
- Expressions that can set as well as get data
- Method expressions, which can invoke methods
The new expression language worked well for the purposes of JSF. But developers had problems when integrating the JSP EL with the JSF EL because of conflicts. Because of these incompatibilities, the unified expression language initiative was started to unify these expression languages. As of JSP 2.1, the expression languages of JSP 2.0 and JSF 1.1 have been merged into a single unified expression language (EL 2.1)
The new unified EL is a union of the JSP and JSF expression languages. In addition to the features already available in the JSP EL, the unified EL has the following features:
Support for expressions that can set values and expressions that can invoke methods
A pluggable API for resolving expressions
- Apache Struts :
Apache Struts is an open-source web application framework for developing Java EE web applications. It uses and extends the Java Servlet API to encourage developers to adopt a model - view - controller (MVC) architecture. It was originally created by Craig McClanahan and donated to the Apache Foundation in May, 2000. Formerly located under the Apache Jakarta Project and known as Jakarta Struts, it became a top-level Apache project in 2005.
Design goals and overview
In a standard Java JEE web application, the client will typically call to the server via a web form. The information is then either handed over to a Java Servlet which interacts with a database and produces an HTML-formatted response, or it is given to a JavaServer Pages (JSP) document that intermingles HTML and Java code to achieve the same result. Both approaches are often considered inadequate for large projects because they mix application logic with presentation and make maintenance difficult.
The goal of Struts is to separate the model (application logic that interacts with a database) from the view (HTML pages presented to the client) and the controller (instance that passes information between view and model). Struts provides the controller (a servlet known as ActionServlet) and facilitates the writing of templates for the view or presentation layer (typically in JSP, but XML/XSLT and Velocity are also supported). The web application programmer is responsible for writing the model code, and for creating a central configuration file struts-config.xml that binds together model, view, and controller.
Requests from the client are sent to the controller in the form of "Actions" defined in the configuration file; if the controller receives such a request it calls the corresponding Action class that interacts with the application-specific model code. The model code returns an "ActionForward", a string telling the controller what output page to send to the client. Information is passed between model and view in the form of special JavaBeans. A powerful custom tag library allows it to read and write the content of these beans from the presentation layer without the need for any embedded Java code.
Struts is categorized as a request-based web application framework.
Struts also supports internationalization by web forms, and includes a template mechanism called "Tiles" that (for instance) allows the presentation layer to be composed from independent header, footer, menu navigation and content components.
- Simple POJO-based actions
- Simplified testability
- Thread safe
- AJAX support
- jQuery plugin
- Dojo Toolkit plugin (deprecated)
- Ajax client-side validation
- Template support
- Support for different result types
- Easy to extend with plugins
- REST plugin (REST-based actions, extension-less URLs)
- Convention plugin (action configuration via Conventions and Annotations)
- Spring plugin (dependency injection)
- Hibernate plugin
- Support in design
- JFreechart plugin (charts)
- jQuery plugin (Ajax support, UI widgets, dynamic table, charts)
- Rome plugin
Competing MVC frameworks
Although Struts is a well-documented, mature, and popular framework for building front ends to Java applications, there are other frameworks categorized as "lightweight" MVC frameworks such as Spring MVC, Stripes, Wicket, Play!, and Tapestry. The new XForms standards and frameworks may also be another option to building complex web form validations with Struts in the future.
The WebWork framework spun off from Apache Struts aiming to offer enhancements and refinements while retaining the same general architecture of the original Struts framework. However, it was announced in December 2005 that Struts would re-merge with WebWork. WebWork 2.2 has been adopted as Apache Struts2, which reached its first full release in February 2007.
In 2004, Sun launched an addition to the Java platform, called JavaServer Faces (JSF). Aside from the original Struts framework, the Apache project previously offered a JSF-based framework called Shale, which was retired in May 2009.
Other MVC frameworks that are JVM-based include Grails.
- JavaServer Faces :
JavaServer Faces (JSF) is a Java specification for building component-based user interfaces for web applications. It was formalized as a standard through the Java Community Process and is part of the Java Platform, Enterprise Edition.
JSF 2 uses Facelets as its default templating system. Other view technologies such as XUL can also be employed. In contrast, JSF 1.x uses JavaServer Pages (JSP) as its default templating system.
How it Works ?
JavaServer Faces is based on a component-driven UI design model, using XML files called view templates or Facelets views. Requests are processed by the FacesServlet, which loads the appropriate view template, builds a component tree, processes events, and renders the response, typically in the HTML language, to the client. The state of UI components and other objects of scope interest, is saved at the end of each request in a process called stateSaving (note: transient true), and restored upon next creation of that view. Objects and states can be saved either on the client or server side.
JSF and Ajax
Because JSF supports multiple output formats, Ajax-enabled components can easily be added to enrich JSF-based user interfaces. The JSF 2.0 specification provides built in support for Ajax by standardizing the Ajax request lifecycle, and providing simple development interfaces to Ajax events, allowing any event triggered by the client to go through proper validation, conversion, and finally method invocation, before returning the result to the browser via an XML DOM update.
Ajax-enabled components and frameworks :
The following companies and projects offer Ajax-based JSF frameworks or component libraries :
- JBoss RichFaces (derived from and replaces Ajax4jsf), Ajax-enabled JSF components for layout, file upload, forms, inputs and many other features.
- PrimeFaces Ajax framework with JSF components
- Oracle ADF Faces Rich Client, Oracle Application Development Framework
- Backbase Enterprise Ajax - JSF Edition, Ajax framework
- IBM Notes - XPages
- Apache MyFaces, The Apache Foundation JSF implementation with Ajax components
- Sun Java BluePrints AJAX Components
- ZK Ajax framework with JSF components
Facelets (which was designed specifically for JavaServer Faces) was adopted as the official view technology for JSF 2.0. This eliminates the life-cycle conflicts that existed with JSP, forcing workarounds by Java developers. Facelets allows easy component/tag creation using XML markup instead of Java code, the chief complaint against JSF 1.x.
The new JSF developments also provide wide accessibility to Java 5 annotations such as @ManagedBean, @ManagedProperty and @FacesComponent which removes the need for faces-config.xml in all cases except framework extension. Navigation has been simplified, removing the need for faces-config.xml navigation cases. Page transitions can be invoked simply by passing the name of the desired View/Facelet.
Addition of Partial State Saving and DOM updates are part of the built in standardized Ajax support.
JSF 2.0 also includes a number of other changes like adding support for events, separate development, staging, and production modes, similar to RAILS_ENV in Ruby on Rails, and significantly expanding the standard set of components.
- Spring Mvc Framework :
The Spring Framework is an open source application framework and inversion of control container for the Java platform.
The first version was written by Rod Johnson, who released the framework with the publication of his book Expert One-on-One J2EE Design and Development in October 2002. The framework was first released under the Apache 2.0 license in June 2003. The first milestone release, 1.0, was released in March 2004, with further milestone releases in September 2004 and March 2005. The Spring 1.2.6 framework won a Jolt productivity award and a JAX Innovation Award in 2006 Spring 2.0 was released in October 2006, Spring 2.5 in November 2007, Spring 3.0 in December 2009, and Spring 3.1 in December 2011. The current version is 3.2.3, which was released in May 2013. Spring Framework 4.0 is expected by the end of 2013, with plans to support Java SE 8, Groovy 2, some aspects of Java EE7, and WebSockets.
The core features of the Spring Framework can be used by any Java application, but there are extensions for building web applications on top of the Java EE platform. Although the Spring Framework does not impose any specific programming model, it has become popular in the Java community as an alternative to, replacement for, or even addition to the Enterprise JavaBean (EJB) model.
The Spring Framework includes several modules that provide a range of services:
Inversion of Control Container: configuration of application components and lifecycle management of Java objects, done mainly via dependency injection
Aspect-oriented programming: enables implementing cross-cutting concerns.
Data Access: working with relational database management systems on the Java platform using JDBC and object-relational mapping tools and with NoSQL databases
Transaction Management : unifies several transaction management APIs and coordinates transactions for Java objects
Model-View-Controller : an HTTP- and servlet-based framework providing hooks for extension and customization for web applications and RESTful web services.
Remote Access Framework: configurative RPC-style marshalling of Java objects over networks supporting RMI, CORBA and HTTP-based protocols including web services (SOAP)
Convention over Configuration : a rapid application development solution for Spring-based enterprise applications is offered in the Spring Roo module
Authentication and Authorization : configurable security processes that support a range of standards, protocols, tools and practices via the Spring Security sub-project (formerly Acegi Security System for Spring).
Remote management : configurative exposure and management of Java objects for local or remote configuration via JMX
Messaging : configurative registration of message listener objects for transparent message-consumption from message queues via JMS, improvement of message sending over standard JMS APIs
Testing : support classes for writing unit tests and integration tests
The Spring Framework features its own MVC web application framework, which wasn't originally planned. The Spring developers decided to write their own web framework as a reaction to what they perceived as the poor design of the (then) popular Jakarta Struts web framework, as well as deficiencies in other available frameworks. In particular, they felt there was insufficient separation between the presentation and request handling layers, and between the request handling layer and the model.
Like Struts, Spring MVC is a request-based framework. The framework defines strategy interfaces for all of the responsibilities which must be handled by a modern request-based framework. The goal of each interface is to be simple and clear so that it's easy for Spring MVC users to write their own implementations if they so choose. MVC paves the way for cleaner front end code. All interfaces are tightly coupled to the Servlet API. This tight coupling to the Servlet API is seen by some as a failure on the part of the Spring developers to offer a high-level abstraction for web-based applications. However, this coupling makes sure that the features of the Servlet API remain available to developers while offering a high abstraction framework to ease working with said API.
The DispatcherServlet class is the front controller of the framework and is responsible for delegating control to the various interfaces during the execution phases of a HTTP request.
The most important interfaces defined by Spring MVC, and their responsibilities, are listed below:
HandlerMapping : selecting objects that handle incoming requests (handlers) based on any attribute or condition internal or external to those requests
HandlerAdapter: execution of objects that handle incoming requests
Controller: comes between Model and View to manage incoming requests and redirect to proper response. It acts as a gate that directs the incoming information. It switches between going into model or view.
View: responsible for returning a response to the client. Some requests may go straight to view without going to the model part; others may go through all three.
ViewResolver : selecting a View based on a logical name for the view (use is not strictly required)
HandlerInterceptor : interception of incoming requests comparable but not equal to Servlet filters (use is optional and not controlled by DispatcherServlet).
LocaleResolver : resolving and optionally saving of the locale of an individual user
MultipartResolver : facilitate working with file uploads by wrapping incoming requests
Each strategy interface above has an important responsibility in the overall framework. The abstractions offered by these interfaces are powerful, so to allow for a set of variations in their implementations, Spring MVC ships with implementations of all these interfaces and together offers a feature set on top of the Servlet API. However, developers and vendors are free to write other implementations. Spring MVC uses the Java java.util.Map interface as a data-oriented abstraction for the Model where keys are expected to be string values.
The ease of testing the implementations of these interfaces seems one important advantage of the high level of abstraction offered by Spring MVC. DispatcherServlet is tightly coupled to the Spring inversion of control container for configuring the web layers of applications. However, web applications can use other parts of the Spring Framework - including the container - and choose not to use Spring MVC.
- Spring Web Flow :
Spring Web Flow
Spring Web Flow (SWF) is the sub-project of the Spring Framework that focuses on providing the infrastructure for building and running rich web applications. The project tries to solve 3 core problems facing web application developers:
- How do you express page navigation rules ?
- How do you manage navigation and conversational state ?
- How do you facilitate modularization and reuse ?
In Spring Web Flow, a web flow answers all of the above questions: it captures navigational rules allowing the Spring Web Flow execution engine to manage a conversation and the associated state. At the same time, a web flow is a reusable web application module.
Since version 2.0, Spring Web Flow also introduces other additional features supporting the construction of rich web applications, such as AJAX support and tight integration with JavaServer Faces.
The Spring Web Flow project started as a simple extension to the Spring Web MVC framework providing web flow functionality, developed by Erwin Vervaet in 2004. In 2005 the project was introduced into the Spring portfolio by Keith Donald and grew into the official Spring sub-project it is now. The first production ready 1.0 release was made on 2006-10-26. Version 2.0, first released on 2008-04-29, saw a major internal reorganization of the framework to allow better integration with JavaServer Faces.
- Web Services Architecture :
Web Services Architecture
A web service is a method of communication between two electronic devices over the World Wide Web. A web service is a software function provided at a network address over the web or the cloud, it is a service that is "always on" as in the concept of utility computing. The W3C defines a "Web service" as:
A software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.
The W3C also states:
We can identify two major classes of Web services:
REST-compliant Web services, in which the primary purpose of the service is to manipulate XML representations of Web resources using a uniform set of "stateless" operations; and arbitrary Web services, in which the service may expose an arbitrary set of operations.
Web services in a service-oriented architecture.
A web API is a development in web services where emphasis has been moving to simpler representational state transfer (REST) based communications. RESTful APIs do not require XML-based web service protocols (SOAP and WSDL) to support their light-weight interfaces.
Web APIs allow the combination of multiple web resources into new applications known as mashups.
WSDL version 2.0 offers support for binding to all the HTTP request methods (beyond GET and POST as in version 1.1) allowing for a "RESTful web services" approach.
XML web services
XML web services use Extensible Markup Language (XML) messages that follow the SOAP standard and have been popular with the traditional enterprises. In such systems, there is often a machine-readable description of the operations offered by the service written in the Web Services Description Language (WSDL). The latter is not a requirement of a SOAP endpoint, but it is a prerequisite for automated client-side code generation in many Java and .NET SOAP frameworks (frameworks such as Apache Axis2, Apache CXF, Spring, gSOAP being notable exceptions). Some industry organizations, such as the WS-I, mandate both SOAP and WSDL in their definition of a web service.
Automated design methods
Automated tools can aid in the creation of a web service. For services using WSDL it is possible to either automatically generate WSDL for existing classes (a bottom-up strategy) or to generate a class skeleton given existing WSDL (a top-down strategy).
A developer using a bottom up method writes implementing classes first (in some programming language), and then uses a WSDL generating tool to expose methods from these classes as a web service. This is simpler to develop but may be harder to maintain if the original classes are subject to frequent change.
A developer using a top down method writes the WSDL document first and then uses a code generating tool to produce the class skeleton, to be completed as necessary. This way is generally considered more difficult but can produce cleaner designs and is generally more resistant to change. As long as the message formats between sender and receiver do not change, changes in the sender and receiver themselves do not affect the web service. The technique is also referred to as "contract first" since the WSDL (or contract between sender and receiver) is the starting point.
Web services that use markup languages
There are a number of web services that use markup languages:
- Web template
- Web Services Description Language (WSDL) from the W3C
- XML Interface for Network Services (XINS) provides a POX-style Web service specification format
- Web Services Conversation Language (WSCL)
- Web Services Flow Language (WSFL) (superseded by BPEL)
- Representational state transfer (REST) versus remote procedure call (RPC)
- XML-RPC - XML Remote Procedure Call
Web Services Description Language ( WSDL )
The Web Services Description Language is an XML-based interface description language that is used for describing the functionality offered by a web service. A WSDL description of a web service (also referred to as a WSDL file) provides a machine-readable description of how the service can be called, what parameters it expects, and what data structures it returns. It thus serves a purpose that corresponds roughly to that of a method signature in a programming language.
The current version of WSDL is WSDL 2.0. The meaning of the acronym has changed from version 1.1 where the D stood for Definition.
Representation of concepts defined by WSDL 1.1 and WSDL 2.0 documents.
The WSDL describes services as collections of network endpoints, or ports. The WSDL specifications provides an XML format for documents for this purpose. The abstract definitions of ports and messages are separated from their concrete use or instance, allowing the reuse of these definitions. A port is defined by associating a network address with a reusable binding, and a collection of ports defines a service. Messages are abstract descriptions of the data being exchanged, and port types are abstract collections of supported operations. The concrete protocol and data format specifications for a particular port type constitutes a reusable binding, where the operations and messages are then bound to a concrete network protocol and message format. In this way, WSDL describes the public interface to the Web service.
WSDL is often used in combination with SOAP and an XML Schema to provide Web services over the Internet. A client program connecting to a Web service can read the WSDL file to determine what operations are available on the server. Any special datatypes used are embedded in the WSDL file in the form of XML Schema. The client can then use SOAP to actually call one of the operations listed in the WSDL file using XML or HTTP.
The current version of the specification is 2.0; version 1.1 has not been endorsed by the W3C but version 2.0 is a W3C recommendation. WSDL 1.2 was renamed WSDL 2.0 because of its substantial differences from WSDL 1.1. By accepting binding to all the HTTP request methods (not only GET and POST as in version 1.1), the WSDL 2.0 specification offers better support for RESTful web services, and is much simpler to implement. However support for this specification is still poor in software development kits for Web Services which often offer tools only for WSDL 1.1. Furthermore, the latest version (version 2.0) of the Business Process Execution Language (BPEL) only supports WSDL 1.1
Universal Description Discovery and Integration ( UDDI )
It has been suggested that this article be merged with Web Services Discovery. (Discuss) Proposed since January 2012.
Universal Description, Discovery and Integration (UDDI, pronounced Yu-di?) is a platform-independent, Extensible Markup Language (XML)-based registry by which businesses worldwide can list themselves on the Internet, and a mechanism to register and locate web service applications. UDDI is an open industry initiative, sponsored by the Organization for the Advancement of Structured Information Standards (OASIS), for enabling businesses to publish service listings and discover each other, and to define how the services or software applications interact over the Internet.
UDDI was originally proposed as a core Web service standard. It is designed to be interrogated by SOAP messages and to provide access to Web Services Description Language (WSDL) documents describing the protocol bindings and message formats required to interact with the web services listed in its directory.
UDDI was written in August 2000, at a time when the authors had a vision of a world in which consumers of web services would be linked up with providers through a public or private dynamic brokerage system. In this vision, anyone needing a service, such as credit card authentication, would go to their service broker and select a service supporting the desired SOAP (or other) service interface, and meeting other criteria. In such a world, the publicly operated UDDI node or broker would be critical for everyone. For the consumer, public or open brokers would only return services listed for public discovery by others, while for a service producer, getting a good placement in the brokerage by relying on metadata of authoritative index categories would be critical for effective placement.
UDDI was included in the Web Services Interoperability (WS-I) standard as a central pillar of web services infrastructure, and the UDDI specifications supported a publicly accessible Universal Business Registry in which a naming system was built around the UDDI-driven service broker.
UDDI has not been as widely adopted as its designers had hoped. IBM, Microsoft, and SAP announced they were closing their public UDDI nodes in January 2006. The group defining UDDI, the OASIS Universal Description, Discovery, and Integration (UDDI) Specification Technical Committee voted to complete its work in late 2007 and has been closed. In September 2010, Microsoft announced they were removing UDDI services from future versions of the Windows Server operating system. Instead, this capability would be moved to Biztalk.
UDDI systems are most commonly found inside companies, where they are used to dynamically bind client systems to implementations. However, much of the search metadata permitted in UDDI is not used for this relatively simple role.
A UDDI business registration consists of three components:
- White Pages - address, contact, and known identifiers;
- Yellow Pages - industrial categorizations based on standard taxonomies;
- Green Pages - technical information about services exposed by the business.
White pages give information about the business supplying the service. This includes the name of the business and a description of the business - potentially in multiple languages. Using this information, it is possible to find a service about which some information is already known (for example, locating a service based on the provider's name).
Contact information for the business is also provided - for example the businesses address and phone number; and other information such as the Dun & Bradstreet Universal Numbering System number.
Yellow pages provide a classification of the service or business, based on standard taxonomies. These include the Standard Industrial Classification (SIC), the North American Industry Classification System (NAICS), or the United Nations Standard Products and Services Code (UNSPSC) and geographic taxonomies.
Because a single business may provide a number of services, there may be several Yellow Pages (each describing a service) associated with one White Page (giving general information about the business).
Green pages are used to describe how to access a Web Service, with information on the service bindings. Some of the information is related to the Web Service - such as the address of the service and the parameters, and references to specifications of interfaces. Other information is not related directly to the Web Service - this includes e-mail, FTP, CORBA and telephone details for the service. Because a Web Service may have multiple bindings (as defined in its WSDL description), a service may have multiple Green Pages, as each binding will need to be accessed differently.
UDDI Nodes & Registry
UDDI nodes are servers which support the UDDI specification and belong to a UDDI registry while UDDI registries are collections of one or more nodes.
SOAP is an XML-based protocol to exchange messages between a requester and a provider of a Web Service. The provider publishes the WSDL to UDDI and the requester can join to it using SOAP.
SOAP, originally defined as Simple Object Access Protocol, is a protocol specification for exchanging structured information in the implementation of Web Services in computer networks. It relies on XML Information Set for its message format, and usually relies on other Application Layer protocols, most notably Hypertext Transfer Protocol (HTTP) or Simple Mail Transfer Protocol (SMTP), for message negotiation and transmission.
SOAP can form the foundation layer of a web services protocol stack, providing a basic messaging framework upon which web services can be built. This XML based protocol consists of three parts: an envelope, which defines what is in the message and how to process it, a set of encoding rules for expressing instances of application-defined datatypes, and a convention for representing procedure calls and responses. SOAP has three major characteristics: Extensibility (security and WS-routing are among the extensions under development), Neutrality (SOAP can be used over any transport protocol such as HTTP, SMTP, TCP, or JMS) and Independence (SOAP allows for any programming model). As an example of how SOAP procedures can be used, a SOAP message could be sent to a web site that has web services enabled, such as a real-estate price database, with the parameters needed for a search. The site would then return an XML-formatted document with the resulting data, e.g., prices, location, features. With the data being returned in a standardized machine-parsable format, it can then be integrated directly into a third-party web site or application.
The SOAP architecture consists of several layers of specifications for: message format, Message Exchange Patterns (MEP), underlying transport protocol bindings, message processing models, and protocol extensibility. SOAP is the successor of XML-RPC, though it borrows its transport and interaction neutrality and the envelope/header/body from elsewhere (probably from WDDX).
SOAP was designed as an object-access protocol in 1998 by Dave Winer, Don Box, Bob Atkinson, and Mohsen Al-Ghosein for Microsoft, where Atkinson and Al-Ghosein were working at the time. The SOAP specification is currently maintained by the XML Protocol Working Group of the World Wide Web Consortium.
SOAP originally stood for 'Simple Object Access Protocol' but this acronym was dropped with Version 1.2 of the standard. Version 1.2 became a W3C recommendation on June 24, 2003. The acronym is sometimes confused with SOA, which stands for Service-oriented architecture, but the acronyms are unrelated.
After SOAP was first introduced, it became the underlying layer of a more complex set of Web Services, based on Web Services Description Language (WSDL) and Universal Description Discovery and Integration (UDDI). These services, especially UDDI, have proved to be of far less interest, but an appreciation of them gives a more complete understanding of the expected role of SOAP compared to how web services have actually evolved.
The SOAP specification defines the messaging framework which consists of:
The SOAP processing model defining the rules for processing a SOAP message
The SOAP extensibility model defining the concepts of SOAP features and SOAP modules
The SOAP underlying protocol binding framework describing the rules for defining a binding to an underlying protocol that can be used for exchanging SOAP messages between SOAP nodes
The SOAP message construct defining the structure of a SOAP message
The SOAP processing model describes a distributed processing model, its participants, the SOAP nodes, and how a SOAP receiver processes a SOAP message. The following SOAP nodes are defined:
SOAP sender : A SOAP node that transmits a SOAP message.
SOAP receiver : A SOAP node that accepts a SOAP message.
SOAP message path : The set of SOAP nodes through which a single SOAP message passes.
Initial SOAP sender (Originator)
The SOAP sender that originates a SOAP message at the starting point of a SOAP message path.
A SOAP intermediary is both a SOAP receiver and a SOAP sender and is targetable from within a SOAP message. It processes the SOAP header blocks targeted at it and acts to forward a SOAP message towards an ultimate SOAP receiver.
Ultimate SOAP Receiver
The SOAP receiver that is a final destination of a SOAP message. It is responsible for processing the contents of the SOAP body and any SOAP header blocks targeted at it. In some circumstances, a SOAP message might not reach an ultimate SOAP receiver, for example because of a problem at a SOAP intermediary. An ultimate SOAP receiver cannot also be a SOAP intermediary for the same SOAP message.
SOAP Building Blocks
- A SOAP message is an ordinary XML document containing the following elements:
- - A required Envelope element that identifies the XML document as a SOAP message.
- - An optional Header element that contains header information.
- - A required Body element that contains call and response information.
- - An optional Fault element that provides information about errors that occurred while processing the message.
Both SMTP and HTTP are valid application layer protocols used as Transport for SOAP, but HTTP has gained wider acceptance as it works well with today's Internet infrastructure; specifically, HTTP works well with network firewalls. SOAP may also be used over HTTPS (which is the same protocol as HTTP at the application level, but uses an encrypted transport protocol underneath) with either simple or mutual authentication; this is the advocated WS-I method to provide web service security as stated in the WS-I Basic Profile 1.1.
This is a major advantage over other distributed protocols like GIOP/IIOP or DCOM which are normally filtered by firewalls. SOAP over AMQP is yet another possibility that some implementations support.
SOAP also has the advantage over DCOM that it is unaffected by security rights being configured on the machines which require knowledge of both transmitting and receiving nodes. This allows SOAP to be loosely coupled in a way that is not possible with DCOM.
There is also the SOAP-over-UDP OASIS standard.
XML Information Set was chosen as the standard message format because of its widespread use by major corporations and open source development efforts. Typically, XML Information Set is serialized as XML. A wide variety of freely available tools significantly eases the transition to a SOAP-based implementation. The somewhat lengthy syntax of XML can be both a benefit and a drawback. While it promotes readability for humans, facilitates error detection, and avoids interoperability problems such as byte-order (Endianness), it can slow processing speed and can be cumbersome. For example, CORBA, GIOP, ICE, and DCOM use much shorter, binary message formats. On the other hand, hardware appliances are available to accelerate processing of XML messages. Binary XML is also being explored as a means for streamlining the throughput requirements of XML. XML messages by their self documenting nature usually have more 'overhead' (Headers, footers, nested tags, delimiters) than actual data in contrast to earlier protocols where the overhead was usually a relatively small percentage of the overall message.
In financial messaging SOAP was found to result in a 2-4 times larger message than previous protocols (FIX (Financial Information Exchange) and CDR Common Data Representation)
It is important to note that XML Information Set does not require to be serialized in XML. For instance, a CSV or JSON XML-infoset representation exists. There is also no need to specify a generic transformation framework. The concept of SOAP bindings allows for specific bindings for a specific application. The drawback is that both the senders and receivers have to support this newly defined binding.
Java API for XML Processing JAXP
The Java API for XML Processing, or JAXP (/'d?ækspi?/ jaks-pee), is one of the Java XML Application programming interfaces (API)s. It provides the capability of validating and parsing XML documents. The three basic parsing interfaces are:the Document Object Model parsing interface or DOM interface the Simple API for XML parsing interface or SAX interface the Streaming API for XML or StAX interface (part of JDK 6; separate jar available for JDK 5) In addition to the parsing interfaces, the API provides an XSLT interface to provide data and structural transformations on an XML document. JAXP was developed under the Java Community Process as JSR 5 (JAXP 1.0) and JSR 63 (JAXP 1.1 and 1.2).
JAXP version 1.4.4 was released on September 3, 2010. JAXP 1.3 was end-of-lifed on February 12, 2008.
The DOM interface is perhaps the easiest to understand. It parses an entire XML document and constructs a complete in-memory representation of the document using the classes modeling the concepts found in the Document Object Model(DOM) Level 2 Core Specification.
The DOM parser is called a DocumentBuilder, as it builds an in-memory Document representation. The javax.xml.parsers.DocumentBuilder is created by the javax.xml.parsers.DocumentBuilderFactory. The DocumentBuilder creates an org.w3c.dom.Document instance, which is a tree structure containing nodes in the XML Document. Each tree node in the structure implements the org.w3c.dom.Node interface. There are many different types of tree nodes, representing the type of data found in an XML document. The most important node types are:
- element nodes that may have attributes
- text nodes representing the text found between the start and end tags of a document element.
- Refer to the Javadoc documentation of the Java package org.w3c.dom for a complete list of node types.
The SAX parser is called the SAXParser and is created by the javax.xml.parsers.SAXParserFactory. Unlike the DOM parser, the SAX parser does not create an in-memory representation of the XML document and so is faster and uses less memory. Instead, the SAX parser informs clients of the XML document structure by invoking callbacks, that is, by invoking methods on a org.xml.sax.helpers.DefaultHandler instance provided to the parser. This way of accessing document is called Streaming XML.
The DefaultHandler class implements the ContentHandler, the ErrorHandler, the DTDHandler, and the EntityResolver interfaces. Most clients will be interested in methods defined in the ContentHandler interface that are called when the SAX parser encounters the corresponding elements in the XML document. The most important methods in this interface are:
- startDocument() and endDocument() methods that are called at the start and end of a XML document.
- startElement() and endElement() methods that are called at the start and end of a document element.
- characters() method that is called with the text data contents contained between the start and end tags of an XML document element.
- Clients provide a subclass of the DefaultHandler that overrides these methods and processes the data. This may involve storing the data into a database or writing it out to a stream.
- During parsing, the parser may need to access external documents. It is possible to store a local cache for frequently used documents using an XML Catalog.
- This was introduced with Java 1.3 in May 2000.
StAX was designed as a median between the DOM and SAX interface. In its metaphor, the programmatic entry point is a cursor that represents a point within the document. The application moves the cursor forward - 'pulling' the information from the parser as it needs. This is different from an event based API - such as SAX - which 'pushes' data to the application - requiring the application to maintain state between events as necessary to keep track of location within the document.
The XML Stylesheet Language for Transformations, or XSLT, allows for conversion of an XML document into other forms of data. JAXP provides interfaces in package javax.xml.transform allowing applications to invoke an XSLT transformation. This interface was originally called TrAX (Transformation API for XML), and was developed by an informal collaboration between the developers of a number of Java XSLT processors.
Main features of the interface are :
a factory class allowing the application to select dynamically which XSLT processor it wishes to use (TransformerFactory, TransformerFactory.newInstance(), TransformerFactory.newInstance(java.lang.String, java.lang.ClassLoader))
methods on the factory class to create a Templates object, representing the compiled form of a stylesheet. This is a thread-safe object that can be used repeatedly, in series or in parallel, to apply the same stylesheet to multiple source documents (or to the same source document with different parameters) (TransformerFactory.newTemplates(javax.xml.transform.Source), also TransformerFactory.newTransformer(javax.xml.transform.Source), TransformerFactory.newTransformer())
a method on the Templates object to create a Transformer, representing the executable form of a stylesheet (Templates.newTransformer()). This cannot be shared across threads, though it is serially reusable. The Transformer provides methods to set stylesheet parameters and serialization options (for example, whether output should be indented), and a method to actually run the transformation. (Transformer.transform(javax.xml.transform.Source, javax.xml.transform.Result))
Two abstract interfaces Source and Result are defined to represent the input and output of the transformation. This is a somewhat unconventional use of Java interfaces, since there is no expectation that a processor will accept any class that implements the interface - each processor can choose which kinds of Source or Result it is prepared to handle. In practice all JAXP processors support the three standard kinds of Source (DOMSource, SAXSource, StreamSource) and the three standard kinds of Result (DOMResult, SAXResult, StreamResult) and possibly other implementations of their own.
Java Architecture for XML Binding (JAXB)
Java Architecture for XML Binding (JAXB) allows Java developers to map Java classes to XML representations. JAXB provides two main features: the ability to marshal Java objects into XML and the inverse, i.e. to unmarshal XML back into Java objects. In other words, JAXB allows storing and retrieving data in memory in any XML format, without the need to implement a specific set of XML loading and saving routines for the program's class structure. It is similar to xsd.exe and XmlSerializer in the .NET Framework.
JAXB is particularly useful when the specification is complex and changing. In such a case, regularly changing the XML Schema definitions to keep them synchronised with the Java definitions can be time consuming and error prone.
JAXB is a part of the Java SE platform and one of the APIs in the Java EE platform, and is part of the Java Web Services Development Pack (JWSDP). It is also one of the foundations for WSIT. JAXB is part of SE version 1.6.
JAXB 1.0 was developed under the Java Community Process as JSR 31. As of 2006, JAXB 2.0 is being developed under JSR 222. Reference implementations for these specifications are available under the CDDL open source license at java.net.
The tool "xjc" can be used to convert XML Schema and other schema file types (as of Java 1.6, RELAX NG, XML DTD, and WSDL are supported experimentally) to class representations. Classes are marked up using annotations from javax.xml.bind.annotation.* namespace, for example, @XmlRootElement and @XmlElement. XML list sequences are represented by attributes of type java.util.List. Marshallers and Unmarshallers are created through an instance of JAXBContext.
In addition, JAXB includes a "schemagen" tool which can essentially perform the inverse of "xjc", creating an XML Schema from a set of annotated classes.
Default data type bindings :
The table below lists the mappings of XML Schema (XSD) data types to Java data types in JAXB.
XML Schema Type Java Data Type
- xsd:string -- java.lang.String
- xsd:integer -- java.math.BigInteger
- xsd:positiveInteger -- java.math.BigInteger
- xsd:int -- int
- xsd:long -- long
- xsd:short -- short
- xsd:decimal -- java.math.BigDecimal
- xsd:float -- float
- xsd:double -- double
- xsd:boolean -- boolean
- xsd:byte -- byte
- xsd:QName -- javax.xml.namespace.QName
- xsd:dateTime -- javax.xml.datatype.XMLGregorianCalendar
- xsd:base64Binary -- byte
- xsd:hexBinary -- byte
- xsd:unsignedInt -- long
- xsd:unsignedShort -- int
- xsd:unsignedByte -- short
- xsd:unsignedLong -- java.math.BigDecimal
- xsd:time -- javax.xml.datatype.XMLGregorianCalendar
- xsd:date -- javax.xml.datatype.XMLGregorianCalendar
- xsd:g -- javax.xml.datatype.XMLGregorianCalendar
- xsd:anySimpleType (for xsd:element of this type) -- java.lang.Object
- xsd:anySimpleType (for xsd:attribute of this type) -- java.lang.String
- xsd:duration -- javax.xml.datatype.Duration
- xsd:NOTATION -- javax.xml.namespace.QName
Java API for XML Registries ( JAXR )
Java API for XML Registries (JAXR) defines a standard API for Java platform applications to access and programmatically interact with various kinds of metadata registries. JAXR is one of the Java XML programming APIs. The JAXR API was developed under the Java Community Process as JSR 93.
JAXR provides a uniform and standard Java API for accessing different kinds of XML-based metadata registry. Current implementations of JAXR support ebXML Registry version 2.0, and UDDI version 2.0. More such registries could be defined in the future. JAXR provides an API for the clients to interact with XML registries and a service provider interface (SPI) for the registry providers so they can plug in their registry implementations. The JAXR API insulates application code from the underlying registry mechanism. When writing a JAXR based client to browse or populate a registry, the code does not have to change if the registry changes, for instance from UDDI to ebXML.
Java API for XML-based RPC (JAX-RPC)
Java API for XML-based RPC (JAX-RPC) allows a Java application to invoke a Java-based Web Service with a known description while still being consistent with its WSDL description. JAX-RPC is one of the Java XML programming APIs. It can be seen as Java RMIs over Web services. JAX-RPC 2.0 was renamed JAX-WS 2.0 (Java API for XML Web Services). JAX-RPC 1 is deprecated with Java EE 6. The JAX-RPC service utilizes W3C (World Wide Web Consortium) standards like WSDL or Web Service Description Language
It works as follows:
- A Java program executes a method on a stub (local object representing the remote service)
- The stub executes routines in the JAX-RPC Runtime System (RS)
- The RS converts the remote method invocation into a SOAP message
- The RS transmits the message as an HTTP request
The advantage of such a method is that it allows the Web Service to be implemented at server-side as a Servlet or EJB container. Thus, Servlet or EJB applications are made available through Web services.
XML-RPC is a remote procedure call (RPC) protocol which uses XML to encode its calls and HTTP as a transport mechanism. "XML-RPC" also refers generically to the use of XML for remote procedure call, independently of the specific protocol. This article is about the protocol named "XML-RPC".
XML-RPC, the protocol, was created in 1998 by Dave Winer of UserLand Software and Microsoft. As new functionality was introduced, the standard evolved into what is now SOAP.
The generic use of XML for remote procedure call (RPC) was patented by Phillip Merrick, Stewart Allen, and Joseph Lapp in April 2006, claiming benefit to a provisional application filed in March 1998. The patent is assigned to webMethods, located in Fairfax, VA.
XML-RPC works by sending a HTTP request to a server implementing the protocol. The client in that case is typically software wanting to call a single method of a remote system. Multiple input parameters can be passed to the remote method, one return value is returned. The parameter types allow nesting of parameters into maps and lists, thus larger structures can be transported. Therefore XML-RPC can be used to transport objects or structures both as input and as output parameters.
Identification of clients for authorization purposes can be achieved using popular HTTP security methods. Basic access authentication is used for identification, HTTPS is used when identification (via certificates) and encrypted messages are needed. Both methods can be combined.
In comparison to REST, where resource representations (documents) are transferred, XML-RPC is designed to call methods.
XML-RPC is simpler to use and understand than SOAP because it allows only one method of method serialization, whereas SOAP defines multiple different encodings
has a simpler security model
does not require (nor support) the creation of WSDL service descriptions, although XRDL provides a simple subset of the functionality provided by WSDL
JSON-RPC is similar to XML-RPC.
- WebWork :
WebWork was a Java-based web application framework developed by OpenSymphony that merged into the current Struts2 framework. It was developed with the specific intention of improving developer productivity and code simplicity. WebWork is built on top of XWork, which provides a generic command pattern framework as well as an Inversion of Control container.
WebWork provides support for building reusable UI templates, such as form controls, UI themes, internationalization, dynamic form parameter mapping to JavaBeans, client and server side validation, etc.
Design goals and overview
This article appears to be written like an advertisement. Please help improve it by rewriting promotional content from a neutral point of view and removing any inappropriate external links. (May 2008)
In a standard Java EE web application, the client will typically submit information to the server via a web form. The information is then either handed over to a Java Servlet which processes it, interacts with a database and produces an HTML-formatted response, or it is given to a JavaServer Pages (JSP) document which intermingles HTML and Java code to achieve the same result. Both approaches are often considered inadequate for large projects because they mix application logic with presentation and make maintenance difficult.
WebWork attempts to understand existing frameworks' limitations and works to eliminate them. It supports type conversion, continuations, and interceptors. WebWork also supports multiple-view technologies like JSP, velocity, and FreeMarker.
Ultimately, WebWork has been designed and implemented with a specific set of goals, that are very important for its users. They are as follows:
- Web Designer never has to touch Java code
- Create multiple "Web Skins" for an application
- Change Look and Feel
- Change Layout on a given Web Page
- Change Flow among Web Pages
- Move *existing* data elements from one page to another
- Integrate with various backend infrastructures
- Reuse components
- Perform internationalization (i18n) of a web application
- Keep the API small and to the point
- Ability to learn WebWork fast, by making all the fancier features optional
- Allow the developer to choose how to implement as much as possible, while providing default implementations that work well in most cases
The architecture of WebWork is based on the MVC, Command, and Dispatcher patterns and the principle of Inversion of Control. The life cycle of a WebWork request begins when the servlet container receives a new request. The new request is passed through a set of filters called the filter chain and sent to the FilterDispatcher. The FilterDispatcher forwards the request to the ActionMapper to determine what needs to be done with the request. If the request requires an action, it sends an ActionMapping object back to the FilterDispatcher. If not, ActionMapper returns a null object, indicating that no action needs to be taken. The FilterDispatcher forwards the request and the ActionMapper object to the ActionProxy for further action. The ActionProxy invokes the Configuration File manager to get the attributes of the action, which is stored in the xwork.xml file and creates an ActionInvocation object. The ActionInvocation object contains attributes like the action, invocation context, result, result code, etc. The configuration file manager has access to these configuration files and is used by the ActionProxy as a gateway to the configuration files. The ActionInvocation object also has information about Interceptors that need to be invoked after or before an action is executed.
ActionInvocation invokes all the interceptors listed in the ActionInvocation object and then invokes the actual action. When the action is completed, ActionInvocation gets the action result code from the execution. It uses the action result code to look up the appropriate result, which is usually a JSP page, a velocity template or a freemarker template associated with the result code. ActionInvocation also executes the interceptors again in the reverse order and returns the response as a HttpServletResponse.
- Liferay Portal :
Liferay Portal is a free and open source enterprise portal written in Java and distributed under the GNU Lesser General Public License and proprietary licenses. It is primarily used to power corporate intranets and extranets.
Liferay Portal allows users to set up features common to websites. It is fundamentally constructed of functional units called portlets. Liferay is sometimes described as a content management framework or a web application framework. Liferay's support for plugins extends into multiple programming languages, including support for PHP and Ruby portlets.
Although Liferay offers a sophisticated programming interface for developers, no programming skills are required for basic website installation and administration.
Liferay Portal is Java-based and runs on any computing platform capable of running the Java Runtime Environment and an application server. Liferay is available bundled with a servlet container such as Apache Tomcat.
Liferay, Inc., is a professional open-source company that provides free documentation and paid professional service to users of its software. Mainly focused on enterprise portal technology, the company has its headquarters in Los Angeles, California, United States.
Liferay was created in 2000 by chief software architect Brian Chan to provide an enterprise portal solution for non-profit organizations. In 2004, the company was incorporated under the name Liferay, Inc., formalized its Germany subsidiary Liferay GmbH. In 2007, the company opened new Asian headquarters in Dalian, China, and the Spanish subsidiary Liferay SL. In March 2009, the company opened a new office in Bangalore, India.
Sun Microsystems and Liferay signed a technology-sharing agreement during May 2008. Sun Microsystems rebranded the offering GlassFish Web Space Server. ZDNet further describes the relationship in the May 2008 article Sun and Liferay launch web-presentation platform. In 2010 Sun was acquired by Oracle and the GlassFish Web Space Server was rebranded to Oracle GlassFish Server.
Liferay 6.1 was released in January 2012 and saw several improvements and new functionality including an improved document library, dynamic data lists and an app store
This section does not cite any references or sources. Please help improve this section by adding citations to reliable sources. Unsourced material may be challenged and removed. (February 2012)
Liferay Portal is a JSR-286 and enterprise portal which includes a suite of applications (e.g., Content Management System, blogs, instant messaging, message boards, etc.). It is distributed in two different editions:
Liferay Portal Community Edition : A version with the latest features and support through the active community.
Liferay Portal Enterprise Edition : A commercial offering that includes services including updates and full support. This release goes through additional quality assurance cycles and is usually available around 1 or 2 months after the Community Edition and comes under a non-free license.
Liferay also provides a collaboration suite based on the Liferay platform:
Liferay Social Office : A social collaboration suite for enterprises.
Liferay comes with certain portlets preinstalled. These comprise the core functionality of the portal system. They include:
- Alerts and Announcements
- Alfresco, Documentum, and other document library integration
- Asset Publishing
- Blogs and blog aggregation
- Document and Image management
- Document Library Manager, Recent Documents
- Image Gallery
- Knowledge Basev
- LDAP Integration
- Message Boards
- Nested Portlets
- Page Ratings & Flags
- Site Map
- Site Navigation
- Social Equity
- Software Catalog
- Tags and Categories
- Themes, supporting Velocity and FreeMarker markup
- User Directory
- Web Content
- Web Form Builder
- WebDAV Integration
- Website Tools
- Wiki (supports Creole as well as MediaWiki syntax)
- ZK (Framework) :
The core of ZK consists of an Ajax-based event-driven mechanism, over 123 XUL and 83 XHTML-based components, and a markup language for designing user interfaces. Programmers design their application pages in feature-rich XUL/XHTML components, and manipulate them upon events triggered by end user's activity. It is similar to the programming model found in desktop GUI-based applications.
ZK takes the so-called server-centric approach that the content synchronization of components and the event pipelining between clients and servers are automatically done by the engine and Ajax plumbing codes are completely transparent to web application developers. Therefore, the end users get the similar engaged interactivity and responsiveness as a desktop application, while programmers' development retains a similar simplicity to that of desktop applications.
Meanwhile, with the so-called server+client fusion, the optional client-side customization allows the developer to leverage the client-side resources, to custom the look and feel and to reduce the Ajax traffic.
In addition to component-based programming in a manner similar to Swing, ZK supports a markup language for rich user interface definition called ZUML.
- ZUML is designed for non-programmer developers to design user interfaces intuitively.
- ZUML allows developers to meld different markup languages, such as Mozilla XUL language and XHTML, seamlessly into the same page.
- ZUML allows developers to embed scripts in pure Java language (interpreted by BeanShell) and use EL expressions to manipulate the components and access data.
Over 100 Ajax components offer UI designers a variety of feature rich components to meet the demands of enterprise Ajax applications. ZUML makes the design of rich user interfaces similar to authoring HTML pages. ZUML is a variant of XUL inheriting all features available to XML, and separates the UI definition from the run-time logic.
- Event-driven component-based model (similar to desktop programming models).
- Support for Model-View-Controller (MVC) decoupling View, Model and Controller for easy to develop and maintain.
- Support for Model-View-Presenter and Model-View-ViewModel (MVVM) design patterns that decouples the controller furthermore to minimize the code required and to maximize the maintainability.
Databinding capability via in-ZUML-page annotations that transparently automates CRUD and state synchronization between UI view and the data and POJO.
Application components, such as spreadsheet, pivot table, and calendar.
Support for integrating with existing web frameworks via a JSP custom tag library, JSF support, Portlet, and a Servlet Filter. Has support for Spring and Hibernate.
Extensible in that programmers can create new custom UI controls. Groups of controls can be re-used as a macro component.
Differences from XUL
ZK is a server side framework which emits HTML and thus does not depend on client side presence of Gecko making it portable to any browser. ZK takes ZUML (xul and xhtml) serverside pages as input and outputs dhtml for the browser.
ZK processes user interface logic on the server in Java. This increases choice in the scripting engines and application libraries that can be used to create logic. Presentation effects can be delegated to the browser using the Client-side Actions feature to reduce server load for dhtml effects. Running the application logic on the server in a single application container reduces the amount of cross browser and browser version testing when compared to extensively programming the DOM at the browser.
While ZK and XUL have an overlapping subset of components, ZK has its own unique component sets. The component library can be extended with custom components. Macro components can be defined that are composites of components.
ZK provides serverside databinding annotations to declaratively bind UI components to serverside data. Look and Feel differences.
- ZUML (ZK User Interface Markup Language) is a markup language for rich user interfaces definition.
- ZUML is designed for non-programmers to design user interfaces efficiently with the ZUML markup
- ZUML allows developer to meld different markup languages, such as Mozilla XUL language and XHTML, seamlessly into the same page.
- ZUML allows developers to embed script in pure Java language (interpreted by BeanShell) and use EL expressions to manipulate the components and access data.
- ZUML is supported by ZK.
ZK is a server-centric framework. Technically you don't need to know about the implementation at the client side. It is how ZK Mobile running on Java Mobile VM is done. Since ZK 5.0, the so-called Server+client Fusion architecture is introduced. Developers are allowed to access the client-side widgets directly if they want to. ZK Client Engine is based on jQuery. Technically you can use jQuery-compliant libraries and widgets.
- Stripes Framework :
Stripes is an open source web application framework based on the model - view - controller (MVC) pattern. It aims to be a lighter weight framework than Struts by using Java technologies such as annotations and generics that were introduced in Java 1.5, to achieve "convention over configuration". This emphasizes the idea that a set of simple conventions used throughout the framework reduce configuration overhead. In practice, this means that Stripe applications barely need any configuration files, thus reducing development and maintenance work.
- Action based MVC framework
- No configuration files
- Annotations replace XML configuration files
- Flexible and simple parameter binding
- Search engine friendly URLs
- Runs in J2EE web container
- JUnit integration
- Easy internationalization
- Wizard support
- JSP layouts
- JSP or freemarker templates as View
- Spring integration
- JPA support
- AJAX support
- Fileupload support
- Compatible with Google App Engine
- Apache Wicket :
Apache Wicket, commonly referred to as Wicket, is a lightweight component-based web application framework for the Java programming language conceptually similar to JavaServer Faces and Tapestry. It was originally written by Jonathan Locke in April 2004. Version 1.0 was released in June 2005. It graduated into an Apache top-level project in June 2007.
Traditional model-view-controller (MVC) frameworks work in terms of whole requests and whole pages. In each request cycle, the incoming request is mapped to a method on a controller object, which then generates the outgoing response in its entirety, usually by pulling data out of a model to populate a view written in specialised template markup. This keeps the application's flow-of-control simple and clear, but can make code reuse in the controller difficult.
In contrast, Wicket is closely patterned after stateful GUI frameworks such as Swing. Wicket applications are trees of components, which use listener delegates to react to HTTP requests against links and forms in the same way that Swing components react to mouse and keystroke events. Wicket is categorized as a component-based framework.
Wicket uses plain XHTML for templating (which enforces a clear separation of presentation and business logic and allows templates to be edited with conventional WYSIWYG design tools). Each component is bound to a named element in the XHTML and becomes responsible for rendering that element in the final output. The page is simply the top-level containing component and is paired with exactly one XHTML template. Using a special tag, a group of individual components may be abstracted into a single component called a panel, which can then be reused whole in that page, other pages, or even other panels.
Each component is backed by its own model, which represents the state of the component. The framework does not have knowledge of how components interact with their models, which are treated as opaque objects automatically serialized and persisted between requests. More complex models, however, may be made detachable and provide hooks to arrange their own storage and restoration at the beginning and end of each request cycle. Wicket does not mandate any particular object-persistence or ORM layer, so applications often use some combination of Hibernate objects, EJBs or POJOs as models.
In Wicket, all server side state is automatically managed. You will never directly use an HttpSession object or similar wrapper to store state. Instead, state is associated with components. Each server-side page component holds a nested hierarchy of stateful components, where each component’s model is, in the end, a POJO (Plain Old Java Object)
Wicket is all about simplicity. There are no configuration files to learn in Wicket. Wicket is a simple class library with a consistent approach to component structure
- Apache Tapestry :
Apache Tapestry is an open-source component-oriented Java web application framework conceptually similar to JavaServer Faces and Apache Wicket. Tapestry was created by Howard Lewis Ship, and was adopted by the Apache Software Foundation as a top-level project in 2006.
Tapestry emphasizes simplicity, ease of use, and developer productivity. It adheres to the Convention over Configuration paradigm, eliminating almost all XML configuration. Tapestry uses a modular approach to web development, by having a strong binding between each user interface component (object) on the web page and its corresponding Java class. This component-based architecture borrows many ideas from WebObjects.
Live Class Reloading : Tapestry monitors the file system for changes to Java page classes, component classes, service implementation classes, HTML templates and component property files, and it hot-swaps the changes into the running application without requiring a restart. This provides a very short code-save-view feedback cycle that is claimed to greatly improve developer productivity.
Component-based : Pages may be constructed with small nestable components, each having a template and component class. Custom components are purportedly trivial to construct.
Convention over configuration : Tapestry uses naming conventions and annotations, rather than XML, to configure the application.
Spare use of HTTPSession : By making minimal use of the HTTPSession, Tapestry is designed to be highly efficient in a clustered, session-replicated environment.
Post/Redirect/Get : Most form submissions follow the Post/Redirect/Get (PRG) pattern, which reduces multiple form submission accidents and makes URLs friendlier and more bookmarkable, along with enabling the browser Back and Refresh buttons to operate normally.
Inversion of Control (IOC) : Tapestry is built on a lightweight Inversion of Control layer with similarities to Google Guice but designed to make nearly all aspects of Tapestry's behavior configurable and replaceable.
- Apache Velocity :
Apache Velocity is a Java-based template engine that provides a template language to reference objects defined in Java code. It is an open source software project directed by the Apache Software Foundation and aims to ensure clean separation between the presentation tier and business tiers in a Web application (the model-view-controller design pattern).
Some common types of applications that use Velocity are:
Web applications: Web designers create HTML pages with placeholders for dynamic information. The page is processed with VelocityViewServlet or any of a number of frameworks which support Velocity.
Source code generation : Velocity can be used to generate Java source code, SQL, or PostScript, based on templates. A number of open source and commercial development software packages use Velocity in this manner.
Automatic Emails: Many applications generate automatic emails for account signup, password reminders, or automatically sent reports. Using Velocity, the email template can be stored in a text file, rather than directly embedded in Java code.
XML transformation : Velocity provides an Ant task, called Anakia, which reads an XML file and makes it available to a Velocity template. A common application is to convert documentation stored in a generic "xdoc" format into a styled HTML document.
- J2ee Solutions
- Spring -Spring Mvc-Hibernate
- Java Server Faces-Hibernate
- Struts 1.3 - Hibernate
- Struts 2.0 - Hibernate
- Xml based Web Services
- Liferay Portal - Hibernate
- Socket Prog - Swings/JFace
- RMI - Swings/Swt/JFace
- EJB 2.0 - Swings/Swt/JFace
- EJB 3.0 - Swings/Swt/JFace
- Jms - Ejb -Swings/Swt/JFace
- CORBA - JCA - Swings
- Spring Remote Access
- Active JDBC
- iBATIS / MyBatis
- Java Data Objects (JDO)
- Java Object Querying (jOOQ)
- Java Persistence API (JPA)
- Apache Tomcat
- Apache Geronimo
- Sun One
- BEA Weblogic
- IBM Websphere
- SAP Netweaver
- Jasper Reports
- Eclipse Birt
- JFree Report
- Open Reports
A solid working knowledge of productivity software and other IT tools has become a basic foundation for success in virtually any career. Beyond that, however, I don't think you can overemphasise the importance of having a good background in maths and science.....
"Every software system needs to have a simple yet powerful organizational philosophy (think of it as the software equivalent of a sound bite that describes the system's architecture)... A step in thr development process is to articulate this architectural framework, so that we might have a stable foundation upon which to evolve the system's function points. "
"All architecture is design but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change"
"The ultimate measurement is effectiveness, not efficiency "
"It is argued that software architecture is an effective tool to cut development cost and time and to increase the quality of a system. "Architecture-centric methods and agile approaches." Agile Processes in Software Engineering and Extreme Programming.
"Java is C++ without the guns, knives, and clubs "
"When done well, software is invisible"
"Our words are built on the objects of our experience. They have acquired their effectiveness by adapting themselves to the occurrences of our everyday world."
"I always knew that one day Smalltalk would replace Java. I just didn't know it would be called Ruby. "
"The best way to predict the future is to invent it."
"In 30 years Lisp will likely be ahead of C++/Java (but behind something else)"
"Possibly the only real object-oriented system in working order. (About Internet)"
"Simple things should be simple, complex things should be possible. "
"Software engineering is the establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines."
"Model Driven Architecture is a style of enterprise application development and integration, based on using automated tools to build system independent models and transform them into efficient implementations. "
"The Internet was done so well that most people think of it as a natural resource like the Pacific Ocean, rather than something that was man-made. When was the last time a technology with a scale like that was so error-free? The Web, in comparison, is a joke. The Web was done by amateurs. "
"Software Engineering Economics is an invaluable guide to determining software costs, applying the fundamental concepts of microeconomics to software engineering, and utilizing economic analysis in software engineering decision making. "
"Ultimately, discovery and invention are both problems of classification, and classification is fundamentally a problem of finding sameness. When we classify, we seek to group things that have a common structure or exhibit a common behavior. "
"Perhaps the greatest strength of an object-oriented approach to development is that it offers a mechanism that captures a model of the real world. "
"The entire history of software engineering is that of the rise in levels of abstraction. "
"The amateur software engineer is always in search of magic, some sensational method or tool whose application promises to render software development trivial. It is the mark of the professional software engineer to know that no such panacea exist "
Core Values ?Agile And Scrum Based Architecture
Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration.....more
Core Values ?Total quality management
Total Quality Management / TQM is an integrative philosophy of management for continuously improving the quality of products and processes. TQM is based on the premise that the quality of products and .....more
Core Values ?Design that Matters
We are more than code junkies. We're a company that cares how a product works and what it says to its users. There is no reason why your custom software should be difficult to understand.....more
Core Values ?Expertise that is Second to None
With extensive software development experience, our development team is up for any challenge within the Great Plains development environment. our Research works on IEEE international papers are consider....more
Core Values ?Solutions that Deliver Results
We have a proven track record of developing and delivering solutions that have resulted in reduced costs, time savings, and increased efficiency. Our clients are very much ....more
Core Values ?Relentless Software Testing
We simply dont release anything that isnt tested well. Tell us something cant be tested under automation, and we will go prove it can be. We create tests before we write the complementary production software......more
Core Values ?Unparalled Technical Support
If a customer needs technical support for one of our products, no-one can do it better than us. Our offices are open from 9am until 9pm Monday to Friday, and soon to be 24hours. Unlike many companies, you are able to....more
Core Values ?Impressive Results
We have a reputation for process genius, fanatical testing, high quality, and software joy. Whatever your business, our methods will work well in your field. We have done work in Erp Solutions ,e-commerce, Portal Solutions,IEEE Research....more
Why Choose Us ?
The intellectual commitment of our development team is central to the leonsoft ability to achieve its mission: to develop principled, innovative thought leaders in global communities.Read More
Today's most successful enterprise applications were once nothing more than an idea in someone's head. While many of these applications are planned and budgeted from the beginning.Read More
We constantly strive to redefine the standard of excellence in everything we do. We encourage both individuals and teams to constantly strive for developing innovative technologies....Read More
If our customers are the foundation of our business, then integrity is the cornerstone. Everything we do is guided by what is right. We live by the highest ethical standards.....Read More