Real World SOA | David Linthicum | July 2006

MORE ENTRIES

July 2006

July 31, 2006 | Comments: (0)

I Get Open SOA Collaboration...But Learn from the Mistakes of the Past

If you check out this news item, you'll see that:

"An alliance of leading software vendors Wednesday announced progress on specifications to define a language-neutral programming model for application development within SOA (service-oriented architecture) environments."

In essence, they are proposing a new standard to create and manage IT making the process of integrating different third-party SOA technologies "less onerous."

BEA Systems Inc., IBM Corp., Oracle Corp. and SAP AG first got together in November to begin work on the common programming model along with Iona Technologies PLC, Sybase Inc., Xcalia SA and Zend Technologies Ltd. Others are joining the mix, include Software AG and Red Hat.

Under the banner of Open SOA collaboration, the vendors have concentrated their efforts on two projects -- service component architecture (SCA) and service data objects (SDO).

Form their Web site it seems that SCA is looking to provide a model for the creation of service components in a wide range of languages and a model for assembling service components into a business solution. Okay, that would be orchestration, correct?

SDA is looking to provide consistent means of handling data within applications, whatever its source or format may be. Okay, that would be data abstraction. Moreover, SDO provides a way of unifying data handling for databases and for services.

New? No. Interesting? Sure. We've seen these types of standards before with the rise of client/server, CORBA, and Java, all looking to provide standard mechanisms of development for SOA, or the way we bind all of these things together to form applications. The SDA concept has been done to death, specially, with some successes and some classic failures.

The real battle to be won here is developer's acceptance of these standards, as always. For that, the vendors need to work together to implement the standards in the very same way...something that's been tough to do in the past. Thus, they'll need to put aside their desire to stand out and focus on being the same...an unnatural act for most.

Also, it will be interesting to see where this standard goes in context of BPEL and other standards that provide the same solution patterns. At the end of the day standards are only useful if there is one for each problem pattern. Thus far in the world of SOA we have 3 or more standards for each problem pattern. Those who consume the technology won’t touch standards until the problem is solved. Once bitten, twice shy.

Posted by Dave Linthicum on July 31, 2006 07:04 AM

July 30, 2006 | Comments: (0)

SOA and Data and Step 2 of my 12 Steps to SOA

Download file

Posted by Dave Linthicum on July 30, 2006 06:24 PM

July 28, 2006 | Comments: (0)

Non-Visual Mashups Rule

I thought that InfoWorld knocked it out of the park with this article on "Enterprise Mashups" by Galen Gruman. Yes, they are hosting this blog, so what of it? :-)

With the advent of rich client and extensible interfaces such as AJAX, we now have the ability to quickly create mashups to solve specific business problems using standard dynamic interfaces that front services. Mashups are powerful ways of taking existing applications and services, and creating something even more useful for business.

However, I think that there are really two types of mashups emerging: visual and non-visual.

Visual mashups, are mashups we are more than aware of today as we mash Google Maps with a sex offender database, or a real time stock ticker with a portfolio manager. The value is there, we take two different interfaces and create something that is more useful than the two separate applications, kind of a 1+1=3 thing. Clearly, this is the "sex on the screen" aspect of SOA and mashups. We’re bound to so a ton of these in the near future, if not already.

Non-visual mashups are the mashing up of two or more services to create a combined application, or integration point, to service a business process. What's unique here is that they may not externalize anything to a user interface. For instance, mashing up a stream of customer addresses with an address validation service, or mashing up a stream of social security numbers with a credit check service. Each non-visual mashup, perhaps, is sending exceptions off to another stream or queue for processing later, or perhaps to other mashups. This is very simple, and I bet you can think of even more complex and valuable non-visual mashups for your own enterprise.

Truth-be-told, while visual mashups are cool and useful, I think that non-visual mashups will be more valuable to business as time goes on. So, if you’re mashing stuff up remember to consider the non-visual with the visual, as well as how this all works in the context of your SOA.

Posted by Dave Linthicum on July 28, 2006 01:20 PM

July 27, 2006 | Comments: (0)

HP Buys into SOA?

As many of you know by now, HP announced Wednesday that it had reached an agreement with Mercury in a deal worth about $4.5 billion. News to some, but this buyout was a rumor that I've heard several times.

