Real World SOA | David Linthicum | March 2007

MORE ENTRIES

March 2007

March 30, 2007 | Comments: (0)

Great SOA Video...SOA ROI

Posted by Dave Linthicum on March 30, 2007 05:20 PM

March 30, 2007 | Comments: (0)

SOA Vendors Need to go to SOA School

I ran across Joe McKendrick's blog post reporting on a fact that I've raised several timesâ€¦SOA vendors don't understand SOA, and it's frustrating end users.

"ZDNet's Steven Deare reports that the IT head of one large financial services firm says that despite pronouncements to the contrary, vendors don't seem to get â€” or maybe just don't want to get â€” SOA.

ING, which is three years into its services transformation strategy to integrate the systems of 20 companies it had acquired during this time, has been disappointed by lack of understanding from vendors, and their continued insistence on pushing their own proprietary software."

This is a huge issue in the adoption of SOA. In essence, vendors are pushing and hyping so much, that it's actually hindering the adoption of SOA. I hear this from my clients all of the time, and as much as I attempt to educate the vendors I work with, many are just not listening.

Here are a few things that vendors can do:

Understand SOA is a holistic change, and your product is only part of the solution.
Guide your users as to the value of your product within the context of SOAâ€¦don't sell "SOA in a box." There is no such thing.
Define your strategy, and make sure to understand the customer requirements before pushing your product.
Be prepared to walk away from deal where you're not a fit. You would be surprised how many of those customers invite you back when you are.
SOA is something you do, not something you buy.

There are some real issues here, and my larger concern is that the vendors, who don't understand SOA, will kill it as a concept before it has had a chance to prove its value within many organizations.

Posted by Dave Linthicum on March 30, 2007 04:53 AM

March 29, 2007 | Comments: (0)

Increased IT Spending Will Drive SOA Adoption in Asia

Clearly SOA is picking up steam outside of the USA. In some cases more so than the USA, and that's a matter of interest as the uptake in technology for non-US firms has always lagged that of the US in the past. Asia is no exception. In this article, CXO highlights that indeed Asia is ready for SOA, and adoption is occurring due to the increase in IT spending.

"The Asia Pacific SOA Readiness Survey is part of the IT Services & Applications subscription to include research in the following markets: SOA - vendor assessment, SOA - end-user assessment, hosted applications/software as a service (SaaS), enterprise software trends, and IT professional services.

IT spending among enterprises in the Asia-Pacific region is growing rapidly. The emergence of enterprise integration and a need for flexible business processes will trigger IT adoption, and drive demand for a service-oriented architecture (SOA) as a viable and popular option to achieve a viable IT infrastructure."

What's interesting here is that the Asia market has been traditionally very conservative when it comes to the adoption of new technology. Moreover, they seem to march to their own drummer. I remember in the days of Mercator, and how different the sales cycles are there, and the very different prioritiesâ€¦such as more focus on the long term outlook.

Clearly, they see SOA as something that can add longer term value to their company, and that's something they are always looking for in IT. US companies have a tendency to focus more on quick fixesâ€¦SOA is not a quick fix as I've been saying.

Posted by Dave Linthicum on March 29, 2007 04:39 AM

March 27, 2007 | Comments: (0)

What does SOA have to Learn from Traditional Enterprise Architecture? Tools

At the Enterprise Architecture Conference (EAC) this week in New Orleans, as I stated in my last posting. So, what are the trends here? Not a whole lot other than the fact that the traditional EA tools are continuing to move towards SOA, and they do indeed bring some value.

The fact is that SOA technology, typically development, integration, and governance tools, have charged way ahead of the approaches and methods that people need to leverage to get their SOA working for their enterprise. Thus, the hype has been leading the new SOA technology, and the new SOA technology has been leading any notion of common methodology, architecture, and design tools.

However, in the world of EA, architecture and design tools have been around for a while, typically coming up from the days of CASE technology gone by. These tools do a few things, typically allowing the architect to create and manage artifacts for the architecture and design process, leveraging a shared repository. The trouble is that the artifacts they were managing in the world of "old EA" (not my term, by the way) had little to do with the changing concepts that SOA brought to the table. In other words, you need a new approach to account for the differences.

