SOA / Web Services / Java

A Technology Blog

Archive for January, 2012

Download MQMON tool

Posted by Vivek on January 21, 2012

1. Download the following file.
2. Change the extension to .zip from .odt format
3. Extract the zip file on your local machine and use the tool. (No installation required)

MQMONTool

Advertisements

Posted in IBM Websphere MQ, Middleware | Tagged: , , | 3 Comments »

Download Free SOA Knowledge Kit

Posted by Vivek on January 8, 2012

PushToTest is offering free SOA knowledge kit that includes comparison of top middleware vendor products. Follow this link:

http://www.pushtotest.com/a-guide-to-the-soa-knowledge-kit

Registration Link – http://www.pushtotest.com/soa

 

 

Posted in integration, Middleware, SOA | Tagged: , | Leave a Comment »

JSON vs XML in REST WS

Posted by Vivek on January 8, 2012

One distinctive feature of REST web service is that it supports message formats other than XML or SOAP.  In a REST based web service, resources are identified by a unique URI and can support formats such as XML, JSON, HTML, CSV etc. However, XML and JSON (JavaScript Object Notation) have gained more visibility and are widely used formats. While XML is still the preferred choice, JSON is not far behind than XML.

1. XML is verbose and causes performance bottlenecks. The primary objective behind adoption of REST is to increase the performance of services and XML does not provide good support here.

2. Those using Java can easily parse JSON as it is well supported by javascript clients. Nowadays, all browsers support javascript and browsers like firefox 4 and IE8 also provide special support for parsing JSON. Afterall, JSON is a subset of javascript. Note that not all browsers support encoding and decoding of JSON.

3. There is support in leading XML editors like XML Spy for JSON. Other editors will soon follow the same. However, this will take some time. JSON schema is not widely accepted and is still evolving.

4. Processing JSON requires less effort and is not memory intensive. Fewer lines of code without any dependency on external JARs reduces overhead.

5. JSON can pose several security problems if the processing program contains insecure scripts. There is no standard security mechanism that can be used. JSON is a preferred approach only when the data and parsers are from a trusted source.

6. A variety of XML processors are available in the market. Also, there are techniques to compress XML or accelerate XML processing. JSON has a limted playing field.

 

Posted in Java/J2EE, Miscellaneous, Web Services | Tagged: , , | 1 Comment »

Checklist for a new interface in integration

Posted by Vivek on January 8, 2012

While integrating several systems, interfaces are created based on the technical requirements. The interface is defined by a set of parameters, which form building blocks of any interface design.

1. Name: This involves name of the requesting application as well as the service provider or name of the systems involved in the conversational process. Ex. ABCProvider_WeatherService
2. Integration Style: This includes information such as Batch or Real-Time.
3. Integration Technology Framework: This includes information such as ETL (eg Datastage, Ab Initio, Informatica), Web Services, EAI, B2B
4. Invocation Style: It includes the way in which the integration application will be invoked. Invocation could be through Database trigger or Change Data Capture, Manual or through sequencer (in case of ETL).
5. Message Exchange Pattern: It includes information about the way in which messages are exchanged such as Request-Reply, Fire and forget, Pub-Sub topology
6. Message Domain: It includes details such as HL7 for Healthcare, ACORD for Insurance etc
7. Message Format: It includes details such as XML, CSV, Pipe delimited messages, SOAP including web service standards such as WS-Addressing, WS-RM, WS-BaseNotification
8. Messaging Style: Messages could be transported using HTTP, SMTP, MQ etc.
9. Service Contract: It can be WSDL for SOAP based web services, WADL for REST
10. Security: It includes non-functional requirements such as Authentication, Authorizarion, Confidentiality, Integrity and Non-Repudiation.
11. Security level: This can be Message level or Transport level.
12. Security Implementation: It can be WS-Security username token for authentication, SSL, Canonicalization algorithm for encryption/ descryption etc.

If these parameters are clearly defined, then it is possible to build the interfaceand use this information as metadata in governing the services in future.

Posted in integration, SOA, Web Services | Tagged: , | 2 Comments »

Identifying services in SOA

Posted by Vivek on January 8, 2012

Perhaps the most critical task before embarking on a SOA journey is to identify and build the right set of services. This exercise requires not only technical knowledge but also functional knowledge as the services might span across business and techical domain of the enterprise. Based on the business and technical requirements, services can be classified into one of the four major categories.

1. Infrastructure or Utility services: Services falling under this category and mostly techical and discrete in nature and provide reusable functionalities and are internal to an enterprise. If there is a need to execute a piece of logic which is difficult to be rewritten and/ or is readily available on the other side of the firewall or business domain or is offered by a third party, then building a wrapper or client or choreographing the service with ESB provide easy access to the information saving a considerable amount of effort and cost. For example- a credit check service can be used by billing, HR or insurance domain within an enterprise. Similarly, authentication or authorization services can be reused across an organization.

2. Application services: These services are designed and developed to address a sepecific set of requirements. They can be composite and encompass the domain or functional logic within. These services are not generally accessed directly by the user. example: a packaging application service that packages and ships order.

3. Business Services: These services are exposed to the consumer and is composed by choreographing one or more application services. Example: An order service that takes an order, sends it for approval, confirms payment mode, processes transaction and triggers shipment.

4. Process Services: These services are used mostly by management and business analyst to make the business more agile. Process services involve orchestration of services and other components and typically take the form of a workflow. Example: A loan processing service which spans across HR, Finance, Insurance departments. Loan interest rate might change from time to time and a rule engine can serve the pupose for management.

Posted in SOA, Web Services | Leave a Comment »