Real World SOA | David Linthicum | March 2006

MORE ENTRIES

March 2006

March 31, 2006 | Comments: (0)

You remember patterns don't you? They are defined by WikiPedia as:

"A pattern is a form, template, or model (or, more abstractly, a set of rules) which can be used to make or to generate things or parts of a thing, especially if the things that are generated have enough in common for the underlying pattern to be inferred or discerned, in which case the things are said to exhibit the pattern."

What I am seeing in the world of SOA are architectural patterns that are beginning to emerge around problem/requirements patterns and solution patterns, and perhaps it's time we began to take notice of these patterns to speed development and increase the chances of success.

In using patterns we are learning from the successes and mistakes of others by understanding both the problem and solution patterns, and the relationships between them. For instance, say you're embarking on SOA for a particular domain. That domain will have certain problem/requirement patterns, such as:

Critical information movement.
Need for transactions.
Light weight process execution requirements.
Use of existing systems.

From these problem patterns we can find architectural solution patterns that match up, perhaps including:

Use of messaging system with service abstraction to address information movement requirement.
Use of transactional middleware, and standards supporting transaction, such as WS-Transaction.
Not using a process integration or orchestration layer at this point, because it makes the architecture too complex.
Use of legacy abstraction technology, allowing older proprietary interfaces to appear as standard Web services interfaces.

You get the idea. Again, a pattern is a something that repeats, both the problem and the solution, and in essence we're using experiences of others, as well as experiences within our own organizations.

So, why are we not doing this today? The problem is that you need to have access to those experiences, which is not the case today. However, we could create a database of SOA patterns if everyone would agree to contribute, but chances are there are too many legal and cultural obstacles. I can't help but thinking there should be a way around that, considering the benefit.

Posted by Dave Linthicum on March 31, 2006 11:02 AM

March 29, 2006 | Comments: (0)

Could "Web 2.0" Kill Web 2.0?

Buzzwords are key to this business. I did fight back long ago, but now I'm much more accepting, understanding that old notions with new handles are what the press and end user communities are looking for. It's kind of like pop culture for technology.

I'm responsible for a few of them, if not creating them, than promoting them into the mainstream, so I can't afford to sound too much like a hypocrite here. However, I've also seen how emerging notions and the buzzwords that follow them, can put a bad taste in everyone's mouth if they are overused and over-hyped.

The latest, is "Web 2.0," which I've blogged about here. Basically Web 2.0 is anything and everything associated with modern Web applications, and it seems to be moving from a very narrow and meaningful definition to something that is much too broad and far reaching.

Marketing is doing this. As I'm meeting with VCs these days I'm finding that all of their pitches in the last several weeks were Web 2.0 applications. However, upon a closer look they are mere static Web sites, clearly not in the core notion of Web 2.0 if you ask me. But, nobody is asking me. They are just leveraging a hot term to make their product look better. Thus, the term is being diluted. Hence, it will be tagged as hype, and nobody cares for hype in the long term.

Web 2.0 to me is really something that defines the disruptive technology that is now shaping the new Web, including use of Web services, rich clients such as Ajax, and the empowerment of the user to create their own dynamic and meaningful content. However, most of all the Web 2.0 is a platform where many disparate systems can communicate to automate business processes in and between enterprises, the global SOA. If we keep that goal in mind we'll be okay. If we go off target the Web 2.0, the term, will be a dot bomb.

Posted by Dave Linthicum on March 29, 2006 06:32 AM

March 28, 2006 | Comments: (0)

SOA: Focus is on Approaches, Not Technology

So what's hot these days in the world of SOA? Governance, registries, orchestration,...? Nope. As those looking to implement SOA seek that first killer project the emphasis is on what to do, not what you use.

This is a clear trend that I'm seeing in the SOA space, those charged with building SOAs in their enterprise are working on establishing an approach to the implementation of their SOA instance, and are not yet looking for "key enabling SOA technology," at least not yet.

If you ask me this is a good trend. While the attraction of SOA is the hot new technology in this space, or perhaps the reinvention of existing technology, most enterprise architects view this as a key strategic initiative, and are not willing to fool around, perhaps turning this notion into a technology bake off.

Finding an approach is not that easy, however. There is certainly a lot written on this topic by some very smart people, but the right approach for your particular organization may be a bit different from the generalized approaches/methodologies you see around today. In other words, you'll be doing some planning to create the plan.