However, all of that seems to be changing. Clearly, a trend at this conference is that the architecture and design tool vendors that lived in the world of traditional enterprise architecture, have moved, or are moving into the world of SOA. These tools include Telogic, Troux Technologies, and Agilense, at this conference. I'm sure there are a few more.

So, what's new? Not a whole lot at this point, however they are looking at the SOA model and artifacts that would be valuable within the world of SOA design automation infrastructure. This means service level understanding of the architecture, and binding to metadata, etc..

However, I did not get the feeling that this is comfortable territory for most of these guys, in other words it's going to be learning process. At the end of the day, this technology could be as important, or more important, than ESB, governance tools, and orchestration engines. None of that technology is worth a damm without a good set of requirements, architecture, and service level design. We need to begin to focus more on approaches, best practices, and methodologies, and the tools that can make that manageable.

Posted by Dave Linthicum on March 27, 2007 06:34 PM

March 26, 2007 | Comments: (0)

Embracing the Changing Nature of Enterprise Architecture

Off to New Orleans this week to speak at the Enterprise Architecture Conference.

Here is the description of my keynote:

"Enterprise Architecture is morphing into some new and exciting directions. With the advent of new concepts such as Web 2.0 and SOA, we have new opportunities to modernize our enterprise, and better align IT with business. However, there is much to be learned, and some of the existing approaches will have to change. So, how do you go about it? In this presentation I'll take you through the softer concepts of preparing for this shift, including: Having a better understanding of your own IT needs, understanding the real value beyond the SOA hype, understanding what changes need to take place, and planning for those changes including altering the skill sets, and the technology employed. Moreover, I'll provided you with a step-by-step proven approach for aligning your organization and enterprise architecture, with both the emerging needs of the business and embracing best-of-breed emerging technology and concepts. "

So, what's changing? In a world, everything. Truth-be-told many enterprise architectures out there are not pretty things, and as we become more aware of the inefficiencies of IT, there is more pressure on IT, as well as the enterprise architects, to become more agile in light of changing business requirements. Moreover, the layers upon layers of technology that have accumulated over the years need attention as well.

Thus, things are indeed changing. While SOA seems to be the battle cry for many in the enterprise today seeking change, in many cases the fundamental changes that are required are much more about the culture and the people, and less about the technology and the latest-greatest approach. In other words, we have to become savvier about what we do, and not what we buy. There is a huge difference.

It will be interesting to see my impressions from this conference. My sense is that guys like me, yelling about things such as process improvement, architecture normalization, and SOA, are getting more air time these days. That means that the message is at least getting out to those that should hear it.

I'll blog from the EAC conference this week, so stay tuned.

Posted by Dave Linthicum on March 26, 2007 01:01 PM

March 26, 2007 | Comments: (0)

AJAX and SOA...Where are the Links?

Download file

Posted by Dave Linthicum on March 26, 2007 12:37 PM

March 23, 2007 | Comments: (0)

Is your SOA Balanced?

SOAs are in essence distributed systems, meaning that the services are running all over the place, as are the data services, and persistence layers. As such many SOAs that I'm seeing deployed have a tendency to be out-of-balance or a disproportionate portion of the processing is taking place within a small group of services, and the others are not pulling their load. Thus, you may have the old 80/20 rule again, with 20 percent of the services handling 80 percent of the processing.

So, how did this happen? Many who create SOAs simple place services interfaces on existing processes and APIs and call it good, and don’t really understand what’s in those processes or opportunities for redesign to optimize the architecture. Thus, you just have lines of code that are repurposed as services, and little architectural thought goes into how all of those services work and play well together, and do so while sharing the load.

"Services balancing" is something we have not explored yet in the world of SOA because there are not that many SOAs yet, first of all, and performance is typically is an afterthought (so is security, as I'm finding, but that's for another blog). However, a few SOAs where performance is a concern, are finding that their SOAs are out of balance, and they have to move quickly to fix the issue to optimize their implementation.

So, what do you need to consider in terms of service balancing?

First, as the services are designed you should consider the overall balancing of processes between the services. Truth-be-told, sometimes you're stuck, and there is little you can do to move processing from one service to another. However, more often than not your services are "balanceable" and you should consider how the processes are distributed across services, as well as logical organization of those services.

