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
  integrity.
• 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.

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");
Authenticator.setDefault(auth);

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.

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

http://<hosthame>/<contextpath>/<servicename>/vN

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.

Version	Namespace URL
Version 1.0.0 Major version release	http://soa.mycompany.com/services/payment/v1
Version 1.0.1 Patch release	http://soa.mycompany.com/services/payment/v1
Version 1.1.0 Minor release, backward compatible API changes	http://soa.mycompany.com/services/payment/v1
Version 1.1.1 Patch release, no changes	http://soa.mycompany.com/services/payment/v1
Version 1.2.0 Minor release, Backward compatible API changes	http://soa.mycompany.com/services/payment/v1
Version 2.0.0 Major version release , backward incompatible changes	http://soa.mycompany.com/services/payment/v2
Version 2.0.1 Patch release, no changes	http://soa.mycompany.com/services/payment/v2

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

Examples

• Versioning and Extending a Service from WSDL Spec