What this trend will result in, you just wait, is a focus on design and planning tools more so than implementation technology. Truth-be-told there are not many design and planning tools out there for SOA, and the ones in the market are not impressive at all. Hopefully, we'll see some creative and well funded startups in this space soon. VC guys, are you listening?

So, if you're focusing on what you need to do, you're in good shape. Those that jump directly to "what to use," are fooling themselves in thinking that a lack of understanding of the problem domain will be overshadowed by killer technology. That never works.

Posted by Dave Linthicum on March 28, 2006 08:26 AM

March 24, 2006 | Comments: (0)

SOA Expert Podcast Show 33...My Interview with ARCast a Crosscast

Listen to the latest SOA Expert Podcast

Posted by Dave Linthicum on March 24, 2006 06:30 AM

March 23, 2006 | Comments: (0)

Traditional IT versus SOA Architects...There is a Difference

I'm done with my worldwide tour, SF, Vegas, and Orlando yesterday. Good use of time, but boy is travel a pain these days.

The EAC conference is a great opportunity to speak to the more "traditional" IT architects, or old school, which I'm finding are a bit different than the SOA architects, or new school. So, what are the differences?

Traditional architects work from the enterprise out to trading partners and the Web, but only if needed. SOA architects work from the Web to the enterprise. Indeed the SOA guys look for newer Web 2.0 standards to enable new processes within their architectures, such as RSS, Web services, Ajax, etc..

Traditional architects work with canned methodologies, such as Zachman, where SOA architects pretty much wing it. This is not to say either approach is bad, but I am seeing a need for discipline in terms of insuring success. Not sure you can "wing" an enterprise architecture, it's just too big and complex.

There is some cross pollination within the groups, but I'm still seeing a huge valley between these guys, and I also see a need for them to work together, or perhaps become the same person. The disciplines of the more traditional world are needed in the new world of SOA, and both sides need to understand that there is not much difference in the desired end state. SOA, as I've said before, is really good architecture at its essence. But, good architecture is good architecture, no matter if you're old or new school.

Posted by Dave Linthicum on March 23, 2006 05:34 AM

March 22, 2006 | Comments: (0)

New Podcast Out There Show 32...EAC Keynote 12 Steps to SOA

Listen to the latest SOA Expert Podcast -- EAC Keynote 12 Steps to SOA.

Slides are here:

Download file

Posted by Dave Linthicum on March 22, 2006 04:28 PM

March 20, 2006 | Comments: (0)

New Podcast Out There Show 31...Notes from Microsoft SPARK

Posted by Dave Linthicum on March 20, 2006 08:57 PM

March 20, 2006 | Comments: (0)

Notes from SPARK - Part Last

Did not get a chance to blog yesterday. Pretty full day at the final day of SPARK on Sunday, in bed by 11:00 and up at 5:00 AM to catch my flight, which was late by the way. As you may remember the goal of SPARK was to think about, if not actually define the next generation architectures considering the influences of Web 2.0, SOA, and SaaS.

We worked on a few things including attempting to model what the next generation architecture will look like. Pretty interesting exercise, but all of the groups had very different views. You can see the photos of this meeting here. Note that Microsoft put no restrictions on what information gets out of that meeting, they were very good hosts and there was no selling during either day.

The building of the models was a bit chaotic. I was teamed with Phil Wainewright from Looselycoupled.com and Steve from Disney. Phil suggested we leverage his Web 3.0 model. It's very simple, and as good as any, working up from services, to aggregators, to applications. Note that as you rise up through the stack, the more expensive the layer. I would have added a few more things, but I think the model was close enough, and its simplicity is actually its power. I've never seen complex models work, at least in the projects I've been involved with.

The other models took very different and much more complex approaches, take a look at the results here. Not sure I could find common patterns, but everyone agreed that the next generation architectures using SOA and Web 2.0 notions were going to have the following basic characteristics:

1. The user is empowered to create and own dynamic content.
2. The lines are blurring between enterprise architecture and the next generation Web.
3. The Web is more changing and dynamic than the enterprise.
4. Composite applications, outside service consumption, and mashups are here and are going to accelerate.

The best part about this event was to catch up with friends, such as Dion, Anne, Gregor, and Phil. Also, finally got to meet Graham, and Steve, as well as the other 15 or so people, including a few from Microsoft, and the CTO of Myspace.com Aber Whitcomb.

So, would I do this again if invited? Sure. I was impressed by Microsoft's openness and willingness to hear all sorts of opinions. That's not the Microsoft I remember...good for them. Clearly they are attempting to figure this out, along with the rest of us. I wish I could have stayed for Mix, which was occurring today through Wednesday, but I have a company to run now.

