Exception/Fault and Error Handling and Ontology in SOA

In any SOA enable environment (Enterprise as well as Product) Exception/ Fault and Error Handling forms one of the major areas during Architecture & Design and Governance (especially Design and Run time).

Before moving forward let us set some definitions:

1. Exception/Fault: These are the business and system conditions which can cause temporary or permanent disruption of instance of service/s. In most of cases this disruption is temporary and with some efforts (run time only though coded at design time) service instance remains alive and keep on serving the clients.

2. Error: These are the life killing system conditions which not only kills a very particular instance of service but may also affect deployment of service. There will not be any run time recovery. The best one can expect is graceful death.
In any SOA enabled environment, typical service interaction can be depicted as:

In this diagram the service under consideration is MyService which is calling right hand side service and being called by right hand side service in some business orchestration.

For Exception/Fault and Error occurrence perspective, exception/fault or error can occur in MyService, or called service or calling service.
For brevity let us call Exception/Fault and Error just Exception. If separation required in Exception/Fault and Error then Exception/Fault and Error will be mentioned explicitly.

As a good exception handling practice any exception occurring in any service should be handled in that service and should be resolved there. If resolution is not possible only then exception should propagated to calling service.

For Ontology perspective, exception can be divided into two broad categories:

1. System
2. Business

And if we go into details of each exception then an exception object (sic!) should have following attributes:

a. Exception Group: most of the applications like to group exception for the resolution and notification perspective.
b. Exception Type: Exception, Error, Warning
c. Internal Exception Code: Code to be used by service internally for logging and identification
d. External Exception Code: Code to be used by calling service
e. Detailed Description of Exception
f. Reporting time for Exception
g. Possible Corrective Action/s
h. Severity
i. Service ID
j. Instance ID: of Service
k. Business Object Name: In some cases/implementations payload and/or stack trace may not contain business object name.
l. Stack trace
m. Payload

The code for exception can follow following nomenclature

Legal Challenges in cloud computing: Software Architect Perspective

Though Cloud gaining currency across the globe and across the industry. But if one carefully observe, he will find slow adoption of cloud in big enterprises. From a Software Architect perspective one should be aware of the legal challenges while evaluating cloud platforms for a solution.

1. Intellectual Property Rights
a. Is application and data protected under intellectual property rights?
b. If cloud provider gives access to your application, data, log etc to third party then what legal responsibility cloud provider assumes?
2. Trade Secrets
a. How secure are the trade secrets?
b. How far cloud provider can go to protect data, log, etc. in case of court summons and/or quasi legal requests/pressure?
c. How long cloud provider keeps application data and logs even after application is deleted from cloud and/or log deleted from cloud?
3. Privacy
a. What responsibility cloud provider assumes to protect Application Owner’s privacy?
b. What responsibility cloud provider assumes to protect Application users’ privacy?
c. Is there any liability coverage for privacy breach?
d. How behavioral tracking is maintained?
4. Data Centre
a. What legal responsibility does cloud provider assume in case of disaster?
b. What legal responsibility does cloud provider assume in case of hacking?
5. Jurisdiction
a. In case of any legal dispute which law apples – location of application provider, location of end user, location of cloud provider, location of server farm or any other?
b. In case of data breach who will send the notice of data breach – application provider or cloud provider?
c. How trans-border laws will be handled?
d. How do reputational risks covered?
e. How long data will be retained for legal and taxation purpose?
f. What is damage policy (say total dames are capped by amount of fee)?
g. Does the flow of data meet the regulatory requirements of each jurisdiction it flows through?
h. Does the cloud provider provides solutions for de-identifying data for transboarder data flow?
i. Where will the data and processes be stored? Can a commitment be obtained?
j. Are there multiple cloud platforms/parties involved?
k. Can the movement of data be controlled?
l. Should/can the data be encrypted?
6. Service Level Agreement
a. What are the SLA’s for cloud provider?
b. What matrices will be used to measure performance of cloud provider?
c. In case of dishonoring of SLA, what are the penalties and they will be enforced?
7. Licensing
a. Do libraries, components, services, servers, etc used in application creation, deployment, etc have cloud compatible licenses?
b. Do libraries, components, services, servers, etc used in application creation, deployment, etc licenses cover upgrade and maintenance as well?
c. How application’s license is structured for end users?
8. Physical Location of Data and processes
a. What is the location of data?
b. What is the location of processes?
c. Is any point of time, location of data and process be ascertained?
9. E-discovery
a. What are the evidentiary issues when client data is in cloud?
b. What are the SLA’s of e-discovery?
c. Who is responsible for e-discovery?
10. Termination
a. In case of contract termination, how data will be moved from cloud to in agreed upon format?
b. Who is responsible to move data?
c. If cloud provider goes out of business then how termination will be handled?
d. If application provider goes out of business then how termination will be handled – data, intellectual property.
e. Is there any lock in?
11. Change in Terms and conditions
a. How change in terms and conditions to be handled?
b. Does cloud provider change terms and condition by inserting URL?
12. Audit
a. Can application provider do audit of facilities and processes/procedures and how extensive are these audits?
b. Can application provider do audit of logs and how extensive are these audits?
13. Miscellaneous
a. What insurance cover cloud provider has?
b. In case of emergencies how data be accesses and who will be responsible?
c. Use of application provider’s name and logo for publicity by cloud provider?
d. Use of cloud provider’s name and logo for publicity by application provider?
e. How service renewal will be handled?