"After the announcement, HP CEO Mark Hurd said the move will double his company's software revenue to more than $2 billion annually, adding that the combination of the companies' product lines will make HP 'an end-to-end leader in IT management.'"

Clearly, the Mercury products will add a lot of value to HP Open View tools that focus on performance and availability of systems and IT Infrastructure. However, if you recall a few months back Mercury Interactive also has the essence of Systinet as well, a SOA directory and governance technology.

So, what did they buy what for, and for what?

Who knows as this point. However, I do know that Systinet had some damm good tools, and now HP has some damm good tools, including the legacy Mercury Interactive tech. But, it's up to HP to make sure this stuff works and plays well with their existing technology. That is easier said than done, believe me, but I wish them luck.

This continues with the great consolidation that will occur in the next year or so, as larger companies learn that it's faster to buy their way into SOA, than build their way into SOA. Not sure how I feel about that at this point. I'll let you know.

Posted by Dave Linthicum on July 27, 2006 12:30 PM

July 26, 2006 | Comments: (0)

SOA Adoption and Step 1 of my 12 Steps to SOA

Download file

Posted by Dave Linthicum on July 26, 2006 06:39 AM

July 22, 2006 | Comments: (0)

3 Areas where the SaaS Guys are Falling Short, and How to fix it

Ha! Made you look. I bet you thought that I was going to rage against the SaaS machine, but nothing could be further from the truth.

However, there is always room for improvement, and while I'm out there working with the SaaS guys I am finding a few areas where many can improve. Figure I would mention them here so we can all learn what to look for.

1. SaaS guys do not value the non-visual interfaces, as much as the visual application engine.

SaaS guys need to learn how to make all of the functionality that's available through the visual interfaces available through the non visual interfaces as well...typically Web services. Today, most do not, and as we look to extend the reach of our SOAs to incorporate or SaaS partners, this requirement is on the critical path.

It's easy to fix this. Okay, it’s easy to understand how to fix it, costly to implement, but this is critical to the success of the SaaS player. Indeed, non-visual interfaces (Web services) could be the way we leverage SaaS players going forward, the majority of the time.

2. SaaS guys typically don't consider integration to other SaaS players.

While the focus as been on integration between the enterprise and the SaaS, as more enterprises move their applications to SaaS, there is a growing need for SaaS to SaaS integration. Unfortunately, as customers are requesting this, many of the SaaS providers are stumped for an answer; beyond hire a bunch of developers and hoping for the best. That is what everyone thinks is the answer, and thus end up spending way to much money for a cumbersome architectures that lack agility. Don't get me started on that.

3. Many are slow in supporting true rich client technology, such as Ajax or Flex.

Thus, the SaaS delivered applications are still the old school HTTP push and pull, and thus don't have the look and feel of native applications. Flex and Ajax are here to stay, they work well, and those SaaS players that support true rich client Internet delivered applications will rule the world, and make the user experience just that much more fulfilling and productive.

By the way, I am not talking about any particular SaaS player, just some general comments. Solve the above problems, and it will be a few more nails in the coffins of enterprise software, moving to a "global SOA," Web 2.0, and a pervasive computing environment, which is just drop dead sexy.

Posted by Dave Linthicum on July 22, 2006 01:50 PM

July 20, 2006 | Comments: (0)

Is "Traditional EAI" a good fit for SOA?

Download file

Posted by Dave Linthicum on July 20, 2006 10:44 AM

July 19, 2006 | Comments: (0)

SOA and Data Integration...Final Word

In contrast to coupling, cohesion is the "act or state of sticking together" or "the logical agreement." Cohesively integrated source and target systems are independent from one another. Changes to any source or target system should not affect the others directly. In this scenario, information can be shared between systems without worrying about changes to the applications or databases, leveraging some type of loosely coupled middleware layer to move information between applications and make adjustments for differences in application semantics. Most data integration product leverage the notion of cohesion.

The advantages of using cohesion included:

The ability to avoid changing source and target systems just to facilitate integration. You no longer have to make changes to the systems because the points of integration are less invasive.

The fact that a single system failure won’t bring down all connected systems. Since the systems are not dependent, a failure typically won’t affect the integrated systems (at least immediately).

