WebObjects

WebObjects is a Java web application server from Apple Inc., and a web application framework that runs on the server. It is available, at no additional cost, as part of the Xcode Developer Tools included with Apple’s Mac OS X operating system. Its basic  features are its deep object-orientation, powerful database connectivity, and rapid prototyping tools. Applications created with WebObjects can be deployed as web sites, Java Web Start desktop applications, and/or standards-based web services.

Tools

As of 2008 most WebObjects architects and engineers are using the tools being developed by the WebObjects community. These tools run within the Eclipse IDE and are open-source. The WebObjects plug-ins for Eclipse are known as WOLips.

Building WebObjects frameworks and applications for deployment is typically achieved using the WOProject set of tools for Apache Ant or Apache Maven. These tools are distributed with WOLips.

The centerpiece of these tools is Monitor, itself a WebObjects application that manages all the different WebObjects applications and the servers on which they are running. You can use Monitor to start and stop instances, generate statistics, and configure how applications run. Other tools enable you to record and play back sessions for both functional and stress testing.

History of WebObjects

WebObjects was fully transitioned from a stand-alone product to an integral part of the Mac OS X platform with the release of version 5.3 in June 2005. The developer tools and frameworks were bundled with Apple’s Xcode IDE. A corollary of this move was that support for other platforms, such as Windows, was discontinued.

Apple had decided to concentrate its engineering resources on the runtime engine of WebObjects, leaving the future responsibility for developer applications with the open source community. The main open source alternative — the Eclipse IDE with the WOLips suite of plugins — had matured to such an extent that its capabilities had, in many areas, surpassed those of Apple’s own tools, which had not seen significant updates for a number of years.

WebObjects 5.4, which shipped with Mac OS X Leopard in October 2007, eliminated the license key requirement for both development and deployment of WebObjects applications on all platforms. All methods for checking license limitations were deprecated

Features

WebObjects makes it easy to develop and deploy enterprise-level web services and Java server applications — while giving you the agility to respond quickly to change.

A rapid application development environment with web services, data access and page generation capabilities, WebObjects extends your reach by ensuring flexible, maintainable design.WebObjects gives you the ability to build or use standards-based web services without writing low-level SOAP, XML or WSDL. Tools enable code-free generation, configuration and testing of web services from existing data assets. These standards-based web services can interoperate with clients written in many languages, including Java, AppleScript, Perl and .Net — opening up enterprise development to a new class of programmers.

Built on a classic three-tier architecture with clustering support, WebObjects allows you to deliver maintainable, scalable applications. You can create enterprise-level web services backed by robust business logic and relational databases — using visual tools to reverse-engineer your JDBC or JNDI data sources and object-oriented frameworks to transparently handle data persistence.

Beyond web services, WebObjects can help you rapidly build database applications that have HTML, XML, SMIL or Swing (Java) interfaces, depending on your needs. Generate code-free applications that provide rich Java client interfaces or HTML with the click of a button. You can choose to use Assistants for easy customization of layout and function — or exercise full control by freezing components for direct access to the code.

Support for J2EE technologies, including Servlet integration and an Object Request Broker (ORB), allows you to mix and match. JSP programmers can use the automated data persistence of WebObjects as an alternative to complex EJBs. Others can host third-party beans or write their own. And your deployment platform is up to you: Choose virtually any J2EE-capable server or use the included WebObjects J2SE application server.

Core WebObjects frameworks

A WebObjects application is essentially a server-side executable, created by combining prebuilt application framework objects with the developer’s own custom code. WebObjects’ frameworks can be broken down into three core parts:

