SOA / Web Services / Java

A Technology Blog

Archive for May, 2012

Determining Complexity of Service in SOA

Posted by Vivek on May 13, 2012

Every unit of logic in a SOA is treated as a service. Before embarking on the SOA journey, it is important to go through a service identification process. Once services are identified, they are categorized as per the level of complexity. Determining the complexity is a key step in providing estimation. The following guidelines can be used to gauge the complexity of a service:

Simple Service:

· Exposed using a standard based interface and no adapters are required.
· There is minimal (simple) or no data validation required.
· There is minimal (simple) or no data transformation required.
· Does not require any security implementation. (Mostly public services)
· Simple logging framework. Does not require a separate error handling mechanism.
· Can be easily searched in UDDI. Taxonomies clearly defined. Simple end-point look.
· Does not require WS-* Standards like WS-RM, WS-A etc.
· Does not require any guaranteed delivery messaging mechanism to be in place
· Mostly utility services with simple read/ update operations.

Medium Service:

· Exposed using a standard based interface.
· There is simple/ medium data validation required.
· There is simple/ medium data transformation required.
· Simple logging framework. Requires a separate simple error handling mechanism.
· Require simple security implementation. Eg WS-security for authentication/ authorization, tool based encryption and decryption, SSL etc
· Can be easily searched in UDDI. Taxonomies clearly defined. Simple end-point look.
· Can include simple WS-* standards such as WS-Addressing, WS-reliable messaging.
· Requires some guaranteed delivery messaging mechanism to be in place
· Services returning/ adding medium to large amount of information and interacting with 1 application or system.

Complex Service:

· Exposed using a standard based interface.
· There is complex data validation required. (eg, data & timezone validation etc)
· There is complex data transformation required. (eg. One message standard to another)
· Complex logging framework. Implementation of Correlation sets. Requires a separate complex error handling mechanism with retry/ reprocessing logic and fault notification.
· Require medium to complex security implementation. Eg Digital Signature, encryption & decryption, SAML etc
· Multiple versions exist in UDDI. Standards such as WS-Policy, WS-trust need to be enforced.
· Can include WS-* standards such as WS-Coordination etc.
· Requires guaranteed delivery messaging mechanism to be in place
· Services adding/ updating and returning large and complex information and interacting with multiple systems.

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

Why IBM is not a best choice for SOA?

Posted by Vivek on May 5, 2012

SOA offers great benefits by simplifying the architecture by virtue of its priniciples and helps in making an enterprise more agile. But implementing SOA is not easy and it takes a well-defined strategy. It is a long-term investment and if the first step taken is in wrong direction, then integration costs and complexity can increase exponentially.

For example, consider an organization which is in Retail domain and wants to integrate its 2 channels – Store and E-Commerce. This can be done by choosing any of ESB available in the market which supports the protocols, message formats etc of the requesting and providing applications. However, integration might not stop here. There can be another legacy system which the organization has acquired and wants to integrate. Also, management wants to increase agility by defining worflows and dynamically changing rules according to business needs in a faster changing market. It needs to be understood that SOA is a journey and it is business to decide which mode of transport they take to embark on this journey.

IBM is one of the leaders in middlware but does its products make a better choice when implenting SOA?

1. IBM has a wide array of products. Deciding which product suits which requirement is a not an easy task. If there is an ESB requirement then IBM offers the following products: Websphere ESB, Websphere Message Broker and Datapower. Not all products offer the same benefits and each one has its own strength and pitfalls.
2. These ESBs alone may not suffice. If complex transformations are required, then you might also need a Websphere Transformation Extender. If a legacy application needs to be integrated and a third-party or customized adapter is required, then providing a seamless integration will be a challenge.
3. As SOA evolves and business grows, it almost becomes a necessity to have a BPM tool to facilitate agility. IBM provides Websphere Process Server as a BPM tool for process based integration.
4. Websphere Process Server is mounted on top of Websphere Application Server. It also comes with a Business Rule engine to enrich process workflows. However, there is another powerful product, websphere ILOG, which also offers business rule management.
5. ILog JRules is installed separately and has its own development and runtime environments. While you already have a Rational Application Developer, an eclipse based IDE, you will be using another IDE for rule authoring. Not only this, you are also using an IDE for designing and developing ESB flows. For example, if you are using websphere message broker, then you will be using a message broker toolkit as IDE.

Posted in IBM Websphere Message Broker, IBM Websphere MQ, integration | Tagged: , | Leave a Comment »