The disadvantages include:

The inability to provide visibility into the services layer, and thus gain value from encapsulated business services and tactical functions. This is simple information movement; there is usually no notion of services access, thus remote applications can only see information not behavior, thus no reuse of services.

You need to consider the tradeoffs. Coupling, or service-oriented integration, provides the greatest flexibility as the application integration solution moves into the future. The notion of leveraging services makes the application integration solution much more valuable than simple information movement.

However, cohesion has its advantages. Systems can be added to, changed, or removed from a cohesive application integration solution without typically requiring changes to any of the other systems in the problem domain.

Posted by Dave Linthicum on July 19, 2006 05:33 AM

July 18, 2006 | Comments: (0)

SOA and Data Integration Part 3 Saga Continues...

Okay, sorry about the delay in getting this blog done. I was going to do it on Friday, but decided to go to the gym instead. Moreover, I was going to do it yesterday, but hey it was Monday.

However, it also gave many PR people the opportunity to send e-mail after e-mail pitching their company as the "data integration solution for SOA." Very funny. It's just a blog guys, relax.

Okay, back to work.

In order for a technology to be truly a SOA technology, or so I argue, it needs to support the notion of coupling, as well as cohesion, and not just one or the other. This is where some data integration products fall down.

Coupling, in the context of application integration and SOA, is the binding of applications together in such a way that they are dependent on each other, sharing the same services, methods, interfaces, and perhaps data. This is the core notion of SOA where the applications are bound by shared services, versus the simple exchange of information (using services or not).

Of course, the degree of coupling that occurs is really dependent on the SOA architect, and how he or she binds source and target systems together. In some instances systems are tightly coupled, meaning they are dependent on each other. In other instance, the are loosely coupled, meaning that they are more independent. It matters not if you're doing this through Web services or other mechanisms, you're typically going to have to make these architectural tradeoffs within the notion of coupling.

There are, of course, more pros and cons of coupling that should be considered in context of the problem you’re looking to solve. On the pros side you have:

The ability to bind systems by sharing behavior, and bound data, versus simple sharing information. This provides the integration solution set with the ability to share services that could be redundant to the integrated systems, and thus reducing development costs. This is the reason we leverage SOAs.

The ability to tightly couples processes as well as shared behavior. This means that process integration engines, layered on top of SOA solutions have a better ability to bind actually behavior (functions, methods, services), versus just simple move information from place to place.

The problem is that many data integration solution are more about information/data and not about sharing services, thus they are hard fit for many SOAs. ESBs have a similar issue, but not as obvious. Thus, the marriage between data integration and SOA could end up in divorce if coupling is a requirement. Again, generally speaking.

More on this topic tomorrow, or if I feel fat, the day after.

Posted by Dave Linthicum on July 18, 2006 06:29 AM

July 11, 2006 | Comments: (0)

SOA and Data Integration Part 2

Unlike SOA, which can support real-time data movement, data integration (typically) provides adequate business information (data replication) without up-to-the-minute access of information. In many cases, the data is weeks, even months, old, and the data mart or data warehouse is updated through antiquated batch, extract-aggregate-and-load, processes. Indeed this is the way integration is done today, using a data integration product or in most cases no product at all. When I was doing research for my last book, for instance, I found that FTP was still the primary form of data integration.

Things are changing, fortunately. SOA, and the technology that comes with it, allows data warehouse architects and developers to move information – no matter where it comes from or where it is going – as quickly as they want to move it. As a result, it is not unheard of to have all participating databases and services in a SOA solution receiving new data constantly, thus providing more value to those using the source and target systems existing within the SOA – including those who use them as a data warehouse or data mart.

Therefore, the rise of SOA will also lead to the rise of real-time data warehouse solutions, or could replace the notion of data warehousing all together. For instance, we could place the data behind services (data services or abstract data services), with users able to leverage up-to-the-minute information to make better business decisions using BI tools or BAM, or just snap them into composite applications.

As fore mentioned, as time goes on the data integration products may not be needed as SOA architects craft services that abstract both operational and aggregated data, in some cases leveraging aggregated data without having to replicate and change the data, but instead do it through abstraction layers. This approach, if possible for your domain, is much less costly and less complex. In essence, the SOA becomes the place to leverage services that can deal with the data layer(s) through many types of abstraction services, services that can be mixed and match in composite to create solution instances for the SOA. Thus, the value of SOA, bringing all of these things together as a platform for business solutions.

