SOA / Web Services / Java

A Technology Blog

Archive for January, 2009

Preserve white spaces in a SOAP message

Posted by Vivek on January 30, 2009

Sometimes, the business requirement mandates that a SOAP request/response should maintain leading or trailing spaces that are present in a variable. By default, this does not happen. For example, you may expect ” ABC” or “ABC “, but you get “ABC”. The spaces are removed. Also, you may encounter issues if you use a binding mechanism like JAXB to marshal/ unmarshal xml fragments.  This requires modifying the default marshalling or unmarshalling behavior. This is how you can still maintain any whitespaces:

Before marshalling call

marshaller.setPropertyMarshaller.JAXB_ENCODING, “UTF-8”)

 which informs MarshallerImpl#createWriter(…) to create a UTF8XmlOutput instead of SAXOutput. 

UTF8XmlOutput escapes line-break into “ ”, which will be preserved when unmarshalling is performed by any xml parser.


Posted in Web Services | Tagged: , , | Leave a Comment »

Best UDDI Registries

Posted by Vivek on January 27, 2009

UDDI service registry is of paramount importance when it comes to providing a SOA Governance solution. A service registry stores metadata that is related to the particular asset you have interest in, without actually containing those assets.  It is essentially an online directory of services that enables the service providers to advertise their offerings and allowing service consumers to find services that match their criteria. It provides a foundation for the governance and lifecycle management of Business Services. It provides with what is needed to obtain enterprise-wide insight, control and economic leverage of organization’s business and service artifacts. The registry also supports metadata like classifications, categorizations, relationships and properties. These metadata are then used to define taxonomies, describe how service artifacts are related to each other and associate generic as well as object specific characteristics for service artifacts.

Here are some UDDI registries that are widely used in organizations:

1. Systinet Registry (now HP SOA Systinet Registry)  

2. Oracle Service Registry : It is a modified version of Systinet Registry. Remodeled according to Oracle needs.

3. Aqualogic Service Registry: Again a modified version of Systinet Registry.

4. IBM Web Services Registry Repository

5. TIBCO ActiveMatrix: Again a modified version of Systinet Registry.

Posted in SOA Governance | Tagged: , , , , | Leave a Comment »

5 things that suck about working in IT (and 5 things that don’t)

Posted by Vivek on January 26, 2009

Worth reading for any IT professional:


Posted in Miscellaneous | Leave a Comment »

Good Practices: Oracle BPEL

Posted by Vivek on January 26, 2009

–Do not import or add XSD files in a ZIP file into a BPEL project. Always  extract the XSD files from a ZIP file before importing them.

–Do not include any special characters in the project name (such as periods). If you do include special characters, errors appear when you attempt to compile your project

–The bpel.xml file content is only read into memory when the file is opened. Therefore, if you change the content of bpel.xml after the file is opened, the changes are not made in memory. After changing the content of the BPEL file, close and reopen the file for the changes to take effect.

–Do not edit the bpel.xml file through a combination of Oracle JDeveloper and a text editor such as Notepad or Wordpad. Use only a single editing environment such as Oracle JDeveloper.

–Do not edit the bpel.xml file, BPEL files, and WSDL files while changing the
design of the process. If you want to edit a file:
1. Ensure that the BPEL files are not being edited in Oracle JDeveloper. If they are being edited (that is, a tab for that file is visible), close it and save changes as needed.
2. Edit the required file and save the changes

–Oracle BPEL Process Manager does not support SOAP-encoded arrays.(soapenc:arrayType).
Use one of the following workarounds:
         * Apache Axis supports document-literal style services. This means you can change the service to not use soapenc:arrayType.
         * A wrapper can be placed around the service (also using Apache Axis) so that the BPEL process talks to the document literal wrapper service, which in turn calls the underlying service with soapenc:arrayType.
         * Call a service with soapenc:arrayType from BPEL, but construct the XML message more manually in the BPEL code. This enables you to avoid changing or wrapping the service. However, each time you want to call that service from BPEL, you must take extra steps

–If you use large binary attachment files in SOAP messages with Oracle Database Lite, your BPEL process may not complete processing, which can cause you to run out of system memory. Oracle Database Lite is largely for testing purposes. To use large binary attachment files in SOAP messages, use an Oracle Database as your dehydration store