For further information on SPARK check out these blogs, and my Podcast.

Posted by Dave Linthicum on March 20, 2006 05:08 PM

March 19, 2006 | Comments: (0)

Notes from SPARK - Part 2

The rest of the day was just a discussion around "drivers to architecture." It;s funny how drivers are very much in the mind of the individual. For instance, there are a few guys here from MySpace.com who focus on the Web experience angle. Most of the discussion was around the next generation Web, or Web 2.0, and what drivers that's externalizing. I thought the discussion was too much Web focused, and really left the topic of core architecture, but that's okay.

Some common patterns:

• The next generation architectures have to be agile, change as the business changes.
• The next generation architectures blur the lines between enterprise architecture and the new Web, including services delivered over the Web.
• Users are empowered to drive change, more so than in the past.
• There will still be common needs, such as operations and security.

Things kick off today at 9:00 AM, strange way to spend a Sunday.

Posted by Dave Linthicum on March 19, 2006 06:50 AM

March 18, 2006 | Comments: (0)

Notes from SPARK - Part 1

At Microsoft's SPARK now, in Vegas. It's Saturday afternoon, and I'm working and blogging. Not much to report thus far, just introductions and coffee. There is an eclectic mix of people here, including end users, vendors, analysts, and of course Microsoft people. I was surprised to see a guy from Oracle here, but why not.

Looks like we're going to be developing a common view of architecture using more modern notions, such as Web 2.0, SOA, MashUps, etc. It will be interesting to see what comes out of all this, and if everyone can reach a consensus. Big brains in the room this weekend. I'll keep you up to date.

I hope to record some sound bites for the Podcast tonight, perhaps from the bar.

Posted by Dave Linthicum on March 18, 2006 03:38 PM

March 17, 2006 | Comments: (0)

Wrapping up the SOA Exec Forum

I had a great time speaking at the forum yesterday, including meeting the people I communicate with on line, but never get a chance to meet in person. Also, pretty much anybody who is anybody in the SOA world is moving on to SPARK this weekend...so I'll be spending the weekend with many of the same people. A little strange, but what the heck, as long as we don't have to shower together.

Here are a few observations from this event:

This thing is packed. If they were not sold out, they were approaching being sold out. Mostly architect types, IT leaders, project managers, and a few developers, which was a good mix of people.

Jeff Gleason of Transamerica Life Insurance's Keynote - Achieving Reusability with SOA, rocked. He really opened the doors to what these guys are working on, and told us about how SOA works, and does not work, within a key user organization.

People are getting smarter. After a year or two of trying to figure out SOA, people are much more sophisticated about the approaches and technologies. They are not looking for quick fixes, but practical ways to make this stuff work.

Vendors are happy. This market is moving forward, and their valuations are going up, as well as sales. In looking around the vendor room, however, I could not help but think about who would be next for acquisition. I think by the next conference 1 or 2 of the smaller guys will be owned by a larger player.

This is a fun and exciting space right now, this conference did a good job of pumping me up, again. I think the technology is growing, and the professionals in this area are first rate. I'm looking forward to the next few years.

Posted by Dave Linthicum on March 17, 2006 05:31 AM

March 16, 2006 | Comments: (0)

New Podcast Out There...Show 30! SOA and ROI Talk at SOA Exec Forum

Posted by Dave Linthicum on March 16, 2006 02:50 PM

March 16, 2006 | Comments: (0)

First Day of my Tour...At the SOA Executive Forum

First day of the tour today, and I'm in San Francisco at the InfoWorld SOA Executive Forum. I'm doing a SOA and ROI talk at 10:45 this morning. That's going to be an interesting topic for me, just wondering about the interest from the attendees. I'll let you know, and put the talk up as a Podcast.

Some of my initial thoughts are:

Not sure the "manage by magazine" guys care much about ROI now. They are just playing with the technology and following the hype. I don’t think these guys are going to be successful...at least they will be late, and way over budget. That is, if budgets actually exist inside these organizations.

The frugal guys, such as those in verticals like health care, retail, and education, will indeed consider ROI. They always consider ROI for the simple reason that they don't have the spare dollars not to. These guys will win a lot of little battles, and while not leading the way, will get a valid return on their SOA investment…eventually.