Levels of Multitenancy

Before diving into multitenancy, let us understand how a typical application is structured.

From the picture supplied it is very clear that a contemporary application is based on layered architecture and runs on infrastructure and network on which typical servers sustained.

If you look into maturity levels of SaaS applications it seems that multitenancy exists only at Database level where one data stores multiple tenants a.k.a. Salesforce.com. This picture depicts a picture that before SaaS there was no concept of multitenancy.

If you dig little bit, it is clear that multitenancy can occur at any level. At Network and Infrastructure level collocation is prime example of multitenancy. View level multitenancy is at its best at blog sites. Business layer level multitenancy is very much present in Applications in Cloud.

Book Review: Cloud Computing - Web Based Applications that Change the Way You Work and Collaborate Online by Michael Miller

Book Review: Cloud Computing - Web Based Applications that Change the Way You Work and Collaborate Online by Michael Miller: Publisher- Que Publishing: ISBN- 13: 978-0-7897-3803-5

I have very little to say for Cloud Cloud Computing - Web Based Applications that Change the Way You Work and Collaborate Online.

1. It is long list of web based applications
2. Incorrect projection of web based applications as Cloud based
3. DO NOT WASTE TIME ON THIS BOOK

Disclaimer: I did not get paid to review this book, and I do not stand to gain anything if you buy the book. I have no relationship with the publisher or the author.

Further reading: None

Build, Buy or Reuse: Services

The one of the most flaunted benefit of SOA is reuse of services. But it is one of the least used aspects of SOA. But Why so?

In enterprises there is no framework exist which can evaluate a service/service requirement which help in reach a decision of Build, Buy or Reuse. To fill up this gap, I have developed a framework. This framework has three aspects:

1. Appraisal Structure
2. Evaluation Criteria
3. Influencers

Appraisal Structure

The Appraisal Structure offers a classification for the types of considerations within the context of the business. The considerations and decision to build, buy or reuse fall into the following categories:

a. Strategic
b. Tactical
c. Operational
d. Business
e. Technical

Strategic considerations deal with the long-term vision and direction of an enterprise. These include:

• Market Share and Differentiation
• Growth
• Strategic Change Management

Tactical considerations deal with the short-term decisions and direction of an enterprise. These include:

• Current Project Portfolio
• Cash flow considerations
• Time consumption considerations

Operational considerations deal with the operational aspects of a project or a portfolio of enterprise. These include:

• Governance
• Change Management
• Skills
• Support and Maintenance

The business considerations are the ones that support the short- to medium-term objectives of the business. These include:

• Contract Management
• Depreciating of Assets
• Internal or External Provision

Enterprise have a technical strategy—one that states what technologies can be used and for what purposes. Considerations in this category include:

• Technology Considerations
• Technology Choice
• Interoperability/Integration
• Repository of Assets

Evaluation Criteria

There are eight Evaluation criteria identified eight attributes that affect Build, Buy or Reuse decision of services.