–Use TCP tunneling to view SOAP messages exchanged between the BPEL process flow and the Web service (including those containing the
correlation ID). You can see the exact SOAP messages that are sent to, or received from, services with which a BPEL process flow communicates.

–Instead of manually entering an expression, you can press Ctrl and then the space bar in the Expression field. Scroll through the list of values that appears and double-click the value you want. Edit the value as necessary. As you enter information, a trailing slash can appear. This means you are being prompted for additional information. Either enter additional information, or press the Esc key and delete the trailing slash to complete the input of information.

–Do not copy and paste the expression syntax shown in this document into Oracle JDeveloper. This is because the single and double quotation marks are sometimes not compatible with Oracle JDeveloper. Instead, use the Expression Builder window or press Ctrl and then the space bar to use the XPath Building  Assistant.
–When you deploy a process with the same name and version, you are prompted to overwrite the currently-deployed BPEL process or deploy to a new version number. The best practice is to always deploy to a new version (as described in this tutorial). Redeploying a process with the same version can have consequences, such as instances being marked as stale.


I recommend reading the following article about Managing complexities within a BPEL Environment. It includes some of the best practices one can follow to ensure availability of BPEL Infrastructure.

Hope it helps.

Posted in jdeveloper, oracle | 1 Comment »

Some J2EE Best Practices

Posted by Vivek on January 12, 2009


–Use the MVC, or Model 2, architecture pattern to isolate and modularize screen logic, control logic, and business logic. A generic MVC implementation is a key component of the reference architecture as it provides a flexible and reusable foundation for rapid Web application development.

–A large session size can quickly degrade the scalability and performance of an application. It is recommended that the size of the session be kept fairly small. How small is small enough? Well, remember that the session size multiplied by a number of users gives an amount of memory that will be consumed on the Web tier. Taking into consideration that this amount is only a portion of the memory needed to run the application, you can get a rough idea of the number of concurrent users that will be supported by a single instance of a JSP container. Multiply this number by the number of JSP container instances in your production cluster, and this gives you a rough limit on the total number of concurrent users your application can support.

–The delete operation of a business object should also encapsulate the deletion of any aggregated objects in order to ensure data integrity.

–The create operation of a business object should also encapsulate the creation of any required aggregated objects such as a Customer and the corresponding Address. Other aggregated objects are created later in the parent lifecycle by corresponding business methods, such as the aggregated Transaction object that is created by the deposit method on an Account object.

–Do not use Entity Bean finder methods to iterate through a result set of business objects unless you can enforce either a read-only caching strategy or an aggressive-loading approach by the container. For a result set of n objects using lazy loading, this can actually cause (n + 1) database interactions. Use a JDBC wrapper component to run the database query and either hold the result set for iteration or return a set of value objects. This limits the operation to one database interaction.

–Perform some amount of load testing early on in your projects to determine if Entity Beans provide an acceptable level of performance in your application environment. As a general rule, you may want to consider using Java business objects instead of Entity Beans for extremely high throughput application components. If performance is acceptable, use Entity Beans to take advantage of a standard component model that provides services such as object persistence and transaction concurrency. Also, use Entity Beans if you want to distribute business objects directly to remote clients. When using either implementation model, consider planning for a migration path between the two. Application requirements or transaction volumes may change. Robust EJB 2.0 container implementations will likely provide a much increased boost from earlier versions; however, test in your environment before making a decision to commit to the Entity Bean model.

–For a lightweight optimistic locking solution, use an integer property with a standardized name on business objects as an optimistic lock column to handle transaction concurrency. The data access objects can generically increment the property’s value and include it in the WHERE clause on UPDATE and DELETE statements. If no rows are found from the SQL statement, an Optimistic Lock exception is thrown. Many J2EE containers and object-relational mapping vendors provide support to make implementing optimistic locking quite easy by allowing the developer to designate an optimistic locking column.

–It is a good practice always to use the getter and setter methods of a given property, even within other methods in that business object. This is the strictest form of encapsulation, in which only the getter and setter methods actually refer to the member variable. The member variables are declared as private to help enforce this concept, although use within the class itself requires discipline by the programmer. This technique can be beneficial in many ways. One example of when this comes in handy is the case in which a property does not have an assigned value. If you referred directly to the member variable, your code would get a NullPointerException in this case. However, use of the getter method can protect you from this condition by checking for this and initializing the value. This logic can then be implemented and encapsulated in one place, and other methods do not need to worry about this condition. This concept becomes even more powerful when the concept of lazy instantiation is used in getter methods for aggregated objects.