Second, you should learn to create a performance model using the profiles of the services. While these are not foolproof, they do indeed provide a basis of understanding pertaining to the performance tradeoffs of your SOA. You would be surprised how much a little time invested in analysis will save your butt during implementation. Performance is clearly one of those things.

Posted by Dave Linthicum on March 23, 2007 05:21 AM

March 22, 2007 | Comments: (0)

"Best Practices for Your Enterprise SOA"

Ann Bednarz did a good job with this article "Best Practices for Your Enterprise SOA" which I was interviewed for some time ago.

"The benefits of the service-oriented architecture are widely touted: reduced integration costs, greater asset reuse, and the ability for I.T. to respond more quickly to changing business and regulatory requirements. But what about the pitfalls?
SOA pioneers know all too well the challenges that can arise when a company service-enables critical applications. The SOA endeavor spans I.T. disciplines: It's part systems design and architecture overhaul, part application development and business makeover."

The article goes on to discuss best practices as stated by SOA experts. Here are some of the highlights:

"2. Don't take interoperability for granted.
When Washington Group International began its SOA implementation three years ago, standards and tools weren't as mature as they are today. A key challenge was building Web services that could be consumed by both Java and Microsoft .Net clients, says Rich Colton, application integration manager at the Boise, Idaho, engineering and construction company."

While everyone assumes that there is some law that systems will interoperate, the reality is that many systems won’t work and play well together without a lot of work. Even with today's toolsets.

"3. Don't open your wallet too quickly.
When I.T. embarks on an SOA project, the first thing it often wants to do is buy new technology. But before committing to a technology platform, I.T. needs to identify all information sources and make sure it documents how each system defines data, says Dave Linthicum, CEO of SOA advisory firm Linthicum Group."

Seems like common sense to me, but the pre-requirement technology buys are still an issue out there.

"6. Budget realistically, or buy-in will suffer.
'People are hungry for information about how to budget for this stuff. The reality is, people don't understand the complexity of it, so they underestimate' cost, says Linthicum, who has devised guidelines for pricing SOA projects based on variables that include the number of data elements, the complexity of systems and processes, and new services needed."

Budgeting for SOA projects are not that difficult, just complex. There are approaches and formulas you can leverage that are logical. No need to approach these projects blindly.

Good thoughts, I'm thinking.

Posted by Dave Linthicum on March 22, 2007 04:57 AM

March 21, 2007 | Comments: (0)

Is AJAX Really the Face of SOA?

I'm at AJAX World this week in New York. In attending the cocktail parties and vendor functions I've been hearing the same pitch over and over again..."AJAX is the face of SOA."

So, is this true? Or, is this another "SOA 2.0" kind of a thing? A couple of things come to mind:

First, SOA does need a common user interface. One of things that are difficult when explaining the value of SOA is that there is no standard way to externalize the value of services, we instead do so using many eclectic ways depending on the needs of the problem domain. AJAX is built to work easily with Web services, and thus services that are exposed within the workings of a SOA are easily leveraged within an AJAX-enabled application.

Second, we may be over simplifying the problem. While it's easy to draw a lot of service and place a user interface on them, that's really not SOA. A SOA lives to provide an oderly and changeable interaction among systems, that's its primary role. Serving a user interface is clearly second. So, while I'm seeing a lot of AJAX user interfaces on SOA clouds this week, the fact is the value still resides in the cloud.

Hey, but when in Rome...Go AJAX!

Posted by Dave Linthicum on March 21, 2007 06:45 AM

March 20, 2007 | Comments: (0)

Managing SOA Semantics...Highlights and Comments

Download file

Posted by Dave Linthicum on March 20, 2007 04:40 AM

March 19, 2007 | Comments: (0)

Real World AJAX...Secrets of the Masters

I was pleased to see that the book Real World AJAX...Secrets of the Masters hit the streets this week. I just received my two copies in the mail, and my name was on the cover...ah...with 20 other guys.

At least my chapter is the sample chapter available for download. Either because it's great or because it's small...I suspect the later but I will think the former.