• The WebObjects Framework (WOF) is at the highest level of the system. It is responsible for the application’s user interface and state management. It uses a template-based approach to take that object graph and turn it into HTML, or other tag-based information display standards, such as XML or SMIL. It provides an environment where you can use and create reusable components. Components are chunks of presentation (HTML) and functionality (Java code) often with a parameter list to enhance reusability. WebObjects Builder is used to create the HTML-templates and creates the .wod-file linking, for instance, a Java String object to interface objects like an input field in a web form.
• The Enterprise Objects Framework (EOF) is, perhaps, the hallmark feature of WebObjects. EOF communicates with relational databases and turns database rows into an object graph. Using EOModeler the developer can create an abstraction of the database in the forms of Java objects. In order to access or insert information into the database the developer simply accesses the Java Enterprise Objects (EOs) from their business logic. After that EOF manages the Enterprise Objects and automatically creates the required SQL-code to commit the changes to the database.

• Java Foundation. Both Enterprise Objects and WebObjects rest on the Java Foundation classes. This framework contains the fundamental data structure implementations and utilities used throughout the rest of WebObjects. Examples include basic value and collection classes, such as arrays, dictionaries (objects that contain key-value pairs) and formatting classes. Java Foundation is similar to the Foundation framework contained in Apple’s Cocoa API for Mac OS X desktop applications, however Java Foundation is written in Pure Java as opposed to Cocoa’s Objective-C (with its Java bridge runtime wrapper). Foundation classes are prefixed with the letters “NS” (a reference to their NeXTStep OS heritage). Since the transition of WebObjects to Java in 2000, the functionality of many of Apple’s Java Foundation classes is replicated in the Sun’s own JDK. However, they persist largely for reasons of backwards-compatibility and developers are free to use whichever frameworks they prefer.

Advantages of WebObjects

WebObjects has a number of key technologies that differentiate it from some application servers:

• Zero Cost: The tools and frameworks required to develop and deploy WebObjects applications are free-of-charge.
• Streamlined Database Access: Database tables are represented in WebObjects as collections of Java classes called Enterprise Objects. The developer creates a “model” that maps objects to database rows. This high level of abstraction relieves developers from the drudgery of writing inflexible, database-specific code. With the use of drivers, such as JDBC, WebObjects automatically handles the writing of appropriate SQL code.
• Separation of Presentation Logic, Business Logic, and Data: WebObjects conforms to the MVC programming paradigm, enforcing a clean separation of presentation (Web pages), logic (Java code) and data (data store).
• State Management: Without using cookies, WebObjects provides objects that allow you to maintain information for the life of a particular user session, or longer.
• Pure Java: WebObjects applications are 100% Pure Java, which means they can be deployed on any platform with a certified Java 2 virtual machine.
• Scalability and Performance: Administrators run multiple instances of an application, either on one or on multiple application servers. Developers can choose from one of several load-balancing algorithms (or create their own).

Made by Andreea Oniga

Axis2 vs CXF vs Metro

Capabilities

Both Axis2 and CFX also evolved from existing projects. Axis2 came from the well known Axis 1.x series. CXF is literally the offspring of the XFire and Celtix projects, as those two projects have pooled their codebases and development teams to give rise to CXF. The delta between the old projects and their new versions is significant in each case. Axis2 is a total rewrite of Axis from the ground up, using a new modular architecture that allows its functionality to be more easily extended. CXF has also been extensively retooled from its Xfire and Celtix origins. Both Axis2 and CXF provide migration guides that give developers tips on how to migrate from their previous versions, but as of this writing neither project has provided migration tools or guides for porting web services from one framework to another. In such a migration, though, it’s always worth looking at all the options available. Axis2 and CXF each take different approaches to web service development and these approaches will appeal more to some developers than others.

CXF: has support for WS-Addressing, WS-Policy, WS-RM, WS-Security, and WS-I BasicProfile. Axis2 supports each of these except for WS-Policy, which will be supported in an upcoming version.

CXF was written with Spring in mind; Axis2 is not.