–Use of a standard interface for business objects is a good technique that can ensure consistency across business objects. In addition to making code more maintainable, this standard interface enables you to automate a number of business object functions and services because you can implement them generically, referring only to the Java BusinessObject interface.

–Use an error utility class to consistently and effectively manage business errors in your application

–Use exceptions whenever processing should halt immediately in a given method. Business errors should then be used wherever processing may continue in the case of an error occurring

–Map system-level exceptions to defined business errors that have more meaningful messages that can be presented to the users.

–Isolate the JDBC logic to execute a SQL statement in a common utility class. This prevents every application developer from having to write this common logic and ensures that all resources are closed properly.

–Whether you are using Entity Beans or regular Java business objects, use a factory method (Erich Gamma et al. 1995) abstraction to create and discover instances of business objects. This simplifies the client code and provides a hook for potential future optimizations such as caching EJB Home interfaces. You can create a BusinessObjectFactory utility class to do this. In the case of EJBs, the BusinessObjectFactory can use the EJB Home interface to look up the Entity Bean. In the case of Java business objects, you can instantiate and populate the proper business object within the BusinessObjectFactory.

–Managing a list of objects for data retrieval or for selective updates is a common operation in business applications. Consider the use of a utility class that consistently and effectively manages collections of objects for you. If Entity Beans are used as the business object implementation, you can also use the collection utility to get a list of value objects and have it instantiate corresponding Entity Beans for any transactional updates.

–Always use business objects for transactional updates to ensure data integrity and avoid redundant business logic validation code. Straight database queries can be used for read-only operations if they are more effective at traversing large table structures. However, this should be done only if you can mitigate the risk of having database names permeate throughout the application code.

–Use the Template Method pattern to implement common behaviors in the business object base class. A primary example of this is the save method, which can call a hook method to perform data validation, specific object validation, and any presave logic implemented in the subclass.

–Use a metadata format that allows your design models to be the original source of the metadata. Either build your metadata parser to read the XMI format or use a conversion utility to create your own XML format from XMI, which is generated by development tools from the design models.

–Cache frequently used data that is fairly static to speed application performance. Use a consistent, extensible cache mechanism that can be implemented either as a Stateless Session Bean or as a Java singleton class. If the cached data can be updated and the application needs the latest data, consider the use of a JMS solution for notifying caches across a cluster to refresh their data

–Implement service-based components as stateless Session Beans to take advantage of Enterprise Java services such as distribution and transaction management while maximizing scalability and performance

–Put the actual workflow and transaction logic of the service in a Java class. This implementation of the service can then be wrapped by the Session Bean to engage the container-managed services of transaction management, distribution, and so on. This allows services to be reused within other services more efficiently because you have the option of avoiding another EJB method invocation. Optionally, you can use a local interface of the Session Bean, which is slightly less efficient but avoids the RMI and serialization overhead.

–Service components with specific interfaces for different functions work well in many software architectures. Use a standard interface for service-based components in order to enable highly automated front-end components. Choose the generic data structure that best fits your needs for this interface. XML data is the most flexible choice for automated components. However, it performs the worst, especially for large amounts of data. For many cases, a collection of value objects that implement a standard value object interface works well. For simpler architectures that do not involve many hierarchies or collections of objects, an argument list containing name and value pairs can also work quite well.

–Consider the use of a standard interface for service components. This approach enables the reference architecture to automate the invocation of services to a large extent. Services can be generically invoked through their interface, and standard data structures allow for the automated creation of input data. A standard service data structure can be used to store arguments and object data as input as well as the corresponding output data and error information from the service.

–Wrap service components with a stateless Session Bean to manage the transaction and distribute the service. Use a common base class to standardize the service error handling and integration with EJB transaction management. Command pattern logic can be used to easily invoke services implemented as regular Java objects while subclasses using the Template Method pattern can be used in order to have specific EJB deployments of a service.