The strategy guys are the best guys in this space. They have money and are also thinking strategically about the use of SOA, including considering ROI. Truth-to-told, SOA needs to be lubricated with a lot of cash to get things going, but you should never spend the money without an equal understanding of the benefit. If you have the proper balance, you're SOA will be there, when you need it, and provide the ROI you’re looking for. I hope most of you are here.

Posted by Dave Linthicum on March 16, 2006 08:02 AM

March 13, 2006 | Comments: (0)

Thoughts on the Government and SOA

Not sure if you have much insight into the government marketplace for technology if you live outside of the DC area, but from where I sit (20 miles outside of DC), the US government push into SOA is full steam ahead.

Why? It's a matter of getting their own inter- and intra-organization systems integration ambitions moving forward, and what better way than under the flag of a new notion -- SOA. Indeed, I'm seeing more SOA activities within the government agencies than within the Global 2000 companies I'm dealing with. Good thing? Sure, as long as they define a clear plan of attack and make sure to do their homework.

The problem with the governmental problem domains is that they are not only complex and bureaucratic, but they are largely unknown to a single entity. They are spread out, and it's very difficult to find a single point of governance, or at least a point that has influence, and without that you have no chance of success. However, I am seeing some agencies, both civilian and military, address this issue today.

So, how do you win the SOA war within the government? Here are a few of my suggestions:

First, establish an entity within the organization that not only has clearly defined responsibility for building the SOA but the proper influence to get it done. You may want to do this at the department level, and then work your way up. Small battles win the war here, I've found.

Second, focus your technology analysis efforts in a single area. This means setting up a competency center where the technology can undergo testing and analysis, versus doing the testing for each organization or contract. This will save money and provide a better overall understanding of the technology.

Finally, established reuse and ROI guidelines. We are doing this for a reason, to save money and operate efficiently. Thus, let's set some goals that can are achievable by those implementing SOA, including return on investment. Not an easy thing to do, I know, but necessary if we are to justify additional investment.

Posted by Dave Linthicum on March 13, 2006 08:10 AM

March 11, 2006 | Comments: (0)

New Podcast Out There...Show 29

I risk life and limb, as well as the lives of other in getting this Podcast to you. I talk about the "ESB Thing" and SaaS integration considerations.

Posted by Dave Linthicum on March 11, 2006 04:54 AM

March 10, 2006 | Comments: (0)

SOA and ROI Talk Next Week and the Info World Conference

Just a reminder, I'm speaking at the Info World SOA conference next week, you can find the information here.

I'm excited about this talk, I'm speaking about SOA and ROI. A pretty controversial topic. Here are some blog thoughts on SOA and ROI, I hope you can make the talk.

We implement SOA for two major reasons. First is the ability to save development dollars through reuse of services. These services may have been built inside or outside of the company, and the more services that are reusable from system to system, the more ROI from our SOA. Second is the ability to change the IT infrastructure faster to adapt to changing needs of the business. This, of course, provides a huge strategic advantage and thus allows for the business to have better chances of survival long-term. While determining the ROI on agility is difficult to figure out in hard dollars, we know the value is there.

Reuse of Services

Under the concept of service reuse, we have a few things we need to determine to better define the value. These include:

• The number of services that are reusable.
• Complexity of the services.
• The degree of reuse from system to system.

The number of reusable services is the actual number of new services created, or, existing services abstracted, that are potentially reusable from system to system. The complexity of the services is the number of functions or object points that make up the service. We use traditional functions or object points as a common means of expressing complexity in terms of the types of behaviors the service offers. Finally, the degree of reuse from system to system is the number of times you actually reuse the services. We look at this number as a percentage.

Just because we abstract existing systems as services, or create services from scratch, that does not mean that they have value until they are reused by another system. In order to determine their value we must first determine the Number of Services that are available for Reuse (NSR), the Degree of Reuse (DR) from system to system, as well as the Complexity (C)of each service, as described above. The formula to determine value looks much like this:

Value = (NSR*DR) * C

Thus, if you have 100 services available for reuse (NSR=100), and the degree of reuse at 50 percent (DR=.50), and complexity of each service is, on average, at 300 function points, the value would look like this:

Value = (100*.5) * 300

Value = 15,000, in terms of reuse.

If you apply the same formula across domains, with consistent measurements of NSR, DR, and C, the relative value should be the resulting metrics. In other words, the amount of reuse directly translates into dollars saved. Also, keep in mind that we have to subtract the cost of implementing the services, or, creating the SOA, since that's the investment we made to obtain the value.

