Arvind Jain

Subscribe to Arvind Jain feed
My observations in IT, Business Services, Cloud, SaaS, Security, Product Management, Compliance and SOA.Arvind Jainhttp://www.blogger.com/profile/18329742389935861777noreply@blogger.comBlogger27125
Updated: 19 hours 44 min ago

SOA on SOA !! - Bring the discipline of SOA to service development and creation in your organization.

Fri, 2008-03-07 18:22

SOA on SOA!!

It was difficult to put the most appropriate words to my thoughts but what I am trying to bring out is that SOA implementation should not burden the service providers and consumers to go through the burden of learning all the latest standards, tools & technologies.

They should just worry about their business logic and there should be a framework which transparently takes care of making that business logic a service as in SOA world while adhering to their company's enterprise policies, processes and standards.

How to enable this? Enterprise architects should closely watch two upcoming standards - SCA & JBI.

JBI is JSR 208 and called as Java Business Integration. SCA is Service component architecture.

JBI is used by system integrators during physical deployment (customers and end users do not see this). It helps in management & interoperability of your SOA infrastructure.

SCA has a design and composition perspective. It is used by developers to annotate or put notes in their code to describe service and their dependencies.

The aim is to create a virtual container for hosting services. This way services can be plugged into ESB or into an existing Policy Manager. It will be independent of language and will help as a framework for exposing business logic as service.

The other significant benefits I see are
- Consistent deployment & management
- Location Transperancy (Virtualization)
- Policy Enforcement
- Consistent Security Model
- SOA does not means every developer needs to know about WSDL or WS-* or other standards. They need to know the core business logic.
- It might possibly help in transaction coordination.

So let us try to use our own methodology SOA to help in implementation & adoption of SOA.

Arvind

How to take Build vs Buy decision in case of Software Products?

Mon, 2008-02-25 13:09
In the world of software development once in a while everyone reaches that crossroad where he needs to decide - Should we build that software or buy it? Build vs Buy !! Deal or No Deal !!

Here are suggestions that will help you. When making a Buy vs Build decision do the following:
  • Consider only the costs that are affected by your decision (example you may or may not decide to buy additionaly 24X7 support)
  • Include all Opportunity Costs (are you going to miss on some other core oppurtunity / project in your own industry)
  • Ignore Sunk Costs, these are costs that have already been incurred (example can be hardware cost as either version of bought or in house build software will require similar hardware)Calculate total costs of each option. Total cost = fixed (avoidable) costs + variable (avoidable) costs
  • Considering "Soft" or "Intangible" cost/benefits, for example future use of product or learning, team reputation or burden (in terms or learning or development), derivative products.

Other Important Hints/Viewpoints
  • A very important consideration is to look at the Marginal cost i.e. the cost for deploying an additional host (cpu) with the same software.
  • For coming up with oppurtunity cost - look at the nature of technology/product and its maturity level - analysis in the Short Run and in the Long Run
  • Look at the service/product provider and its industry - will you be price taker or price chooser? How much can you negotiate? What are hidden benefits/costs of partnership?
  • Evaluate options using the net present value (NPV) & internal rate of return (IRR) approach
  • A little known fact is about the Basic Accounting ... Is it favourable for company's accounting? - This is very important as software bought is a depreciable asset for organization while software built will be treated as an ongoing expense without any balance sheet asset created out of it.
Hope you have some food for thought and solid points to make your case in your next board/council meeting.
Arvind

Does the best technology & architecture guarantee a successful SOA or BPM?

Mon, 2008-02-25 00:50
Have you ever wondered that given best technology & architecture ...Are you guarantee a successful SOA or BPM project?

Answer is a simple and a big NO.
There is much more to a successful SOA or BPM implementation & adoption then just choosing the right tools and technology and architecting the finest blueprints. The best and brightest team of IT architects and engineers definitely help to do the toughest of design & implementation projects .... but that is just half the task.
Embracing SOA or BPM or for that matter any new initiative like WEB 2.0 and Collaboration is a major change for the organization. By nature changes are difficult as people see change with a grain of salt and skepticism.

Hence the Architecture Community has an additional and significant responsibility to be the "Change Agents" in the organization. They need to understand basic human nature & group behavior in order to be successful in their SOA or BPM initiative. They need to understand that shift in attitude seldom comes at once. The rate at which different groups, divisions or individuals will adopt these changes will vary by individual, or the type of change or the organizational context.

They need to identify these stages of change and simultaneously work on those while doing their core IT or Business job.
Understand that it is not sufficient for just you to have adopted this change. You have to guide and lead the larger community through the various stages of change, namely
1) Awareness
2) Interest (people develop curiosity)
3) Trail (skepticism is overcome)
4) Adoption
I will further share my experience about managing change during these various stages in some later blog or if there is an interest in the community.

Arvind

Top 10 areas to address before taking Oracle BPEL Process Manager 10.1.3 to a Production Implementation

Mon, 2007-07-16 17:33
Here is a summary of the article I am writing on How to adopt BPEL PM in a Production Environment. This is based on 10.1.3 release of BPEL PM. If you need specific details then please drop me a line.

Top 10 areas to address before taking Oracle BPEL Process Manager 10.1.3 to a Production Implementation
Arvind Jain
5th July 2007

1) Version Management (Design Time)
When we are choosing a Source Safe System or Version Control system for Business Processes the consideration are quite different than choosing a Source Safe System or Version Control system for Java, C++ code components. The average user / designer of Business processes is not CODE savvy, they cannot be expected to manually merge code (*.bpel files or *.wsdl files for example). BPEL PM lacks in Design time version management of Business Processes using the jDeveloper IDE. What is needed is a Process Based Development and Merge environment. We need Visibility into Process Repository. So the requirements are different from that of a Component based repository. Consider using a good BPMN / BPA tool.