I never liked writing "gang books." I was involved with a few of them in the 90s including Windows Connectivity Secrets and Killer DOS Utilities. Killer DOS Utilities had a very cool picture of a shark on the cover and was about the size of an unabridged dictionary, library version. Anyway, when writing gang books you have a tendency to get lost in the shuffle. The next 5 books I wrote by myself, and 3 of them best sellers. I'm better as a solo act.

This book is different. First of all, 20 authors. My god. Dion Hinchcliffe, the editor, was the mastermind that brought all this together, and it's really a who's who in the world of AJAX today, including me, Mr. SOA/AJAX. Good job Dion, good job authors, great book that I hope you guys find time to read it.

Posted by Dave Linthicum on March 19, 2007 05:11 PM

March 16, 2007 | Comments: (0)

Managing SOA Semantics Using Ontologies and Supporting W3C Standards.... Audio and Presentation

Here is the presentation and audio from the Webinar. Enjoy.

Download file

Posted by Dave Linthicum on March 16, 2007 01:53 PM

March 16, 2007 | Comments: (0)

SOA and the Flu

I have the flu this week. No biggy, I'm never sick. So, when I get sick I don't feel too bad about it. However, I've had an opportunity to catch up on some reading, and think a bit more about a few SOA topics. Here are some thoughts:

One Size does not Fit All

One of the patterns that are beginning to emerge as I was catching up on my SOA reading was the notion that one technology will work for all SOA projects. Typically it's around ESB, but I'm not going to pick on the ESB guys here, also suite solutions from the larger players.

Truth-be-told as I'm working on SOA projects there is no hard and fast rule as to what technology will be the final solution. Indeed, the requirements need to be fully understood, and then you select the right technology for the job. While ESB are indicated some of the time as well as suite solutions, typically I'm finding that best-of-breed technology solutions are optimal. Meaning 3-6 vendor solutions that make up your final group of SOA products.

So, when I read "We are moving to an ESB" but don't hear "based on our requirements" chances are these guys are "managing by magazine" and not taking steps to define their own requirements. It's going to be expensive on the back-end to fix the issues.

Misuse of Governance

Governance is one of those notions that everyone is talking about, but nobody seems to understand what the heck it does. The vendors are part of the problem, the "governance" solutions out there vary wildly in terms of functionality and approach, and it's no wonder that those with real SOA requirements are confused.

I view governance as an layer of software that allows you to manage and control the use of services, including finding, securing, versioning, etc.. In some respects governance technology provides a great deal of value, but not in all cases. You have to select these tools with your own requirements in mind, as always, and I would say you approach them as if you don't need them, until you do.

I'm going to take something and go to bed. The virus that's got me is below.

Posted by Dave Linthicum on March 16, 2007 03:17 AM

March 14, 2007 | Comments: (0)

Is "Mashware" the New Thing for SOA and Mashups?

I typically do product briefings over the phone, or via WebEx. However, for those select few technology companies who are based in DC, I try to find time to get out to them in person. This was the case with JackBe, an Ajax-oriented start-up that has a lot of buzz around it. In essence, they Ajaxed before Ajaxing was cool.

JackBe is moving in some new directions. While they still offer a dynamic client, based on Ajax, and development tools, they are moving back towards the infrastructure as well. In short, providing middleware between the source systems and data which allow the user to mashup the services and information in anyway that makes them more productive. Why don't we call this "mashware" for now, see if it sticks?

While I was first taken back a bit by this approach, it really makes sense when considering mashups and SOA. Truth-be-told while driving a dynamic client has its value, the real trick is mixing and matching views of information, application behavior, and composites of both, and that's best put between the interface and the sources. In other words, JackBe provides a layer of processing to manage reusable mashups on the back-end, and thus provide more productivity on the front-end for the end user.

For instance, say you have a killer mashup for taking a stock feed service and mashing up with a RSS freed to correlate the rise of stock prices using the number of times a stock is mentioned in blogs. To build this, you need to manage the stock feed service; the RSS feed, and have the capabilities link both and add your own processing to make the correlations. The "mashware" would handle the feeds and the other interfaces, you would customize the view for yourself that makes the most sense for your own personal use. In short, each user would have the power to create their own applications that are right for each user. Can you say "agility and reuse?"