So, how will we get there, and what can the data integration vendors do? I'll hit that later in the week.

Posted by Dave Linthicum on July 11, 2006 04:28 AM

July 10, 2006 | Comments: (0)

SOA and Data Integration Part 1

I'm going to tackle SOA and data integration this week due to the number of e-mails I've been receiving on the topic. I did indeed address it in my Podcast this week, but I would like to hit this topic in my blog as well, perhaps provide some more light.

First, the history. Data integration is the name the vendors have adopted to replace ETL (Extract Translate Load), Data Cleansing, and Data Warehousing tools of days gone by. These tools actually pre-date the notion of EAI, and were really the first sets of technology designed to deal with data and the usage of that data for decision support (business intelligence now). They would extract large amount of data from a single or several operational data stores, clean the data, roll up the data, and place it in another data store, typically the data mart or data warehouse for analysis. From there somebody would "mine" the data to extract relevant information, such as productivity over time, sales effectiveness over years, profit by division, you get the idea. Very powerful notion for its time, and very powerful technology today.

When I first was working on the notion of EAI, I did indeed use these tools, and thought they had value. However, I also understood that the value of integration was really about movement of information in real time, system to system, in patterns that resemble actually business processing (sales to inventory to accounting, etc.), and while there was some business intelligence there it was really in the domain of real time monitoring (BAM). Thus, you really had two different threads of technology that was born...ETL (now data integration) and EAI (now integration or SOA).

Enter SOA, and the hype around it, and everyone looking to link to it. All data integration vendors, and EAI vendors for that matter, are repositioning, retooling, and remarketing their technology as a "SOA solution." So, where is the actual fit for data integration?

I'll hit that tomorrow, or Wednesday.

Posted by Dave Linthicum on July 10, 2006 05:20 AM

July 10, 2006 | Comments: (0)

SOA Report Podcast...SOA 2.0 and Data Integration and SOA

Listen to the latest SOA Expert Podcast

Posted by Dave Linthicum on July 10, 2006 04:16 AM

July 06, 2006 | Comments: (0)

SOA 2 point Oh No!

It looks like the anti-SOA 2.0 on-line petition is passing 400 entries now, and growing. Proof positive that people are getting sick of the hype around SOA, and want the vendors and service providers to focus on the discipline, not the marketecture. So, are the marketing departments listening? I'm not sure they are, and this is only going to hurt the progress being made here and their bottom lines as well.

What;s clear about the SOA is that while we are beginning to see tactical successes now, the large scale benefits of leveraging this concept have yet to be understood by most organizations, albeit there are a few successes to report on now. Truth-be-told it's going to take time before we can brag about the benefits of SOA, and perhaps the hype will have died down by then, and thus some of the confusion that's around today. This confusion includes the number of WS-* standards that are around, many of which are redundant and conflicting. But, that's another column or blog.

While "SOA 2.0" is a silly notion, we are indeed looking to evolve our thinking to a place where SOA is more of "the architecture" not "an architecture," there is a difference. What's is more, we need to understand that systemic changes such as the use of SOA is going to take many years, for most organizations, to implement, and unfortunately there are no shortcuts such as just changing version numbers.

Posted by Dave Linthicum on July 6, 2006 06:04 AM

July 03, 2006 | Comments: (0)

How about Some SOA Humor for the Long Weekend?

5 SOA Tips

1. Never have a Web service call itself...you'll go back in time.
2. Make sure to purchase a governance tool. Not that you'll need it, but it's just cool to say "governance tool."
3. Make sure to search and replace "EAI" with "SOA" on your resume.
4. Find out if ESB will be in this year. Never buy technology that's out of fashion, no matter if it works or not.
5. Be the first guy on your block to say "SOA 3.0."

Posted by Dave Linthicum on July 3, 2006 05:05 AM

REAL WORLD SOA PODCAST

Listen to the latest podcast:

MP3 •

•

• Archive •

Technology White Papers

InfoWorld Technology Marketplace

» Technology White Papers Library

Technology White Papers by Topic

Technology White Papers E-mail Alert