Tuesday, 19 January 2010

Service Enabling Existing Assets


Transforming existing application logic or data into callable web services is called as service enabling. This services can be  invoked in other  business processes or new composite applications.  Web Services enable systems to integrate loosely and gain access to needed information and business logic. Assets that can be service enabled will exist in various forms like data, application logic, business logic, or services like notification, messaging engines, security, logging, auditing etc.

Existing legacy systems form the major bottlenecks on road to SOA  transformation, typical problems include 

  • Rigid point to point integration
  • Screen based transaction systems – older transaction systems are screen oriented and business logic is embedded in screens like Green Screens, VB or Java Fat Client
  • Data Complexity - Data that requires complex extraction, cleansing and enrichment. E.g. Cobol Copybooks
  • Data Integrity - Database operations may need re-engineering to maintain overall business process and data integrity

While its complex to re-engineer legacy systems new age middleware and relational databases are best candidates for service enabling. Components that are modular  with  well designed interfaces and data model can be exposed as web services quickly using bottom-up approach

  • Well defined business components like EJB or COM
  • Relational Databases -   The service  to execute typically requires only one
    data set (or call pattern), and new transactions do not need to be created in the
    environment to create a complete solution and ensure referential
  • Business Functions – Well defined business classes or Pojo’s

Approach to Service Enabling existing assets

Data Integration Layer - Building a standard Data model and a strong Data Integration Layer will allow to decouple the  service consumers from legacy systems.   This means regardless of how and where data is stored within the organization one must abide by the standard data model to perform their business functions. Such a layer will bring in flexibility to change and leverage existing data assets. It will be easy to apply compensating transactions and maintain data integrity.


Utility Services – Non business centric logic can be packaged into separate services, this can include services to send Emails and SMS notifications,  Security services to authenticate and manage user accounts, services to audit and log transactions etc.

Service Enabling Existing AssetsSocialTwist Tell-a-Friend

Sunday, 20 December 2009

JAX-WS and .NET Security using NTLM Authentication


The problem with most of the Java and .NET integration via web services is overcoming the authentication issues. Most of the .NET based services like SharePoint and CRM authenticate there web service clients using windows propriety NTLM authentication schema

Java HTTP protocol handler supports HTTP Basic, HTTP Digest and NTLM. In most Microsoft product implementations the ISS services are configured to use integrated windows authentication which is NTLM

On Microsoft Windows platforms, NTLM authentication attempts to acquire the user credentials from the system, say if the Java process is running under username “wstest” the same credentials are passed on to the server.  If these credentials are not accepted by the server then the user's authenticator object will be called.

The client can initialize and set authenticator object prior to invoking an service, check out the below sample

class MyAuthenticator extends Authenticator {

String user;

String password;

public MyAuthenticator(String user, String password)


           this.user = user;

           this.password = password;


public PasswordAuthentication getPasswordAuthentication () {           

return new PasswordAuthentication (user, password.toCharArray());        



then add the authenticator before the web service invocation:

MyAuthenticator auth = new MyAuthenticator("testdomain\\wstest", "luckyme");

NTLM Authentication is supported since JRE1.4, the JRE 1.4 supports NTLM only on Windows and the SUN 1.5_08 and higher support NTLM V2 on all platforms, though on Windows they use the current user's credentials by default.

JAX-WS and .NET Security using NTLM AuthenticationSocialTwist Tell-a-Friend

Sunday, 3 May 2009

Practical Approach for Service Versioning

Versioning refers to the release of a new version of Services. Depending on the type of release, the new version may include new URLs, WSDLs, end-points, and a new namespace.

A new version is required when:

  • new features released
  • changes are made to the components - services, operations, parameters,
  • when bug fixes are made.

Though versioning policy vary from each enterprise  the common versioning scheme is: Version major.minor.patch. E.g. Version 1.0.0.

  • A major version is released for backward-incompatible changes. These changes would have the effect of breaking client implementations that have been compiled using an earlier version of the web services.
  • A minor version is released for backward-compatible API changes.
  • A patch version is released for all other backward-compatible changes.
Service Versioning and Backward Compatibility

Backward compatible changes are released with minor versions or patch versions. Backward incompatible changes are released with major versions.

Service Definition

Backward Compatible

Backward Incompatible

SOAP Header Add an optional SOAP header Change or remove an optional SOAP header. Add, change, or remove a required SOAP header.
SOAP Attachment Add an optional SOAP Attachment. Change or remove an optional SOAP Attachment. Add, change, or remove a required SOAP Attachment.
Service Add a new service Remove an existing service.
Operation Add a new operation to the existing service Change or remove an existing operation.
Parameter   Add a new parameter; change or remove an existing parameter.
Response   Change an existing response.
Element   Add a new element, change or remove existing element. Change an element’s restrictions required or optional etc.
Representing Service versions in Namespaces

Web Services can use the following pattern for representing version in WSDL Namespace


Version: vMajor (vN).  Each time a  major version of  web service is  released it will not be backward compatible, so namespace should be changed accordingly.  Once an earlier version of the WSDL has been replaced by an updated version, the older version should be supported for few months after the launch of the newer version. This will give developers time to migrate to the most recent version.

  • A major version will require new URLs, WSDLs, end-points, and a new namespace.
  • A minor version will require new WSDLs only.
  • A patch version does not require any update.


Namespace URL

Version 1.0.0
Major version release
Version 1.0.1
Patch release
Version 1.1.0
Minor release, backward compatible API changes

Version 1.1.1
Patch release, no changes
Version 1.2.0
Minor release, Backward compatible API changes
Version 2.0.0
Major version release , backward incompatible changes
Version 2.0.1
Patch release, no changes

Service Deprecation

Some of the services might be used thru web service endpoints or thru direct API calls.Any service that's not going to be supported in features releases should be marked as deprecated at API level. The term "deprecated" is a warning to the developer that an API feature will probably be removed from a later version. The text in the deprecation note should explain which API feature replaces the deprecated one, if any. Deprecated can apply to a service, data object, request or field

Practical Approach for Service VersioningSocialTwist Tell-a-Friend