As mashups and SOA learn to get along better, and we learn that SOAs won't have the value without dynamic use; these types of approaches will make more sense going forward.

Posted by Dave Linthicum on March 14, 2007 05:07 AM

March 13, 2007 | Comments: (0)

Managing SOA Semantics Using Ontologies and Supporting W3C Standards...."Web 3.0?" Free Webinar

Just a reminder that I'm giving a free Webinar on:

Friday, March 16, 2007
2:00 PM - 3:00 PM EDT

You can register here.

When dealing with SOA, as you know by now, we are dealing with much complexity. The notion of ontologies and semantics helps the SOA architect prepare generalizations that make the problem domain more understandable. In contrast to abstraction, generalization ignores many of the details and ends up with general ideas. Therefore, when generalizing, we start with a collection of types and analyze commonalities to generalize them.

Clearly, semantic heterogeneity and divergence hinders the notion of generalization, and as commonalities of two entities are represented in semantically different ways, the differences are more difficult to see. Thus, ontological analysis clears the ground for generalization, making the properties of the entities much more clear. Indeed, ontological analysis for SOA encourages generalization.

In this session we take the mystery out of the use of Ontologies, providing the attendee with a step-by-step approach to the use of Ontologies and Supporting W3C standards.

Posted by Dave Linthicum on March 13, 2007 08:21 AM

March 13, 2007 | Comments: (0)

ZapThink and I Talk about the Federal Enterprise Architecture and SOA

Download file

Posted by Dave Linthicum on March 13, 2007 04:58 AM

March 12, 2007 | Comments: (0)

Spotting the Good, and Bad, SOA Technology Vendors

As I'm working SOA projects these days I'm exposed to a number of SOA vendors...big, small, niche, and stack players. While doing this work I'm beginning to recognize some emerging patterns in spotting SOA vendor capabilities. Some of these patterns are good, some bad, some disturbing. Here are a few:

First, they know where they play. When considering the complexity of SOA, and the complexity of the problems they are solving, saying that you're "one stop shopping" is a bit of a clue that you really don't understand the notion of SOA, or your customer's issues. Indeed, effective SOA vendors first listen to the issues, understand the problem domain in detail, and then suggest where they fit, or not. In essence, providing a realistic look at the pain points of the client organization, understand how SOA is applied and the potential value it brings, and exactly where they fit in the proposed solution.

Second, they know what they are talking about. The largest problem is the lack of expertise when it comes to SOA, and many of the solution engineers and sales people who show up on site do not have a working understanding of SOA, and typically need to work exclusively from sales presentations and sales brochures. If they don't understand SOA, and the potential value, they won't be able to understand the problems at hand, nor how their technology fits into a viable solution. I've sent a few of those guys out the door feeling a bit stupid, but gezzzzz, when you're selling a car, understand not only how to drive that car, but the road network and traffic laws.

Third, be willing to move quickly to a POC pre-deal. Got good technology? Prove it. Vendors that are looking to demonstrate their technology beyond the demo-ware are on the top of the list as far as I'm concerned. It tells me that their stuff most likely works well and they are excited about sharing it with you. You would be surprised at how much technology is still half-baked, and verification is the rule these days.

Finally, they accept the fact that everyone is still learning. SOA, hype-wise is widespread. SOA, implementation-wise is not. Thus, we are still attempting to close the gap on what we think will work, and what actually does work, thus it's going to be a learning process for the next few years. Accepting that, SOA vendors need to be constantly reinventing their approaches and technologies, understanding that the game will change as we all become better at SOA. Admitting that does not take away from your creditability, it adds to it.

The funny thing is that all of the vendors that read this blog, and there are about 100+ at last count, will think that they are in the "good column." Unfortunately, a good number are not. Time to become self aware, and move to correct any of these issues before your customers read this blog, or you're sitting across the table from me.

Posted by Dave Linthicum on March 12, 2007 06:33 PM

March 09, 2007 | Comments: (0)

AJAX and SOA...Together Forever?

The week after next I'm speaking at AJAX World, and thus have been thinking a lot about AJAX and SOA. Also, just coauthored a book on AJAX, and yes I did the SOA Chapter.