Axis2 supports a wider range of data bindings, including XMLBeans, JiBX, JaxMe and JaxBRI as well as its own native data binding, ADB. Note that support for JaxME and JaxBRI are still considered experimental in Axis2 1.2. CXF currently supports only JAXB and Aegis; support for XMLBeans, JiBX and Castor will come in CXF 2.1.

Axis2 supports multiple languages — there is a C/C++ version available in addition to the Java version.

In comparing these frameworks, though, it’s just as important to look at their approach to developing web services as it is to compare features. From a developer perspective, both frameworks behave very differently from one another. Axis2 has taken an approach that makes it in many ways resemble an application server in miniature. Axis2 comes packaged with a WAR that can be deployed on a servlet container such as Tomcat that is designed to make web services easier to manage and deploy on the fly. The Axis2 Web Administration module allows Axis2 to be configured dynamically while applications are running: new services can be uploaded, activated or deactivated and their parameters may be changed. The administration UI also allows modules to be enabled on one or more running services.

The only downside to using the UI for these purposes is the fact that configuration changes made through it are not persistent — they go away when the servlet container is restarted.

Axis2 lends itself towards web services that stand alone, independent of other applications, and offers a wide variety of functionality, and a good model for adding more functionality as time goes on through its modular architecture. Some developers may find that a little too cumbersome or heavy-duty for their needs. These developers might prefer to look at Apache CXF.

CXF concentrates on developer ergonomics and embeddability. Most configurations are done via the API instead of cumbersome XML files, Spring integration is heavily emphasized, including support for Spring 2.0, and CXF’s APIs and Spring configuration mirror one another fairly closely. CXF emphasizes code-first design, using simple APIs to make development of services from existing applications easier (and its embeddability helps too).

As regarding Metro, the Java API for XML based Web Services is the successor of the JAXRPC specification. JAX-WS respectively its predecessor is message based and supports asynchronous communication. The Configuration is managed by annotations therefore Java 5 or higher is required. JAX-WS isn’t downwardly compatible to its predecessor JAX-RPC. With JAXWS it is pretty easy to write and consume Web Services. The default values of numerous parameters are comfortable for the programmer, so that simple Pojos declared with a @WebService annotation can be used as a Service.

Metro is documented in detail. Apart from the JAX-WS, JAXB and JWS specifications there are numerous tutorials und samples. The Netbeans IDE as well as the tutorials of the enterprise pack makes it particularly easy to get started. Of course, Eclipse can also be used for the development with Metro. Web applications containing Web Services which have been realized with JAX-WS are executable in the Glassfish Application Server. To make services also executable in other application servers, two libraries (JAX-WS and JAXB) have to be installed. Application servers such as JBoss, WebSphere or Tomcat can be upgraded with JAX-WS within about 10 minutes.

Performance

Due to the modern streaming XML parser, the performance of all three SOAP engines is very well. The ping time for a locale roundtrip is about 2-4 milliseconds (message size about 3KB, Dual Core Notebook). Therefore the time delay by the SOAP communication is negligible in many projects.

WS-* Standards

The support of the WS-Standard family can also be decisive for the selection of a SOAP engine. For example, messages sent to services can be secured with signatures as described in the Web Service Security standard (in short WSS). Table 1 shows the support for WS*-Standards of the toolkits. The following table summarizes the standards implemented by each framework:

Conclusion

None of the Web Services frameworks is in general superior to the others. Axis 2 is structured modularly, has many features and can be used as an application server for Web Services. A special feature of Axis 2 is the support of removable binding frameworks, for example XMLBeans. Axis 2 together with the XMLBeans framework included is well suited for Web Services which are using very complex schema definitions. The disadvantages of Axis 2 are its complexity as well as the insufficient JAX-WS support. Therefore anyone who wants to work with JAX-WS should choose Apache CXF or the reference implementation. Those who prefer a seamless integration with the Spring framework are well advised with the JAX-WS implementation.

Furthermore CXF is slim and easy to use. CXF is the tool of choice if a SOAP engine has to be embedded into existing software. Who just wants to code against the standard is well advised with the JAX-WS implementation.

