"We didn't start the fire ... it was always burning since the world's been turning ..." [Billy Joel 1989]. Is SOA the "Same Old Architecture?" or is it "Simply Over Ambitious?" Let's apply SOA's arsenal:: XML, BPM, Services, SOAP, Web Services - to the real world and find out. Let's put out some fires.

« May 2008 | Main | July 2008 »

June 28, 2008

TurboCharge your SOA Infrastructure with XML Appliances-Part II

In this and subsequent blogs, I  plan to discuss the advanced features of XML Appliances: Field Level Fine Grained Security, Rule Based XML validation, XML to HTML transformation, XML to WML transformation and XML to XML transformation.  In this  and subsequent blog entries, I will discuss only Fine Grain entitlements, and discuss other aspects in a subsequent blog entry. 

XML Appliances- Advanced Features

In my previous blog- I discussed the basic capabilities of XML appliances. In this and subsequent blogs, I  plan to discuss the advanced features of XML Appliances: Field Level Fine Grained Security, Rule Based XML validation, XML to HTML transformation, XML to WML transformation and XML to XML transformation.  In this blog entry, I will discuss only Fine Grain entitlements, and discuss other aspects mentioned above  in a subsequent blog entry. 

Fine grain entitlements for XML

           XML Appliances can provide fine grained security for enterprise data available in XML format.

A Customer Record could for example be split into four parts based on entitlement based on role:

  • Sales Representatives can see Customer Record including internal discussions
  • Account managers can see, notes made during Sales Calls including details of clients organization
  • Support  Engineers can see technical details of past purchases by the client
  • Accountants can see details such as credit limit as well as credit rating of the customer.

The entire customer record could be represented as a XML document, which is secured using fine grained role based entitlements.  The standard used to describe the fine grained security-XACML-is described in an informative tutorial  

The processing of role based security can be very CPU intensive. A XML appliance can process role based fine grained entitlements in a cost effective manner.

XML data so secured could be made available to portals such as WebCenter 2.0 from Oracle.  It could also be used to create HTML using XSLT transformation. For PC and mobile clients, with the CPU capacity, this transformation can be done on the client. For other clients.with limited CPU processing capbility, the XML appliance itself can perform this transformation.

Posted by Kevin Apte at 06:10 PM | | Comments (0) | TrackBacks (0)

June 23, 2008

Service Oriented Elephant?

SOA applicability is very dependent on an organization's environment. Recently I got into a discussion about "SOA in the small." Is it feasible? I think not. But IMHO elements of SOA can be applied to the organization to fit into an enterprise SOA roadmap

This discussion reminded me of a couple of presentations I had made at a couple of conferences. I have combined these into a slideware presentation.

The fable of "The Six Blind Men and the Elephant" comes to mind. Stakeholders investing in SOA need to see benefits that are relevant to each and every one of them. Otherwise, you start losing the investors. Each stakeholder has a different view of SOA. I dub the the entire SOA landscape the "Service Oriented Elephant."

Your perspective of SOA will be depend on which end (or side) of the Service Oriented Elephant you end up at. But don't forget that in the end, there has to be an elephant for the parts (tail, tusks, ears, legs, side, or trunk) to make any sense. Similarly, there has to be comprehensive view of the "Service Oriented Enterprise" for any investment in SOA. You don't have to do it all, but there has to be an "all."

Posted by Ajit Sagar at 02:52 PM | | Comments (0) | TrackBacks (0)

June 12, 2008

The new movie on the Eisenhower System of Enterprise IT i.e. ESB?

The Eisenhower System was envisioned as a systematic, incrementally adoptable plan for surface transport for the United States, which has been in build and operation for around 50 years. It acts as the fundamental artery of passenger and goods transport across United States.