–If you are going to use straight database queries in your application for performance reasons, mitigate the development risk by externalizing the SQL from the application, isolating the JDBC code in a reusable utility to ensure that resources are properly managed, and mapping the database column names to properties as soon as possible to ease code maintenance.

–Build and use generic, reusable services whenever appropriate to realize the benefits of automation, rapid application development, and increased code quality and maintainability.

–Use a generic MVC, or Model 2, implementation as the foundation for the User Interaction Architecture. The Jakarta Struts project provides an excellent, readily available implementation that you can use for this purpose. This approach automates much of the front-end processing while providing a flexible and extensible foundation to meet all types of application requirements. This also adheres to a key design principle that permeates the reference architecture. This principle is to make the normal case as simple as possible through automation and configuration but give the application the ability to override automated, configurable elements when necessary for complex cases.

–Abstract the HTTP request as a user event to isolate the specific protocol being used from as much of the front-end logic as possible. The user event can then be used to drive the other key abstractions in the controller architecture. These include the action, the service, and the next Web page. By abstracting these key elements of user interaction, a good portion of the front-end processing can be automated and defined through metadata.

–Abstract physical URLs out of the application into metadata in order to enable automation, avoid broken links, and have more maintainable pages.

–Keep the session size fairly small, especially for applications that need to scale to large numbers of users.

–Minimize the amount of actual Java code in a JSP. Large amounts of Java code interspersed with HTML in a JSP can quickly become unreadable and unmanageable. Instead, use custom tags wherever possible to encapsulate presentation logic and integrate with the controller architecture. You can also move logic out to action classes that perform setup work for the page or JavaBeans that are referenced by the page. If you do have scriptlets within the JSP, try to use a few large scriptlets as opposed to interspersing Java code throughout the entire HTML content

–Use a JSP template mechanism to apply a common look and feel to your application Web pages. This approach makes it easy to globally change common aspects of pages and reduces the amount of duplicated code

–Use the Struts template tag library or an analogous mechanism to simplify the development and maintenance of the common aspects of application Web pages. A standard naming scheme can be used to distinguish between JSP components that implement template instances and page content.

–Use the same Template Method pattern within form beans to implement a validate template. This mechanism can reuse much of the property validation and handling logic implemented for use with the business objects. This prevents a duplication of code and effort.

–Consider the use of asynchronous processing to alleviate performance concerns in applications with semi-real-time updates, multiple external applications that can be invoked in parallel, or work that can be partitioned into segments. Use Message-Driven Beans and JMS to implement parallel processing in a J2EE container. Asynchronous processing can also be used to increase the perceived performance of an application.

–Make sure that your software components have easy to use APIs and are well documented. A little JavaDoc can go a long way toward helping someone understand an existing component and feel comfortable reusing it.

–For large, strategically important development projects, use a combination of industry and organizational reuse along with the creativity and innovation of the development team. Each of these sources brings unique value to the table. An approach that combines these aspects will help to alleviate the “not-invented-here” syndrome while at the same time providing a jumpstart to the development effort.

–Add refactoring as an explicit task in iterative software development. This helps not only to increase the overall quality of the software, but it often leads to more robust code that can be harvested into reusable assets.

–Choose a reference architecture and view it as a “reuse” architecture. Use it consistently throughout J2EE development projects. Incorporate standard interaction points for components with known interfaces. Use extensible, configurable components, such as the Jakarta Struts project, as a foundation. Take advantage of standard J2EE implementation models such as JSP custom tags and Session Bean EJB components.

Make sure you are abiding by all the design patterns also. Here are those:

Basic Patterns:
        Abstract Parent Class
        Private Methods
        Accessor Methods
        Constant Data Manager
         Immutable Object
Creational Patterns
        Factory Method
        Abstract Factory

Collectional Patterns

Structural Patterns
       Chain of Responsibility
       Virtual Proxy
       Counting Proxy
       Aggregate Enforcer
       Explicit Object Release
       Object Cache

Behavioral Patterns
       Null Object
       Template Method
       Object Authenticator
       Common Attribute Registry

Concurrency Patterns
       Critical Section
       Consistent Lock Order
       Guarded Suspension
       Read-Write Lock

Posted in Java/J2EE | Tagged: , , , | Comments Off on Some J2EE Best Practices