Moreover, the amount of money saved depends upon your development costs, which vary greatly from company to company. Typically, you should know what you’re paying for functions or object points, and thus it’s just a matter of multiplication to determine the amount of money we are saving by implementing a particular SOA.

Agility

Agility is a strategic advantage that is difficult to measure in hard dollars, but not impossible. We first need to determine a few things about the business, including:

• The degree of change over time.
• The ability to adapt to change.
• Relative value of change.

The degree of change over time is really the number of times over a particular period that the business reinvents itself to adapt to a market. Thus, why a paper production company may only have a degree of change of 5 percent over a 5 year period, a high technology company may have an 80 percent change over the same period.

The ability to adapt to change is a number that states the company's ability to react to the need for change over time. The notion being that the use of an SOA provides a better ability to change IT to adjust to needed changes in the business.

Finally, the relative value of change is the amount of money made as a direct result of changing the business. For instance, a retail organization's ability to establish a frequent buyer program to react to changing market expectations, and the resulting increases in revenue from making that change.

Determining an SOA's ROI is not an exact science, but with some analysis and some realistic data points, you can figure out how much value your SOA implementation has brought you, or will bring you. Again, we need to cost justify the use of this approach and technologies, and the information presented here should help you along the road to creating your own business case.

Posted by Dave Linthicum on March 10, 2006 06:15 AM

March 09, 2006 | Comments: (0)

Other Design Considerations

Of course there are other things you need to design into a service including management, and security.

You need to design a service with points of management to allow those that leverage the service to include it into their management infrastructure. Designing for management means designing and building points of management into the service, management APIs really, and define their usage to those that leverage the service.

Security is a bit more of a systemic design issue, meaning you need to define how your service is accessible and how you intend on authenticating users. Typically this means identity management facilities, but what’s most important is that you define the security parameters to those who are looking to leverage the service and that security is designed in.

Of course I can’t discuss all of the detailed design procedures one would employ in designing a service, but I think I’ve hit on the more obvious things here. What’s important is that you actually apply some fundamental software engineering and design principles here so you create a service that’s able to meet your needs the first time. Those who skip that step eventually have to return to it to fix or add to the service later, this interactive approach gets costly quick and only delays the delivery of the working service. So, always focus on the fundamentals.

Posted by Dave Linthicum on March 9, 2006 06:12 PM

March 08, 2006 | Comments: (0)

Checklist for Designing a Service

So, now that we understand the common design patterns we must follow, the question is how does one design a service? There are certain steps architects and developers can follow, here are some suggestions from me.

First, you need to define the purpose of the service. What the service will do, and who is the intended user.

Possible Artifact: Service Definition Document

Second, you need to determine the information to be bound to the service including both metadata and schemas. This means you need to understand how information is leveraged by the service, and what functions require what data. Typically services are storing information outside of themselves, thus you also need to design the mechanisms for accessing outside data sources. Moreover, you need to define data policies here including data validation constraints and dependencies.

Possible Artifact: Metadata and Schema Document

Third, you need to determine the functions (methods) encapsulated inside the service, in other words the behaviors you would like to expose. For instance, if our service checks inventory it may expose:

CheckInvenotoryOnHand(product_ID)
CheckInventoryReorderPoint(product_ID)
CheckInventoryOnOrder(product_ID)

It's also at this step where we define each function, including how the function breaks down using a traditional functional decomposition chart. This means that we define the higher level function by defining all lower level functions. Structure charts or decomposition diagrams are very helpful here.

Possible Artifact: Structure Chart

Forth, we need to define any interfaces into the service both machine and human. This means we need to determine how the service with interact with the calling applications, and through what mechanisms. While Web services define the mechanisms for both interface discovery and communications (e.g., WSDL and SOAP), we need to determine what those interfaces are and what they do. In many instances they map directly back to the functions, but not always.

Moreover, with the use of rich client interfaces in many instances you may be interacting with a human through a portal-type interface, you need to define that here as well, including design of the user interface.

Possible Artifact: API design, User Interface Design

Finally, we need to define how the service is to be tested. This is a very important but often neglected step where you define how those leveraging the service will test the service within the context of their usage pattern. You need to define test information, service invocation, and validity of results. Even performance profiling should be included in this step.

Possible Artifact: Test Plan

Posted by Dave Linthicum on March 8, 2006 06:09 PM

March 07, 2006 | Comments: (0)

Thoughts on Service Design