When we study the history and operation of the Eisenhower System (a.k.a The Dwight D. Eisenhower National System of Interstate and Defense Highways | http://www.fhwa.dot.gov/reports/routefinder/), we will find many parallels to the information superhighway of the Enterprise, the Service Bus, such as

  • Provided standardizations in naming, construction and operation, routing, governance (ownership, leadership, responsibility) and so on.
  • Sequential signage to easily plan and navigate through the routes
  • Had been lobbied for by major U.S. automobile manufacturers (as per Wikipedia)
  • Made a dramatic changes to existing routes, neighborhoods and associated cities (as described in Divided Highways, http://www.skidmore.edu/academics/roads/index.html or as we watched in the pixar movie ‘Cars’)
  • So many urban legends e.g. one out of every five miles of the Interstate Highway System must be built straight and flat so as to be usable by aircraft during times of war; this is not true.

When I find that the product vendors are pushing the enterprise IT for ESB adoption, where IT managers do not know what to do with existing message queue or EAI investments, it is very similar to the 50 years of the Eisenhower system. The current system owners are afraid that they would need to give away many of their exiting processing capabilities for cheaper sourced processing capabilities, interconnected through the super highway. Meanwhile, the architects are marching with their big SOA roadmaps and plans to construct new adapters, services and composites (=exits, entrances, interchanges, bridges and routes), where they debate and argue about the intricacies of service naming, bundling and so on. The enterprise governance officials (=bureaucrats, senators and congressmen) are deep in their discussion on funding, leadership, ownership and contracting, where there are many business driven exceptions (=one of the congressmen want to change the route to include his consistency). 

So let me propose to all the SOA enthusiasts – Folks, we should study the 50 years of The Eisenhower System; it should be handy to build our new Service Bus driven IT enterprise Architecture.

Posted by Binooj Purayath at 06:26 PM | | Comments (1) | TrackBacks (0)

June 11, 2008

The Right Orientation: Object, Service or Resource

We are continuously striving to represent the software concepts in such a way so that we can easily relate them to the real world entities and activities. IT provided automation and tools to create and facilitate a better business environment. Along this journey somewhere the solution (IT) to solve the business problems itself became a problem due to the complexities it created, which paved the way for creating new approaches to solve the business problems. The journey showed us the various styles of software representations and highlighted the differences in thought process in creating the software.

 

The various styles or architecture approaches so far being used are

  • Procedural oriented architecture
  • Object oriented architecture
  • Service oriented architecture
  • Resource oriented architecture

Procedural orientation provided the early automation but created complexities due to the separation of data and operations. Object orientation encapsulated the data and operations (methods) and moved us closer to the real world entities and simplified the programming model. Service orientation moved us even closer to the real world by aligning us to the business processes. The fundamental difference between object orientation and service orientation as I see it is the data vs. process emphasis. Object orientation approaches from the data entities point of view where it creates the objects which can encapsulate the data and methods related to that entity or object. Service orientation approached from the process point of view which encapsulated a process or a number of processes along with the entities participating in that process/s. Resource oriented approach is still evolving and is largely based on the concept of the World Wide Web. Everything that can represent itself and can be addressed by a request is treated as a ‘resource’. Unlike the object a resource does not have a state. Each state of the object itself can be represented as a resource.

 

There are multiple pros and cons of each of these architecture styles. These architecture styles can co-reside while addressing a business problem. It’s important to have the right business orientation rather than being religious about object or service or resource orientation. In my view, Business Oriented Architecture should be the right orientation and need to be adopted as a guiding principle while providing the IT solution to address the business problem.

Posted by Shreyas J. Kamat at 05:15 PM | | Comments (1) | TrackBacks (0)

June 08, 2008

Cloud Computing - SOA Interlinkage: Is it enterprise Ready?

Recent foray by lead vendors like amazon, google, ibm, microsoft etc. into cloud computing, wishes us to think of the scenario where enterprises are not required to own any infrastructure or applications of their own. This is enabled by powerful usage of SOA - namely Infrastructure available as a set of usable pluggable Services..But is this enterprise ready?..

Provisioning of Cloud infrastructure via services, be it storage, or compute power, or utility services, or even business services, is a great idea. However the very notion of usage of XML based Web Services (or even REST based services), over the web, to deliver on this vision of Infrastructural SOA with leverage of multiple infra services from multiple providers to create an enterprise app, as close to enterprise ready as possible, is ridden with its own set of issues, primarily stemming from the NFRs (non functional requirements in SOA)..

1. In distributed application development leveraging these cloud infra services, how is security handled in a robust manner?

2. Like in traditional in house hosted apps, will such federated infra be able to provide the requisite reliability (and availability - think 99.999 % for enterprise ready).

3. issues related to Data management, XML management, distributed synchronization models, transacation models, etc. is a huge area of gap to really address enterprise readiness..

 

we can go on and on..

This is a clarion call to create a research vision for such federated futuristic vision of zero in-house intra enteprise infra, leveraging best of breed infra services from the cloud via standards based SOA..There is a need for SOA researchers and grid community and the data base community to address this...

 

Posted by Dr. Srinivas Padmanabhuni at 07:09 AM | | Comments (4) | TrackBacks (0)

June 07, 2008

Turbocharge your SOA infrastructure with XML appliances-Part I

As SOA initiatives mature, the number and size of XML messages starts growing rapidly. The total XML traffic can therefore  grow exponentially. Elegant architectural design principles, such as canonical models, and model driven architecture,  require processing large XML payloads. Assuring good performance at reasonable cost, while maintaining SLAs can become challenging.  XML Appliances address this issue, and are maturing into a hardware/appliance based replacement for ESB.

XML Appliances address this problem by providing a low latency scalable and performant way of processing XML messages. XML appliance features may be classifiedas "Basic" and "Advanced"

Basic features include: Encryption, Compression and Schema Validation. These features have been used extensively for 5 or more years, and are well established in the industry.

Advanced features include:

  • Rules based validation using XPath and XSLT- messages that do not meet validation rules can be automatically rejected.
  • XPath based search
  • XML to XML transformation through XSLT
  • Rules based validation using XPath/XSLT- Invalid documents can simply be rejected.
  • XML to HTML transformation using XSLT
  • XML Content based routing
  • Conversion from flat files and legacy formats to XML(This feature seems to be available only in DataPower.)

Basic  features such as schema validation, compression and Encryption have been benchmarked at hundreds of megabytes per second.  It is a no-brainer to use XML appliances in this situation.

On the other hand, with advanced features, XML appliances run a lot slower. The speed at which XPath searches and XSLT transformation seems to depend on the complexity of the XML document, and the parsing task at hand. An aggregate XML message that simply aggregates hundreds of messages may be parsed very fast. But a XSLT transformation that does arithmetic calculations and complex transformation will run slower, typically 1-10 MegaBytes per second.

XSLT/XPath based transformations cannot replace work done in procedural languages such as C# and Java. Complex financial calculations, for example, or a validation that depend on other database systems or web services, must be done in C# or Java.

The claim that these appliances can replace an ESB seems farfetched. Intel has a Google campaign, that goes: Still using Tibco-Swith to Intel XML Appliance.(They repeat the campaign with other ESB vendors. )  ESB provides numerous features such as Protocol Mediation, Applying Business Rules, Assuring connectivity between Java and .net systems. It could be argued however, that the XML transformation, which can be a large part of the CPU usage of an ESB  can be offloaded partially/completely to an appliance.

XML Appliances provide performance benefit, as well as the benefit of lower latency.

The other advantage of the appliance is consistency of speed. Unlike a J2EE server that may underperform periodically due to other applications, or due to Garbage collection, an XML appliance performs at consistent speed.

The fully loaded cost of a J2EE or Portal Server can approach 100,000 dollars or more. Using this server for XML Transformations that can be done on lower cost XML appliances, is wasteful.

Skillfully integrating XML appliances with your ESB, Messaging and Application servers may provide critical performance benefits to your SOA initiative. It also changes the debate about the feasibility of using XML for intra and inter-enterprise integration.

In future posts, I hope to elaborate on integration of fine grained and rule based security using a XML Appliance, Deciding when to use XSLT/XPath, and integrating the appliance into the messaging and ESB infrastructure.

Posted by Kevin Apte at 10:30 PM | | Comments (2) | TrackBacks (0)

June 05, 2008

Does BPM mess up SOA?

I have always thought of SOA & BPM as two complimentary solution approaches. There are numerous articles that talk about interplay and synergy between SOA & BPM, and this has become so obvious that any new article on this topic doesn’t even draw my attention. However I recently stumbled upon a blog post titled ‘Why BPM screws up SOA’ by Steve Jones that really caught my attention. I completely disagree with Steve ...

 

This is a rather long post. I apologize I couldn’t keep this short, as given the highly debatable subject I think I need go deep into this matter and put forward my views in detail


Steve has made following points in his blog
1.      “Processes are not the ultimate thing in business” – in fact there is a separate blog on this topic
2.      “if you start with BPM, which is about coordinating steps, then suddenly every service looks like a step”
3.      “If you are doing BPM and then just saying "step = service" then you are doing VISUAL Cobol and replacing function calls with service”
4.      “BPM driven SOA tends to make bad SOA as it is driven from a procedural and process view, has poor separation of concerns and is mostly all about driving things from the technology perspective”
5.      “SOA makes great BPM, BPM makes crappy SOA”
 

With due respect, I completely disagree with Steve’s views. IMHO SOA & BPM are different, yet very complimentary. SOA is a technology approach towards standardizing & streamlining IT systems; while BPM is an approach towards standardizing & streamlining the business processes and operations. The objective of SOA is to make the IT systems agile and promote reuse of IT assets, whereas the goal of BPM is to make business processes agile and promote reuse of business operations & processes across the enterprise.
 

To the first point above where Steve asserts that “Processes are not the ultimate thing in the business” and refereed to his different blog post which states that –
 “Its an old truism that KPIs drive behavior …. , it is therefore, when modeling the architecture, more important to consider these KPIs and the underlying business goals than to worry about the audit process that will allow elements to be measured. This is a great example of where the business value and importance is assessed via the KPIs and Goals, but is measured by the implementation of a process.
…..
In fact I'd say that for most Services the concept of "Goals" will be more useful than the concept of "Process".
 

Now here Steve is totally contradicting his own views that “BPM driven SOA tends to make bad SOA …”, on the contrary when you set out for BPM you first define the objectives and goals for the process. You seek clear answers for questions such as – ‘what this process is all about’, ‘what is it is trying to achieve’, ‘what business value does it generate’, ‘does it really make critical business value to consider for process management’. You define business goals for the process (e.g. enhance responsiveness, improve strike rate, reduce cost, etc) and derive process and activity level KPIs (which are then defined in the business process model for the purpose of business performance monitoring). So going by Steve’s assertion that any SOA initiative should be goal and KPI driven, then here is the way - go on BPM path.
 

To the second point above where Steve’s view is ‘BPM is all about coordinating steps’ – to me it sounds a hardcore technical guy’s pov of BPM. First of all, BPM is not just about automating business process. The real goal of BPM should be to build systems that facilitate continuous business process optimization; put in place infrastructure that enables monitoring business process performance to identify any bottlenecks that hinder in achieving the business goals (target KPIs for the process). Refer to my other blog post ‘BPM – Moving beyond modeling to complete process management’ where I have discussed importance of setting business performance improvement targets as success factor for any BPM (and SOA) initiative. A BPM or SOA project that’s completed within time and budget but does not add to organizations’ top line or bottom line is complete waste. It’s BPM that ensure unremitting focus on business value.
 

However, even if we look at BPM just for automating business processes (and ignore the larger benefits), BPM is not about ‘coordinating steps’ (I assume by ‘steps’ Steve is referring to statements & function calls in typical computer language) BPM is about orchestrating Business activity. When you do BPM you don’t set out to externalize program flow rather the objective is to externalize the flow of business signification activities (fulfilled by multiple heterogeneous internal systems or partners’ systems). This is like difference between high level business process model v/s program flowchart. BPM is not an attempt to translate flowchart into executable artifacts, rather it’s attempt to define business process models and translate that into executable artifacts that coordinates execution of various business significant activities.
 

To the 4th point – “BPM driven SOA tends to make bad SOA as it is driven from a procedural and process view, has poor separation of concerns and is mostly all about driving things from the technology perspective” – There is very clear difference between procedural and process view. Again the analogy of business process model v/s program flowchart would be helpful here. It would be very procedural if you attempt to translate a program flowchart into BPM model. BPM is not a code generator. And saying that it has poor separation of concern and driving things from technology perspective is completely false. In fact BPM significantly promotes separation of concerns by externalization of process flow (not program flow) logic from the code.
 

And to the last point - “SOA makes great BPM, BPM makes crappy SOA”. I think the reverse is the reality. SOA without BPM runs the risk of loosing sight of business value, doing SOA with BPM focus ensures that IT delivers to business goals rather than end up creating elegantly architected system that doesn’t have any business impact.

Posted by Dhiren Mehta at 07:15 PM | | Comments (2) | TrackBacks (0)

June 04, 2008

SCA Java EE Integration Spec brings the Java world closer to SCA

The SCA Java EE Integration Specification has been released. It is quite an interesting read. The vision of SCA is to build composites and composite applications out of configurable, reusable service components or assets as I had tried to explain earlier. It does not intend to replace existing open standards but to build over those standards to enable a technology agnostic service component integration platform. So it has support for multiple communication protocols (or binding types), component implementation languages (implementation types) and component interface languages (interface types). The list of these types is growing. Also I had mentioned (SCDL vs WSDL) the promise to support so many technologies in a standard manner is indeed a big one! This often gives rise to skepticism in some quarters and comparison with similar looking standards such as the JBI.

However, it is important to remember that in the world of SCA, the concept of service component (or simply services and not necessarily web services) is fundamental. An important aim or design goal of the set of SCA specifications is to enable exposure of existing software assets as service components having well defined, carefully designed and publicly visible interface definitions. This is also one of the important goals of service-orientation and SOA. The latest Java EE SCA Integration Specification re-instates that. It specifies how a given JAR/WAR/EAR (Java application / component archive) which has already been built (without having any SCA stuff in mind), could be converted into a first class service component (technically called an SCA contribution). So I can re-use my existing set of Java EE components (sorry only Java EE and not J2EE L) and convert them into service components to be used by others. Imagine a BPEL component talking to an EAR module directly! The specification also enables Java EE web modules to be exposed as SCA contributions and enables presentation components such as JSPs to directly consume SCA enhanced service components, bringing my dream of Portal Composites a step closer to reality.

To the discerning it may appear that there is a good amount of overlap (re-use) between this specification and the Java EE specifications and indeed I had to go back and forth on this specification to really understand its potential. But I find this overlap proper as the SCA is not trying to re-invent the wheel but map the critical features of existing platforms into the SCA, and at the same time ensuring that the final product is a simple uniform looking service component to be consumable by other platforms, enabling interoperability to a large extent.

 

Posted by Sudeep Mallick at 03:11 AM | | Comments (3) | TrackBacks (0)

June 03, 2008

Service Oriented SOWs

Around the budgeting cycle at establshed clients, the three dreaded words "Statement of Work" loom around the corner. Why dreaded? Well, getting all the ducks in a row, tailoring the effort, resources, and cost to the ever-changing environment of the corporate world is always a big challenge. Interestingly, the basic principles of SOA can be readily applied to the preparation and publication of SOWs.

In fact, we have successfully done this at a client. In order to provide clarity around the work that we offer, the definition of services followed the same process as the definition of services in an enterprise system. Here is how it went. Before creating the SOW document, the following steps were to be followed:

  •  At the start of this style of SOW management, discrete service groups were identified for each external vendor
  • At the start of the budget allocation, all the "service leads" needed to define the services offered by their teams.
  • The consumers of the service needed to be clearly listed
  • The service definition needed a clear definition of SLAs and escalation channels
  • The triggering business processes (for example, "application review") for each service level needed to be identified
  • The processes affected by the service were clearly identified
  • OLAs (Operational Level Agreements) were defined for processes on which the service was dependent.
  • The duration of the service, the turnaround time, etc. were documented
  • The links to the services were added to the documentation of the invoking business process
  • Finally, the services resources were estimated and the SOW was created.

There you have it. An organizational, operational application of SOA principles. Actually, is it not the other way around? SOA is a discipline/concept that grew out of business processes and business services. Sometimes we forget that the chicken came before the egg (or the other way around :-))

Posted by Ajit Sagar at 02:40 PM | | Comments (0) | TrackBacks (0)