• Delivery Time
• Complexity
• Investment
• Expense
• Maturity
• Requirements compromise/match
• Maintenance
• Support




Influencers

There are five influencers. Each influencer has attractive and repulsive force field. Which force field will be more effective depends upon particular scenario – internal and external environmental conditions.

• Investment: It has one of the strongest force field – attraction as well as repulsive. This influencer has numerous aspects such as remaining cost-neutral RoI, profitability, affordability, and finally the cost implications of not doing it.

• Expenses: This influencer affect any decision on continuous basis. Investment and expenses in combination cover financial aspect of Build, Buy or Reuse decision. Like Investment, Expense also has multiple views – Cash Flow, ToC, etc.

• Quality: In market one with right quality wins keeping other parameters constant. Therefore Quality of Service (QoS) plays major role while making Build, Buy or Reuse decision. This influencer is also multi facet. Most of the abilities or non functional requirements are covered under Quality head.

• Time: In fast changing environment time is very critical. Time to market is one of the important parameter which affects Build, Buy or Reuse decision.

• Sustainability: Due to fast pace of technological and business environment evolution, obsolesce of a particular service and effort needed to keep it updated drives Build, Buy or Reuse decision.

The framework is very general in nature. It must be tweaked to a particular enterprise business environment, vision, goal, objectives and tactical needs.

Reference: The Architectural Journal (Microsoft) 20

One measure for a Service

Customer view the interface part of service. But from architecture and design perspective apart from interface quality of code is very important. Keeping in mind this picture I have developed one measure:

Quality of Code (in percentage) =100* (Volume of code implementing business logic of service)/ (total volume of code for service)

Here the basic question arises how to measure volume of code. The traditional approach is LoC. But in OO world this is one of the biggest problems.

The measure, Quality of Code is not measure of Quality of service but one of the several measure which gives indication on frameworks used to realize a service. In ideal case the peripheral code to create a service should come from the framework/platform.

SaaS Pattern - SecureMyData

1. Pattern Name
SecureMyData
2. Also Known As
In house encryption & decryption service
3. Class Name
Architectural: SaaS
4. Intent
In SaaS environment security of customer specific data in multi tenant as well as non multi tenant environment is one of the most crucial concerns.
5. Motivation (Forces)
Alleviation of data security breach of customer data
6. Applicability
This pattern is applicable in SaaS environment.
7. Structure & Implementation
When end user asks for data.



When end user supply data.



8. Participants
N/A
9. Collaboration
N/A
10. Consequences
a. Increased traffic over network.
b. Additional infrastructure at customer site.
c. Additional implementation of message splitter and aggregator
d. Complex logic at user interface layer.
e. Customer satisfaction


11. Sample Code
N/A
12. Known Uses
To be find out
13. Related Patterns
This pattern is special case of Division of Labour (A-SOA-0001) pattern.
14. Reference
N/A

Download PDF from Scribd

Is SOA Dead! Nope.

Year 2009 started with bang, SOA is Dead; Long Live Services by Anne Thomas Manes. In her blog and subsequent interview in IT Business Edge she emphasized that SOA is dead in business parlance due to it is failed to deliver its promises of aligning IT with business in real time. She advises not to use SOA word while asking for funding in today’s recessionary economy.

But I have simple question, do we as analysts, architects (not as business person) have analyzed why this phenomena is happening. I don’t think so.

When I read her blog entry in starting of year, I thought of protesting. But, then I though of analyzing the whole story wearing multiple hats – IT Service Company, Tool/Platform Provider, Business Person, Analyst and finally as Architect. Nearly a quarter long conscious analysis, has given me few insights:

1. Most of the SOA initiatives started as integration project where services were used as integration medium in stead of MOM. To maximize reach (in terms of market capture and revenue) Tool/Platform Providers and IT Service Companies have added fuel to fire.
2. Most of the established Tool/Platform Providers saw SOA as new business opportunity, so re-branded their Integration Tools/Platforms as SOA one.
3. To maximize their revenue Tool/Platform Provider created grandiose Tools/Platforms which have resulted bleeding IT departments.
4. As usual, Analysts are folks who can offer criticism on every thing. So they provided argument on both sides. They provided criticism on Tools/Platforms, Methodologies and frameworks but sadly, never on SOA independent of vendors.
5. Architects are greatly influenced by Tools/Platforms to which they were conversant. That’s why we see Java Architect, WebLogic Architect, WebSphere Architect, .Net Architect etc in Architects’ resume and at monster.
6. Business persons wanted quick return on their investment (essentially, they want their investment should be like expense) due to business compulsion which prevented them justifying long term investment.
7. Nobody paid any attention to business process restructuring and operation restructuring which are essential foundations of successful SOA.