AJAX is becoming the standard dynamic interface for the Web. AJAX adds value to SOA as well, providing the core-enabling technology for user interaction, no matter if we're dealing with applications that are remotely hosted, or applications that are local to the enterprise.

In essence, AJAX provides better edge technology for SOAs, or the top layer of technology dealing with the user interface. To this point, AJAX is able to extend visual service to a true interactive dynamic interface that's more attractive and functional for the end user.

The benefits of AJAX to the enterprise are clear, including:

The ability to leverage the same interface technology no matter if you’re dealing with local or remote sites or applications. What's key about AJAX is that many enterprises can agree that it's the standard interface technology, and as such, standardize on AJAX as the common user interface that's platform agnostic. Thus, it matters not if the AJAX interface is delivered on Windows, Linux, and / or the Mac. This makes deploying service-oriented enterprise applications that much easier, avoiding platform localization and testing issues.

The ability to leverage Web services using a more dynamic and rich interface than traditional browser technology. While the browser is functional for Web-based applications, the lack of interactive and dynamic behavior makes its use within the enterprise limiting. AJAX does not use the same "pump and pull" model that traditional HTTP-driven browser-based applications leverage. AJAX provides native-like application interfaces and performance, functioning as good as, or better than native interface APIs, such as Win32.

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. AJAX provides better enabling technology to facilitate the creation of mashups, combining dynamic applications into a single interface with additional binding logic. Using this paradigm, enterprises can quickly create such useful mashups as integrating Google Maps with their delivery system.

AJAX has so much momentum behind it now that there is no stopping it's layering into the enterprise and SOA. SOA will leverage AJAX, and should leverage AJAX. But, as always, it's a matter of architecture.

Posted by Dave Linthicum on March 9, 2007 04:48 AM

March 09, 2007 | Comments: (0)

AJAX and SOA...Together Forever?

The week after next I'm speaking at AJAX World, and thus have been thinking a lot about AJAX and SOA. Also, just coauthored a book on AJAX, and yes I did the SOA Chapter.

The benefits of AJAX to the enterprise and SOA are clear, including:

The ability to leverage the same interface technology no matter if you’re dealing with local or remote sites or applications. What's key about AJAX is that many enterprises can agree that it's the standard interface technology, and as such, standardize on AJAX as the common user interface that’s platform agnostic. Thus, it matters not if the AJAX interface is delivered on Windows, Linux, and / or the Mac. This makes deploying service-oriented enterprise applications that much easier, avoiding platform localization and testing issues.

AJAX has so much momentum behind it now that there is no stopping it's layering into the enterprise. SOA will leverage AJAX, and should leverage AJAX. But, as always, it's a matter of architecture.

Posted by Dave Linthicum on March 9, 2007 04:43 AM

March 08, 2007 | Comments: (0)

"My SOA is Bigger than Your SOA"

Lately I've noticed a lot of SOA envy as organizations begin to roll out their new, and typically first, SOA projects. I hear things like: "How many services you got in your SOA?" or "We employ 10 WS-* standards, you?"

Not sure I get all that, I mean the success of any SOA is really its ability to live up to the business expectations set. Here are a few ways that others are measuring SOA, and the realities:

Services Under Management - Or, the number of services that a SOA will manage, abstract, orchestrate, and govern. While you can certainly have an impressive number of services, the size and complexity of your SOA really depends on the size and complexity of your services. Thus, the number of services really has little to do with the amount of work it took to develop or abstract those services or the value those services bring to the SOA. So, number of services at the very least, is a primitive metric.

Standards Employed - There has been so much of a push to use standards that I often hear SOAs measured in the number of standards they employ. While standards are a good thing, the use of standards really has little to do with the success of a SOA, indeed I'm finding in my practice that those who insist on using too many standards may actually scuttle their projects in an attempt to adapt to any number of standards, some not baked yet or in conflict with other standards. I don’t think this is a good metric at all.

So, what's the best way to measure you SOA?

First, how effective is your SOA considering solving the stated business problems? Your SOA should provide agility witch means you business runs better, you make customers happier, or you enter new markets expeditiously. You should be able to demonstrate the value there easily. This is the best way to measure.