2) Version Governance (Run Time)
While BPEL PM can maintain version number for deployed BPEL processes, it is still left to an administrator or a Business Analyst to decide which process version will be active at a given point in time and what will be the naming, versioning standard. Since every deployed BPEL Process is a service, so it becomes critical to apply SOA governance methodology to control various deployed and running BPEL Processes.

3) SOAP over JMS (over SSL)
Most of the big corporation and multinationals have policies which restrict use of HTTP traffic from outside world to inside intranet. Moreover they have policies which require the use of a Messaging Layer or an ESB as a Service Intermediatory for persistence, logging, security and compliance reasons. BPEL PM support for bi directional SSL enabled JMS communication is not out of box. It needs to be tried and tested out within your organization and workarounds needs to be implemented.

4) Authentication & Authorization - Integration with LDAP / Active Directory
SOA governance requires authentication and authorization for service access based on a corporate repository and roles defined within them. This is also critical for BPEL Human Workflow (HWF). Make sure to do a small Pilot / POC for integration with your corporate identity repository before taking BPEL PM to production.
5) Integration with Rules Engine
BPEL should be used for Orchestration only and not for coding programming logic or hard coded rules. Hence it is important to have a separate Rules Engine. Many rules engine available in Market support Java facts and BPEL Engine Being a Java Engine should integrate out of the Box with these. But some rules engine have the limitation that they can take only XML facts, so it is an overhead to go from Java to XML so as to use XML facts and then marshal back to Java. So make sure that you have sorted out Integration with Rules Engine prior to BPEL production implementation.
6) Implementation Architecture
BPEL processes and projects can and will expand to occupy all available resources within your organization. These business processes are pretty visible processes within a company and have strict SLAs to meet. Make sure you have a proven and tested reference architecture for Clustering, High Availability and Disaster recovery. There has to be a provisioning process, deployment process and Process Life cycle governance methodology in place before you can fire up all engines in a production environment.
7) Throughput Consideration
BPEL PM by nature is an interpretation engine and hence there is a performance hit when running long running processes and doing heavy transformations. Plan on doing some stress and load testing on the servers running your Business Processes to get a Ball Park estimate of what is the end to end processing time and how much load can be taken by the BPEL server. Specifically do a capacity planning based on results from these pilot load and stress tests.

8) Design of BPEL Process (Payload Size, BPEL Variables - Pass by Reference or by Value)
Designing a Business Process is more of an art than a science and the same holds for BPEL Business Processes. It is important to understand what will be best practices in your organization in terms of Payload size and length of various Processes and how they are orchestrated. Are you passing across big XML payloads which can be avoided by changing the process and using a technique called as passing by reference? Will that also make your process more efficient and create true Business Services from these processes? Give a consideration to these and spend some white boarding sessions with Business and IT Analysts before creating a BPEL process.
9) Schema Consideration - Canonical Data Model & Minimal Transformations
The most cost and resource intensive step in any Integration or Process Orchestration scenario is Transformations. Especially in an orchestration engine like BPEL PM the XML payload goes through multiple massaging steps. If you can design your process flow in such a way that there is minimal of these steps then it will improve the performance of Business Process end 2 end. Also it is a best practice to have an enterprise wide canonical data model derived from some industry wide standard like OASIS, Rosettanet, ebXML etc
10) Administration - Multiple BPEL Console, Central HWF Server, Customized UI or use existing UI?
BPEL PM is easy to use and makes process orchestration almost a zero coding activity. Also it is pretty easy to learn and hence there is suddenly a bunch of BPEL processes deployed and a bunch of BPEL developers in enterprise once the floodgates are opened.

It is very critical for an enterprise scale deployment to figure out ways to Provision BPEL Server Instances and to give selective access to BPEL Console to relevant developers. BPEL console is a powerful tool and there is not much of a role based security functionality in that except for the concept of domains. Options are to create your own Administration / Console UI using the BPEL Server API’s or to have a BPEL Administrator take care of such requests.
BPEL PM comes with a built in Human Workflow Server (HWF) but in an enterprise you might want to have a centralized HWF server. All these need to be given though to before putting BPEL PM into a production environment.

How to OBFUSCATE passwords and ENCRYPT sensitive fields in BPEL PM?

Wed, 2007-07-11 15:19
Here is a small tip on security while using Oracle BPEL Process Manager.

Many a times you have to supply password information and other sensitive information in your BPEL PM project files (*.bpel, *.xml, *.wsdl). How do you ensure that these are not visible as clear text to others who do not have access to source codes? Here is a quick tip on using the XML tag <encryption="encrypt">.

Where can this be used?

- to obfuscate password info while accessing a partnerlink that refers to a WebService secured by Basic Authentication ... login/password.

Example:

Suppose you have a partnerlink definition defined with LOGIN PASSWORD info as shown below. You want to obfuscate the password i.e. You do not want to see clear text "cco-pass"

(sample)
<partnerLinkBinding name="PartnerProfileService">
<property name="wsdlLocation">PartnerProfileWSRef.wsdl</property>
<property name="basicUsername">cco-userid</property>
<property name="basicPassword">cco-pass</property>
<propertyname="basicHeaders">credentials</property>
</partnerLinkBinding>

Add the property encryption="encrypt" for sensitive fields, this will cause the value to be encrypted at deployment. So the new XML will look like


(sample)
<partnerLinkBinding name="PartnerProfileService">
<property name="wsdlLocation">PartnerProfileWSRef.wsdl</property>
<property name="basicUsername">cco-userid</property>
<property name="basicPassword" encryption="encrypt">cco-pass</property>
<property name="basicHeaders">credentials</property>
</partnerLinkBinding>


Then deploy your process and the password will be encrypted.
Have fun encrypting things !!

Pages