So, SOA is dead or just acronym SOA has become dirty. Certainly SOA is not dead but we have to work for its acceptance with business people. Business persons sanction budget not IT ones. Whether, acronym SOA remain in vogue or not, it does not matter. So, the core question is how to keep alive SOA and not only alive but healthy and thriving.

1. Understand SOA philosophy (SOA stands for Service Oriented Architecture) independent of Tool/Platform Providers offerings.
2. Technical folks have to understand business realities. Due to present economic conditions business wants quick returns. So, it is time of tiny SOA (not even small), which should fit into grandiose Enterprise Architecture. This world in not perfect.
3. Businesspersons also have to understand that there is no silver bullet; Architecture requires time, money and humans.
4. If acronym SOA has become dirty, change it or clean it. I leave this choice to analysts; it is their job to invent new acronyms.


Underlying fact is, SOA is not dead and will not be dead but morphing itself as Web 2.0/3.0, SaaS, PaaS, BPM, EPM, Cloud computing, etc (Refer: http://architecture-soa-bpm-eai.blogspot.com/2009/03/service-orientation.html).

Further reading:
1. http://apsblog.burtongroup.com/2009/01/soa-is-dead-long-live-services.html
2. http://blog.dhananjaynene.com/2009/01/soa-aint-dead-but-it-certainly-is-transforming/
3. http://blogs.progress.com/soa_infrastructure/2009/01/goodbye-soa-we-hardly-knew-you.html
4. http://technoracle.blogspot.com/2009/01/soa-is-not-dead-but-complexity-is.html
5. http://www.andrejkoelewijn.com/wp/2009/01/06/soa-is-not-dead-were-still-in-the-early-adaptor-fase/
6. http://blog.dhananjaynene.com/2009/01/stop-making-soa-complex/
7. http://rasmussenreport.wordpress.com/2009/02/16/the-death-of-soa-maybe-later/
8. http://soa-today.blogspot.com/2009/02/big-soa-is-dead-little-soa-is-thriving.html
9. http://samisa-abeysinghe.blogspot.com/2009/02/soa-is-dead.html
10. http://broadcast.oreilly.com/2009/01/soa-is-dead-its-about-time.html
11. http://tardate.blogspot.com/2009/02/soa-is-dead-was-it-ever-alive.html
12. http://www.theenterprisearchitect.eu/archive/2009/01/26/soa-is-dead-long-live-model-driven-soa
13. http://www.glaucoreis.com.br/is_soa_dead_i.html
14. http://www.arisblog.com/2009/01/07/technical-soa-is-dead/
15. http://drjbutler.wordpress.com/2009/01/06/soa-in-good-eternal-company/
16. http://havemacwillblog.com/2009/01/13/the-people-who-think-soa-is-dead-are-dead/
17. http://blogs.progress.com/soa_infrastructure/2009/01/soa-wanted-dead-or-alive.html
18. http://www.itbusinessedge.com/cm/blogs/byron/even-if-soa-is-dead-sca-and-sdo-alive-and-well/?cs=30222
19. http://www.itbusinessedge.com/cm/community/features/interviews/blog/why-soa-should-be-dead-to-the-business-but-alive-and-well-in-it/?cs=30407
20. http://www.ecommercetimes.com/rsstory/66104.html?wlc=1237532051
21. http://www.thinkovation.com/blog/index.php/2009/01/14/soa-dude-its-alive-and-kicking/
22. http://jshurwitz.wordpress.com/2009/02/09/yes-virginia-there-is-a-soa/
23. http://www.eweek.com/c/a/Web-Services-Web-20-and-SOA/SOA-Wanted-Dead-or-Alive/