WSO2 and Zend jointly present a webinar titling "PHP Web Services: Why You Should Care" on 26th of May, 2010. The webinar will mainly focus on the following aspects,
• Understand Web services development best practices
• Discuss Web service myths and pitfalls
• Learn about prominent PHP Web services extensions
• Watch a demo of building Web Services with both the Zend Framework and WSO2 Web Services Framework for PHP.
You can find more information about the webinar and the link to registration here, http://wso2.org/library/webinars/2010/05/webinar-php-web-services-you-should-care.
Wednesday, May 19, 2010
Wednesday, May 05, 2010
Metering Java Reader and Writer Objects
Last few days I was working on measuring the bandwidth consumed by different java objects passed to our remote interfaces. It was simple task to do it with 'String' objects, byte arrays as we can directly get the sizes of them using String.length and byte[].size() methods.
But there were objects of type Reader and Writer, which is supposed to transfer big chunk of data. There also we could load all the data to memory and measure the sizes.
But that will consume lot of memory (even possible to exceed available heap size). So it is wrong to use the above method to measure the size of reader or writer.
Anyway there is an easy solution for the problem. We can use the design of Reader API itself to measure it size. The Reader interface has a method that read the data by small chunks. We just need to intercept that call and measure the size of each small chunk and add them all. For that we need to implement the Reader interface in to a custom class (say 'MonitoredReader'). Here is how it is implemented.
So our code to measure the size will simple reduce to the following piece of code.
Similarly we can use this method to get the data size of the writer. (amount of data written to the writer).
Here is how it is used in measuring the writer size.
Anyway like every good methods, there are drawbacks of using these methods to measure the data size on Reader and Writer objects.
If we take measuring the bandwidth consumed by a reader in a remote interface, this gives a slightly low value because this particular code only provide the size of the data read by the end user application and not by the network hardware layers. But actually these low layers read more data and keep it in a buffer which is not measured here. But if we assume that most of the time the end user application read all the data from the reader (and very rarely read portion of data and give up), this give nearly accurate value.
The other drawback could be the performance degradation by wrapping the reader/writer with our custom implementation. But mostly reader and writers are used in IO bound operations (like to read through network or files), so going through an another layer does really little effect to the overall performance. And after all the 'Observer effect theory' says we can't measure anything without causing any effect to the actual cause...
But there were objects of type Reader and Writer, which is supposed to transfer big chunk of data. There also we could load all the data to memory and measure the sizes.
// measuring reader size - memory inefficient method
// read all data to buffer and measure the length
StringReader stringReader = new StringReader(reader);
int size = stringReader.toString().length;
doRealWork(stringReader);
But that will consume lot of memory (even possible to exceed available heap size). So it is wrong to use the above method to measure the size of reader or writer.
Anyway there is an easy solution for the problem. We can use the design of Reader API itself to measure it size. The Reader interface has a method that read the data by small chunks. We just need to intercept that call and measure the size of each small chunk and add them all. For that we need to implement the Reader interface in to a custom class (say 'MonitoredReader'). Here is how it is implemented.
import java.io.IOException;
import java.io.Reader;
/**
* The class to intercept the read method and calculate
* the number of reads
*/
public class MonitoredReader extends Reader {
Reader reader;
int totalReadSize;
/**
* constructor that wraps the original reader object
*/
public MonitoredReader(Reader reader) {
this.reader = reader;
totalReadSize = 0;
}
/**
* The method to call by the user to read the data. We will just calculate the amount
* of data read here.
*
* @param cBuf destination buffer
* @param off offset at which to start storing characters
* @param len maximum number of characters to read
*
* @return the number of characters read, or -1 if the end of the stream has been reached
* @throws IOException if an I/O error occurs
*/
public int read(char cbuf[], int off, int len) throws IOException {
int read = reader.read(cbuf, off, len);
totalReadSize += read;
return read;
}
/**
* Method to call after finishing reading the data. We will just pass the call to the
* original reader
*/
public void close() throws IOException {
reader.close();
}
/**
* Custom method that will return the total size of read data
*
* @return the size of the data read
*/
public int getTotalReadSize() {
return totalReadSize;
}
}
So our code to measure the size will simple reduce to the following piece of code.
// measuring reader size - memory efficient method
// just wrap the original reader with our custom reader
MonitoredReader monitoredReader = new MonitoredReader(reader);
// pass our custom reader to the real work
doRealWork(monitoredReader);
// get the size read in the real work
int size = monitoredReader.getTotalReadSize();
Similarly we can use this method to get the data size of the writer. (amount of data written to the writer).
import java.io.IOException;
import java.io.Writer;
/**
* The class to intercept the write method and calculate
* the number of writes
*/
public class MonitoredWriter extends Writer {
Writer writer;
int totalWrittenSize;
/**
* constructor that wraps the original writer object
*/
public MonitoredWriter(Writer writer) {
this.writer = writer;
totalWrittenSize = 0;
}
/**
* The method to call by the user to write the data. We will just calculate the amount
* of data written here.
*
* @param cBuf Array of characters
* @param off Offset from which to start writing characters
* @param len Number of characters to write
*
* @throws java.io.IOException If an I/O error occurs
*/
public void write(char cbuf[], int off, int len) throws IOException {
totalWrittenSize += (len - off);
writer.write(cbuf, off, len);
}
/**
* Method to call after finishing writing the data. We will just pass the call to the
* original writer
*/
public void close() throws IOException {
writer.close();
}
/**
* flush already written data. Here also we just pass the call to the original writer
*/
public void flush() throws IOException {
writer.flush();
}
/**
* Custom method that will return the total size of written data
*
* @return the size of the data written
*/
public int getTotalWrittenSize() {
return totalWrittenSize;
}
}
Here is how it is used in measuring the writer size.
// measuring writer size - memory efficient method
// just wrap the original writer with our custom writer
MonitoredWriter monitoredWriter = new MonitoredWriter(writer);
// pass our custom wrter to the real work
doRealWork(monitoredWriter);
// get the size written in the real work
int size = monitoredWriter.getTotalWrittenSize();
Anyway like every good methods, there are drawbacks of using these methods to measure the data size on Reader and Writer objects.
If we take measuring the bandwidth consumed by a reader in a remote interface, this gives a slightly low value because this particular code only provide the size of the data read by the end user application and not by the network hardware layers. But actually these low layers read more data and keep it in a buffer which is not measured here. But if we assume that most of the time the end user application read all the data from the reader (and very rarely read portion of data and give up), this give nearly accurate value.
The other drawback could be the performance degradation by wrapping the reader/writer with our custom implementation. But mostly reader and writers are used in IO bound operations (like to read through network or files), so going through an another layer does really little effect to the overall performance. And after all the 'Observer effect theory' says we can't measure anything without causing any effect to the actual cause...
Monday, May 03, 2010
WSO2 Governance Registry, WSO2 Identity Server, WSO2 ESB, WSO2 Web Service Application Server Released
WSO2 has released new versions of their SOA platform products including WSO2 Governance Registry, WSO2 Identity Server, WSO2 ESB, WSO2 Web Service Application Server. This is a major version upgrade of these products introducing many features.
ESB:
Governance Registry
Web Service Application Server (WSO2 WSAS):
Identity Server:
ESB:
- Priority based mediation through priority executors
- WS-Discovery support and dynamic endpoint discovery
- Message Relay for efficient pass through of messages
- Component manager to install and uninstall features (provisioning support)
- Common Internet File System (CIFS) support through the VFS transport
- File locking functionality in the VFS transport to support concurrent polling
- Smooks mediator for efficient message transformation
- Enrich mediator for smart message manipulation
- OAuth mediator for 2-legged OAuth support
- Default endpoint UI
- Hot deploy and hot update configuration elements (sequences, endpoints, proxy services etc)
- Transport level statistics collection and monitoring
- POX security support
- Dependency detection and alerting for mediation configuration elements
- Mediation statistics API and custom mediation statistics consumers
- Multiple certificate/identity support in the NHTTP transport sender
- Improved logging capabilities for the NHTTP transport
- Templates based proxy service development in the UI
- Dashboard to monitor server environment and runtime
- Easy creation and management capabilities for dynamic sequences and endpoints
- Pagination to service management, endpoint management and sequence management UIs
- Obtaining resources like WSDL's through web proxy servers
Governance Registry
- Gadgets for impact analysis on services and registry resources
- WSDL custom view
- Dynamic Handler configuration
- Handler simulator
- Tree-based Resource view
- API to govern SOA artifacts
- Complete Web Services API for Registry
- Improved options for Service discovery
- WS-Discovery support
- Scripting support for lifecycle management
- Improved P2 based provisioning and feature management support
- Support for adding remote mounts
- Platform, and Group/Cluster based deployment model
- Support for multiple server instances
- E-mail verification for subscriptions
- Support for deleting tags and comments
- Support for PostgreSQL and DB2 DBMS
- Paged activity and resource search
- Hierarchical permission model with granular and extensible permissions
- Ability to upload metadata (in addition to importing)
- Governance Archive for uploading WSDLs and Schemas with imports
- Ability to update resource content by uploading
- Rich text editor for editing text resources
- XML editor for editing handler, lifecycle and service UI configurations
Web Service Application Server (WSO2 WSAS):
- Component Manager - The UI tool to install/uninstall Carbon featrues.
- Various bug fixes & enhancements including architectural improvements to Apache Axis2, Apache Rampart, Apache Sandesha2 , WSO2 Carbon & other projects.
- Equinox P2 based provisioning support - extend your WSAS instance by installin new P2 features. See P2 based provisioning in WSO2 Carbon
- Hierarchical service support for Axis2 services, JAX-WS services, Spring services & Jar services
- Report generation for deployed services
Identity Server:
- SAML 2.0 based Single Sign-on support
- OAuth Support
- Support for bulk-user import
- Various bug fixes and enhancements including architectural improvements to Apache Axis2, Apache Rampart, Apache Sandesha2 , WSO2 Carbon and other projects.
Labels:
carbon,
esb,
governance registry,
identity,
SOA,
web service application server,
wsas,
WSO2
Subscribe to:
Posts (Atom)