Software design has always been a focus for developers, but as we cycled through different approaches, standards, and architectures over the years, I think we’ve had a tendency not to pay enough attention to the fundamentals of software engineering. Clearly I've seen a decline in software quality because of this, not from a lack of programming talent, but a lack of upfront architecture and design. Skip this step and your service will cost much more to build and deploy, as you find yourself in an interactive death spiral that’s difficult to recover from.

With the movement towards SOA, and the use of services to assemble and integrate software, we have to pay particular attention to design.

First and foremost services should be designed for reuse. Services become of apart of any number of other applications, and thus must be designed to provide behavior and information, but not be application specific.

Services have to be designed for heterogeneity. Web services should be built so that there are no calls to native interfaces or platforms, this is due to the fact that a Web service, say built on Linux, may be leveraged by applications on Windows, Macs, even mainframes. Those that leverage your service should do so without regard for how it was created, and should be completely platform independent.

Posted by Dave Linthicum on March 7, 2006 06:05 PM

March 04, 2006 | Comments: (0)

Beware of SaaS Providers that don't Focus on Real-Time Integration

It's come to my attention that many of the SaaS providers out there, even the major ones, are not doing a good job in providing real-time integration services out of their network, nor are focused on real-time integration at all. This is bad, very bad.

So, why is real time integration important in the world of SaaS? It's a mechanism that will insure that corporate information placed inside the SaaS provider is able to sync up with corporate information existing within our enterprises. No brainer, but I'm finding that many SaaS users are not asking the right questions when it comes to SaaS integration, and thus end up having to suffer through the lack of integration, or dump the SaaS at some point in the future. Either option is very painful, and could cost hundreds of thousands of dollars.

Another issue is with those that confuse integration with migration.

Integration means that we have real time or near real time access to information, and can synchronize information as needed to support business processing. This can be both service-oriented, information-oriented, or both.

Migration means that during an instance of time they will move information in large batches from the SaaS to the enterprise system(s), or the other way around. Migration is never a good idea, you can't see the current instance of data, and data validity problem can occur, and almost always do.

The requirements for real time integration are easy to define, and you need to ask your SaaS provider the following questions before you sign on the dotted line:

1. Does your network provide an interface that will produce corporate information from the SaaS, and can I do this in real time?
2. Does your network provide access to all of my corporate information contained in the SaaS?
3. How do I select an integration solution to do this?
4. Who’s doing real time integration today with your network, and can I speak with them?
5. Who are you preferred integration technology vendors, and what solution are they offering?
6. Is your integration and SOA strategies documented, with predefined use cases?

Very simple questions, but you would be surprised at how many SaaS providers fail the most simple integration tests. Many have just not taken the time to think through the problem. I think that those who don't provide real time integration, both a technology and strategy, will not be the preferred SaaS providers going forward. Get with it guys.

Posted by Dave Linthicum on March 4, 2006 08:27 AM

March 01, 2006 | Comments: (0)

ESBs Get Knocked Again

It's no secret that I've been a bit suspicious of the whole notion of ESBs, for a few specific reasons.

1. What the heck is an ESB? Everyone has one, and they are all different. However, most are more like service-enabled message queues, if you ask me.
2. ESBs don't seem to be very service-oriented. Most just push information to and from systems, using Web services interfaces. That's not what service-oriented is. SOA is about sharing functional behavior as well as information, not just information.
3. They have a tendency to be leveraged as "good enough" and "to be replaced later" technology. Not sure that's the best approach.
4. I think they will muddy up the architecture issues a bit, making things even more complicated than they need to be.

Don't get me wrong, there are some great ESB products out there such as Sonic's stack. They do a good job in providing a pretty holistic set of features. My comments are really around the notion of an ESB, not specific vendors.

In Joe McKendrick's blog "Rage against the ESB machine," Joe talks to several thought leaders who are pushing back on ESB now.

"Depending on whom you’re talking to, ESBs could be messaging systems; they could be everything and anything."

and

"The vendors are all hot on ESBs, from BEA (AquaLogic) to IBM (with two, count 'em two, ESB offerings) to Sun (SeeBeyond), as well as pure-play SOA vendors. They obviously see a demand in the market for intermediaries. But, at the end of the day, are these just temporary workarounds for services built in a crummy" way?"

I believe these guys are correct. Ultimately it's those that consume the technology who will accept or reject ESBs. However, ESB are also just so confusing that it may slow the adoption of SOA in general. That's what scares me.

Posted by Dave Linthicum on March 1, 2006 07:20 PM

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