Made by: Arpad Sebesi

Metro, Axis2, CFX

Metro

Metro is a high-performance, extensible, easy-to-use web service stack. The Metro web service stack is a part of the GlassFish community, but it can be also used outside GlassFish. It provides several transports and related technologies to provide efficient connectivity to different services:

HTTP transport

Metro can act as both a client and a server for HTTP. The HTTP web service can run inside any servlet container or anywhere on JavaSE6.

MTOM and XOP

These specifications enable optimized binary encodings of XML content within SOAP 1.2 payloads. XML structure is preserved in a text-based “XML Information Set” manifest, while enabling the document’s contents to be serialized to any binary encoding. These specifications enable encoding of XML content as MIME body parts and encapsulation of those parts – along with the associated XML Information Set manifest — within SOAP 1.2 envelopes. The specifications also describe how to encapsulate binary-encoded XML body parts directly within HTTP packets. The main point is that the size of the XML is reduced resulting in more optimal communication.

SOAP/TCP

SOAP over TCP transport enables highly efficient transmission of SOAP messages by using FastInfoset. Transport support in Metro is extensible. There are other transports available as well, including the in-VM transport, JMS transport, SMTP transport, etc.

Reliability, in Metro, ensures that the underlying system is able to recover from failures caused by messages that are lost or misordered in transit. Recovery is handled by the underlying system without involvement of consumer or provider application code.

Interoperable reliability is achieved by implementing the WS-ReliableMessaging specification. Turning on reliability, in Metro, when developing a web service, is simply a checkbox in a reliability panel in NetBeans.

Atomic transactions are a well-known means to ensure that all operations within a transaction boundary succeed or fail in a consistent manner. If even one operation fails then all other operations are aborted. Transactional support has been available in Java Enterprise Edition for a number of years on IIOP invocations. Metro enables transactional support for web services. Interoperable atomic transactions are enabled, in Metro, by implementing the WSCoordination and WS-AtomicTransactions specifications.

Web services, until now, have relied on transport-based security such as SSL to provide point-to-point security. Metro implements the WS-Security specification to provide interoperable message content integrity and confidentiality, even in the presence of intermediaries. In other words, WS-Security does not rely on transport-based security. WS-Security is a security option provided by Metro besides existing transport security which still may be used. Metro also provides an implementation of the WS-Trust specification as a means for issuing, renewing, and validating security tokens used by WS-Security, and to establish and broker trust relationships.

The core of Metro implements the JAX-WS API and serves as the foundation where all the higher-level features plugs in. The extensibility in this layer enables “pay as you go” model, where you’ll only pay the performance/complexity price for features that you use. The core also provides the basic interoperability features, such as WS-I Basic Profile, WS-I Attachments Profile, and WS-Addressing. Metro builds on top of libraries that are independently reusable outside the context of web services. Those include:

1. JAXB RI for the databinding layer

2. SAAJ for raw DOM access to SOAP messages

3. Woodstox for efficient XML parsing

4. XML stream buffer for efficient infoset buffering

Axis2

Axis2 is a clean and extensible Open Source web services platform with a configurable, modular architecture. The same business logic implementation in Axis2 offers both a SOAP endpoint and a REST interface. Otherwise the architecture is similar to Metro JAX-WS: Axis2 utilizes an XML pull parser, supports hot deployment and asynchronous web services, and can be extended to provide security and reliable messaging similar to WSIT. Apache Axis2 not only supports SOAP 1.1 and SOAP 1.2, but it also has integrated support for the widely popular REST style of Web services. The same business logic implementation can offer both a WS-* style interface as well as a REST/POX style interface simultaneously. Apache Axis2 is more efficient, more modular and more XML-oriented than the older version. It is carefully designed to support the easy addition of plug-in “modules” that extend their functionality for features such as security and reliability. The Modules currently available or under development include:

WS-ReliableMessaging - Supported by Apache Sandesha2

WS-Coordination and WS-AtomicTransaction - Supported by Apache Kandula2

WS-Security - Supported by Apache Rampart

WS-Addressing -Module included as part of Axis2 core

Apache Axis2 is built on Apache AXIOM , a new high performant, pull-based XML object model. Axis2 comes with many new features, enhancements and industry specification implementations.

The key features offered are as follows:

Speed - Axis2 uses its own object model and StAX (Streaming API for XML) parsing to achieve significantly greater speed than earlier versions of Apache Axis.

Low memory foot print- Axis2 was designed ground-up keeping low memory foot print in mind.

AXIOM - Axis2 comes with its own light-weight object model, AXIOM, for message processing which is extensible, highly performant and is developer convenient.

Hot Deployment - Axis2 is equipped with the capability of deploying Web services and handlers while the system is up and running. In other words, new services can be added to the system without having to shut down the server. Simply drop the required Web service archive into the services directory in the repository, and the deployment model will automatically deploy the service and make it available for use.

Asynchronous Web services - Axis2 now supports asynchronous Web services and asynchronous Web services invocation using non-blocking clients and transports.

MEP Support - Axis2 now comes handy with the flexibility to support Message Exchange Patterns (MEPs) with in-built support for basic MEPs defined in WSDL 2.0.

Flexibility - The Axis2 architecture gives the developer complete freedom to insert extensions into the engine for custom header processing, system management, and anything else you can imagine.

Stability - Axis2 defines a set of published interfaces which change relatively slowly compared to the rest of Axis.

Component-oriented Deployment - You can easily define reusable networks of Handlers to implement common patterns of processing for your applications, or to distribute to partners.

Transport Framework - We have a clean and simple abstraction for integrating and using Transports (i.e., senders and listeners for SOAP over various protocols such as SMTP, FTP, message-oriented middleware, etc), and the core of the engine is completely transport-independent.

WSDL support - Axis2 supports the Web Service Description Language, version 1.1 and 2.0, which allows you to easily build stubs to access remote services, and also to automatically export machine-readable descriptions of your deployed services from Axis2.

Add-ons - Several Web services specifications have been incorporated including WSS4J for security (Apache Rampart), Sandesha for reliable messaging, Kandula which is an encapsulation of WS-Coordination, WS-AtomicTransaction and WS-BusinessActivity.

Composition and Extensibility - Modules and phases improve support for composability and extensibility. Modules support composability and can also support new WS-* specifications in a simple and clean manner. They are however not hot deployable as they change the overall behavior of the system.

Apache CFX

Apache CXF is an open source services framework. CXF helps you build and develop services using frontend programming APIs, like JAX-WS. These services can speak a variety of protocols such as SOAP, XML/HTTP, RESTful HTTP, or CORBA and work over a variety of transports such as HTTP, JMS or JBI. CXF includes a broad feature set, but it is primarily focused on the following areas:

Web Services Standards Support: CXF supports a variety of web service standards including SOAP, the Basic Profile, WSDL, WS-Addressing, WS-Policy, WS ReliableMessaging, and WS-Security.

Frontends: CXF supports a variety of “frontend” programming models. CXF implements the JAX-WS APIs (version 2.0 will be TCK compliant). It also includes a “simple frontend” which allows creation of clients and endpoints without annotations. CXF supports both contract first development with WSDL and code first development starting from Java.

Ease of use: CXF is designed to be intuitive and easy to use. There are simple APIs to quickly build code-first services, Maven plug-ins to make tooling integration easy, JAX-WS API support, Spring 2.0 XML support to make configuration a snap, and much more.

Binary and Legacy Protocol Support: CXF has been designed to provide a pluggable architecture that supports not only XML but also non-XML type bindings, such as JSON and CORBA, in combination with any type of transport.

Made by: Arpad Sebesi