Second, how much development is avoided, or how much reuse? What is the number of services that are leveraged in more than one place within your architecture? That number should tell you how much development has been avoided. Considering development costs, you should be able to put a number on that. This is the second best way to measure.

It's not rocket science to measure the success of your SOA. However, we seem to pull out illogical concepts when we look at the size of something. At the end of the day, SOA is not about "number of services," or "standards employed," it's about being an effective business solution...albeit that's not as much fun.

size matters.jpg

Posted by Dave Linthicum on March 8, 2007 05:05 AM

March 06, 2007 | Comments: (0)

Burton Report Considers Limitations of BPEL

According to this article, those considering SOA may have some tough choices when it comes to driving code at the process layer. Indeed, a report by the Burton Group describes both the limitations of BPEL, and the advantages of WS-CDL.

"Business Process Execution Language (BPEL) is the standard developers must use for Web services orchestration, but it is a limited standard and will eventually be subordinated to Web Services Choreography Description Language (WS-CDL), argues Chris Howard, the Burton vice president who authored the report."
"BPEL's limitations are covered at length in Howard's detailed report, "Crossing the Divide: The Mechanics of Process Execution."

One of the most interesting things in the report:

"For the process execution component of business process management (BPM), he notes that BPEL has vendor support in tooling for Web services orchestration. But one of the limitations he mentions is that even in the updated BPEL 2.0 standard, which is expected to be finalized by OASIS this summer, 'it still performs orchestration from the perspective of a single service.' This is not adequate for maturing SOA implementations requiring choreography of multiple services, he argues."

Last year I pointed out the limitation of BPEL 2.0, including the issues mentioned the Burton report. The truth of the matter is that WS-CDL is not perfect, but in comparing the standards, the limitations of BPEL 2.0 are apparent. So apparent that I don’t understand why those creating the standard don't step up and fix them considering that BPEL is the standard that I deal with the most in my practice. Also, the standards that most of the vendors employ.

Once again, we have Beta and VHS decisions to make, or should I say Hi Def DVD or BluRay. I know that one won't be around after a few years.

Posted by Dave Linthicum on March 6, 2007 06:35 AM

March 06, 2007 | Comments: (0)

If you Understand SOA, You're Golden

Download file

Posted by Dave Linthicum on March 6, 2007 06:14 AM

March 03, 2007 | Comments: (0)

Funny SOA Video

I got a kick out of this, hope you will as well.

Posted by Dave Linthicum on March 3, 2007 04:34 AM

March 02, 2007 | Comments: (0)

SOA as a SaaS...What to Plan For

I've been working with a number of clients that use outside-in services, or services that are hosted remotely, but leveraged within one or many internal systems. Typically this is around some ad-hoc business driver, such as using a remote services for B2B or access to vertical applications, such as those leveraged by finance, healthcare, and retail.

So, I've been thinking a bit about how you become a services provider, or SOA as a SaaS...an organization that stands up Web services for consumption by others. As the trend to share services continues, you'll find that many of you are put into this position, as SOAs learn to reach across the Internet and touch each other.

Those that design and post services will have to understand a few basic principles, they are:

1. Focus on granular services that are part of a holistic solution.
2. Consider many service externalizations scenarios.
3. Track usage.
4. Quality in the design.

Focus on granular services that are part of a holistic solution means that you consider the problem you're solving, versus just the service you're implementing. Moreover, you're willing to provide many services that together will solve a business problem, but at their instance solve a tactical problem.

Consider many service externalizations scenarios means that you're building a service that may be externalized to humans or other computer systems through a variety of interfaces. In essence you're interface agnostic, understanding that the value of the service will need to be realized within a variety of systems, all having different looks and feels.

Track usage. Not to be too big brother, but it's nice to know who's using the service and where.

Quality in the design. If you're going to provide services for others you need to understand the quality of that service needs to be impeccable. In essence you're becoming part of an application that's unknown to you, thus you need to design that into the service as well as test the service, more so than any application. Not doing so means you'll be disruptive to those using your service, and your service won't add value, thus won't be used.

Posted by Dave Linthicum on March 2, 2007 05:34 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