SOA certification program launched

Just saw this article on the CNN/Money website.

IBM Federal SOA Institute Launches IT Certification Program: IBM today announced the first Service Oriented Architecture (SOA) certification and training program for Federal IT professionals. The program was established to provide knowledge, and share important skill sets needed, for SOA development and adoption.

The 12-week certification program is sponsored by the IBM Federal SOA Institute, and will begin September 12th through December 4th. A second series is scheduled for Spring 2008.

Two distinct course tracks are available: an entry level curriculum in order to become a certified SOA Associate, intended for those who are new to SOA concepts and would like to increase their overall understanding; and an advanced curriculum, to become a certified SOA Solution Designer, structured for senior IT professionals who require enhanced knowledge to deploy SOA capabilities within their organization.

Certification modules cover issues such as the value of SOA, determining return on investment, bridging the gap between technical and business teams, basic architecture, establishing solutions using existing assets and new components, identifying barriers to adoption, preparing for governance issues, and effective deployment and management within an organization.

More...

Web Services performance through the years

On my travels I get asked the simple question many times ... "are web services fast"?

I usually answer by showing the above graphic. Back when I started on Web Services in 2002, the answer was no. As you can see over 5 years, the answer has definitely changed to "it depends".

I say "it depends" with a little sarcasm. Obviously the performance shown in this chart tells you web services performs. However, in practice I find misuses of performance data and/or web services.

The first thing to be wary of is people trying to prove web services aren't viable are folks using "Hello World" string in/string out web services compared to legacy communication protocol xyz. I usually ask such folks how many distributed services in their architecture are string in string out with such small payloads. The answer is none. Usually the service uses complex industry standard schemas and has a small payload in with a large payload out. The above graph therefore is based on a 3k input document using banking industry standard schemas with a 10k output document.

The second thing to be wary of is primitive web services testing. The above graph is an example of primitive web services testing. This is because my team works on optimizing web services. It shows very clearly the impact of web services calling services that have zero business logic. If we optimize the performance of this primitive we will help in all scenario using web services. However, for customers you need to understand that when you add business logic, the performance impact of web services is far less of a concern. To accurately gauge performance impacts of web services in your application, I would suggest a measuring a vertical slice of your entire application, starting at the web service interface, then calling business logic, and finally any database logic. Comparing that vertical slice between web services and legacy communication protocol xyz is a useful comparison.

Lastly, don't replace every legacy communication protocol xyz in every application with web services. Web Services has been documented by almost every vendor to be useful when the service calls are coarse grained. Replacing "services" with calls that are under 1k of input with 1k of output (example a string in, a simple bean out) isn't usually a good idea. Reusable services in a SOA (for example) are typically much larger in payloads as they tend to be calling services that are not fine grained in payload or function.

Now, you may be asking two questions ...

1) How did we improve the performance over the years
2) What is the performance story for 2007 and the new Web Services Feature Pack?

I think those are two good posts to add in the next week or two ...

TCs created at OASIS for SCA

Well, not the timeliest blog ever, but I did want to mention to folks if they hadn't heard yet that the SCA architecture established by the OSOA organization has been accepted by OASIS for standardization and technical communities within the Open Composite Services Architecture Member Section as documented here.

This is the result of a lot of effort from my colleagues from IBM as well as contributors from the many vendors that comprise the OSOA organization. I look forward to the enrichment of a standards process to refining this technology into the valuable, open, multilingual SOA architecture we envisioned several years ago. Great progress!! and evidence that while this technology is not rolling out as fast as some of us would like, the value proposition and promise remains strong.

Obligatory First Post from Andrew Spyker

Terry invited me to join the community. I plan to get busy posting as much as I can, but I thought I'd start with an intro post. Someone beat me with a stick if I don't post within a week with real content.

I have been with IBM WebSphere Application Server for the past five years as a lead of our performance team. My time in performance has given me time to focus on many things - J2EE, Java, Security, Web Services, and more recently all things relating to our SOA foundation. Earlier this year I was promoted to STSM (Senior Technical Staff Member) and asked to broaden this focus more formally as a SOA Runtime Architect. This means I get to focus on more than performance (which I have traditionally done since performance allows you to experience all aspects of the product end-to-end) and more than WAS (ie. the rest of the SOA foundation). My focus as of late is how we can drive our XML strategy forward in both function and performance given XML is one of the core building blocks of all of our SOA runtimes. Also, I still advise the team I've built in WAS performance on daily basis. More on all of that later.

So in the end you should see a mix of content on XML, SOA, and performance from me.

WS-AT interop between WAS and WCF

Anyone who has ever tried to set up interoperable WS-AtomcTransaction interop between WAS and WCF will know its easy once you have figured out how to configure the WS-AT service endpoints in both systems to use SSL with mutual certificate authentication. If you haven't got that far yet and don't want to have to figure this out for yourself, read Billy Lo's paper on Building transactional Web services with WebSphere Application Server and Microsoft .NET using WS-AtomicTransaction

Coping with the internet crash

Breaking News: All Online Data Lost After Internet Crash

We kept telling folks to migrate the internet from those two 386 boxes in the basement in Champaign-Urbana to z/OS on the mainframe, but did they listen? No.

Slightly off-topic: IBM visionary retires

Darryl Taft over at eWeek has an article about and interview with IBM's Irving Wladawsky-Berger, who is retiring after 37 years with IBM. This is slightly off-topic because Wladawsky-Berger isn't a WebSphere guy, but I thought the article and interview were interesting nonetheless. He's obviously had an varied career and been involved in a bunch of key IBM initiatives. That's one of the things I like most about IBM - there's no shortage of diversity when it comes to interesting things to work on. Full disclosure: I've never met Wladawsky-Berger.

Article about Irving

Interview with Irving

WAS V6.1 - Web Services Feature Pack is available

Quick note - the Web Service Feature Pack for WAS V6.1 that has been mentioned here before as a beta product is now complete and available - the announcement is here.

EJB3 Beta program

The EJB3 feature pack for WAS V6.1 is now entering beta, and can be downloaded from IBM's Early Program site.

I've mentioned the Web Services feature pack below. As you'd expect, the EJB3 feature pack follows the same idea - an optionally installable add-on that provides support for EJB3 applications.

Project Zero site is live

IBM's new incubator project named "Project Zero" is now up and running. Like the Jazz project, Project Zero is another IBM foray into "Community Driven Commercial Development". CD/CD is basically an open way of developing software that is intended to be sold. It's an interesting mix of open source style processes with standard commercial practices. I think it has a future. As for Project Zero itself, it's essentially a Web 2.0 mashup platform that tries to address enterprise-level mashup needs in a simple way. Check it out.

Progressive Leakiness

One of the things that has been popping into my mind recently is centered around the notion that all abstractions are leaky in the sense that no abstraction can actually completely hide the layers for what its built on. Joel Spolsky penned "the Law of Leaky Abstractions" which basically states that all abstractions leak through aspects of the layers for which they are built on, and therefore the user of the abstraction winds up being exposed to more complexity than otherwise necessary and/or originally intended. It is interesting in reading some of the internet material that has been published around the subject of leaky abstractions in that folks have extended the notion beyond computer science into the world of physics and even other disciplines like philosophy, etc.

I wonder if when building a good abstraction, you should just acknowledge that all abstractions will be leaky and design-in the leakiness. In this pursuit, we should use the laws of Progressive Disclosure whereby the user of an interface or software is only exposed those concepts which are minimally required to accomplish the desired task. I highly subscribe to the usefulness of progressive disclosure techniques, as they tend to keep simple stuff simple and can make learning a new thing easier.

One of the painful things about abstractions is they sometimes get in your way -- a good abstraction can step aside for situations like this. An excellent example of leaky abstractions and progressive disclosure techniques that I can think of that meld very well is in the area of computer language compilers: some of the better ones expose a way for the programmer to "drop down" into assembler, right in the middle of their higher-level language constructs, and allow the programmer to tailor the code specifically for a given hardware device. This capability of drop down allows the programmer to cope with, in a very natural way, leaks like: new instructions that the higher level language (i.e. the abstraction) has not been built to specifically exploit, or even something as tailoring specific condition codes that can arise on newer hardware that need to be handled for correct code behavior. This concept demonstrates good "Progressive Leakiness" in that most programmers get the 100% value of the language abstraction not needing to be exposed to the more complex assembler language techniques (progressive disclosure) but permits specific situations to be coded for which could not be handled by the abstraction or wind up causing the abstraction to misbehave (leaky abstraction).

It seems to me that SCA might be a good candidate for a Progressive Leakiness focus. I could envision casting an SCA Reference to a JAX-WS, for instance, to do specific Web Service stuff that would not otherwise be available or even maybe appropriate through the SCA abstraction.

I don't know, maybe wrong -- I could be in need of a vacation too, I can't tell....

Web 2.0 at WebSphere Portal Technical Conference 2007

For the next release of WebSphere Portal, we are working on on exciting new Web 2.0 function, including AJAX based client side aggregation, navigation and customization, AJAX based feed aggregation, AJAX proxy capability, support of semantic tags and semantic tag based context menus, Atom/APP based access to portal data and portlet programming model extensions to allow easy access to portal data exposed via Atom/APP from JavaScript embedded in portlet markup.

Apart from the new Web 2.0 technology added to WebSphere Portal, Lotus has Web 2.0 applications under development for collaboration and social networking: Lotus Quickr and Lotus Connections which can both be integrated with WebSphere Portal. This allows to use the portal as a central entry point providing the right content, information, processes and applications to the right people at the right time and links to and integrates with the collaboration and social networking capabilities provoided by Lotus Quickr and Lotus Connections.

These new Web 2.0 capabilities will be featured in presentations at the WebSphere Portal Technical Conference 2007 in Munich, from September 10th-12th.

The event focuses on WebSphere Portal based solutions and is organized to provide IBM customers, business partners and colleagues with latest technical and strategy directions for IBM WebSphere® Portal Version 6.0.x and Lotus technologies, including extended support for Web 2.0 services, performance enhancements and new IBM Accelerator solutions that help customers to easily create a variety of SOA based composite applications, enabling faster deployment and user productivity.

Using Spring with WAS and WAS ND

Interface21, the company behind Spring, announced in June 2007 that it has certified and will support WAS as a deployment platform for the Spring application framework. This is as a result of a collaborative effort between Interface21 and IBM to test - on all WAS platforms - a number of scenarios that use Spring with WAS. There's also an interview, on developerWorks, between IBM's Paul Buck and Interface21's Rod Johnson, discussing the impact of this effort.

One of the results of this collaborative effort is an update to the paper on developerWorks that describes some of the best practices for using Spring with WAS. For example, this illustrates how Spring's declarative transaction demarcation is configured for WAS and how data sources should be declared in a Spring application context definition for injection into a transactional application.

A quick glance over at Rational

Yeah, this is a WebSphere blog, but I thought this eWeek Rational article would be of interest to WebSpherians as well. It's an interview with Rational's Lee Nackman about Jazz.

Honestly, I thought the questions left a lot to be desired, as if the interviewer had not done their homework before talking to Nackman (like "When will Jazz be done?", which is like asking "When will Eclipse be done?"). In spite of the questions, there's some interesting tidbits in there. For example:

Question: You said Jazz is like a middleware layer for building collaborative tools. Can you expand on that?

Answer: The way that I like to think of it is that the Jazz platform provides a middleware layer for software development and delivery. And so the way that that's related to the ESB idea is things happen and notifications need to happen. So somebody might create some sort of a work item, and somebody might be subscribed to a feed for those kinds of work items. And how does that get transported? The nice thing for us that there is so much good collaboration technology, things like RSS feeds, that exist now that we can just exploit.

Sounds like an interesting project.

Simple Ajax

I've been at a couple of conferences recently, and one of the hot topics that everyone is talking about is "Web 2.0". The great thing about these cool buzzwords is that they mean different things to everyone - but "Web 2.0" generally implies web sites that provide a richer, more interactive experience. In turn, one of the technologies that is used to provide this experience is Ajax (Asynchronous Javascript and XML). Ajax is not new, the technologies have actually been around for many years, but the pattern has recently been popularized by modern browsers and high profile applications such as Google Maps, GMail, etc.

AJAX is not a framework or library, it is an application pattern (although many frameworks are emerging to help, such as Dojo). An Ajax enabled page uses Javascript to send an XML request to call back to the server, the server asynchronously completes the request and sends back results, and then more Javascript in the page updates some parts of the page (rather than refreshing the entire page).

The problem is that developing AJAX based applications is hard - it requires writing complex Javascript and DHTML, and the asynchronous nature of the pattern further complicates debugging. There are also a series of other problems that have solutions - but are easier to get wrong, than they are to get right: Making the browser's 'back' button work is tough; Javascript has a tendency to leak memory; you must test your code on many browser variants, etc. As noted, frameworks that will help are starting to emerge, most notably Dojo - but they are still immature, and still require that you write JavaScript code in your page.

WebSphere and RAD have supported JSF (Java Server Faces) based applications for several releases now, and the combination of JSF and the JWL component library we ship offers a powerful combination that simplifies the development of applications. What's new is that RAD v7 has introduced some common AJAX behaviors into our JSF component library; you can now provide capabilities such as scrolling data tables with no page refresh, dynamic menus, and entry fields that support type ahead. The nice part is that none of this function requires you (the developer) to write any JavaScript - the bulk of the function is encapsulated in the JWL component library, and the tiny snippets that are required can be generated for you by RAD. In turn, this means you get to avoid most of the problems listed above - but still provide the enhanced interaction that people are starting to expect from modern web pages.

JSF based pages can co-exist quite happily with "normal" JSP and HTML pages, so there is no requirement for you to make a huge investment and redo your entire site. Instead, you can update just the pages that you wish to modernize, and provide the basic interaction patterns that are the hallmark of "Web 2.0". There are several resources available to help you understand the new capabilities, but a couple of articles on developer works provide a good starting point. The first one is "JSF and Ajax: Web 2.0 application made easy" and provides a general overview, and a second article titled "Improve the usability of Web applications with type-ahead input fields" walks you through adding typeahead to a JSF based page.

As Ajax continues to mature, frameworks such as Dojo will continue to add value to the development of advanced web pages - but the capability that's available in RAD v7 and WAS 6.1 today is more than enough to allow you to provide your customers with a modern, interactive site, without forcing your developers to go through a painful development process.

Tim Francis

Multi-Cores, SOA, SCA and the Incredible Lightness of Being

I received a link from a colleague regarding a recent article "SCA applies SOA principles to Apps Design" by Andy Dornan. The article starts off with a slant that SCA enables runtimes to take advantage of multi-core CPUs; further implying that while Moore's law still is applicable for making the processors themselves faster, that the real leverage in software gains comes from building applications that can have multi-core processors thrown at them. He theorizes that in order to really leverage the multi-core processor future, that applications must be broken up into small loosely-coupled components. And this was just the first paragraph.

Whoa. Where to start. I can say the article made me think, does SOA, or SCA for that matter really help applications deal with multi-core processors? Far be it for me to criticize semantic English, but multi-core processors imply same-box, and the focus of SOA and SCA relate to the wider, distributed network; which may be comprised of multi-core processor nodes. Certainly SOA does help application developers in arriving at application patterns and best practices that lend themselves to being advantaged by multi-core processors, or even more importantly a set of distributed processes and processors. Simply using container-based applications like JEE or even Spring put the majority of the burden of thread management in the hands of the middleware, where presumably there are appropriate controls and exploitation of multi-core processors have been meticulously built; that really doesn't have much to do with SOA or SCA. Billy Newport has blogged numerous times about applications and multi-core issues as well. While there has been lots of research in predictive instruction execution and pipelining, SCA offers more like a circuit board assembly than a flow chart (perhaps like BPEL) and its model doesn't really imply any ordering or sequencing which would afford any great advance in multi-tasking. Certainly SCA has asynchronous invocation concepts which would allow for a greater opportunity for muli-tasking, but I would hardly say they are transparent to the application.

To cut Andy a break, perhaps what he intends to say is the SOA and SCA programming style of providing declarative dependencies and policies allow the runtimes to better understand the application and therefore, de facto have a better chance of exploiting the hardware available to solve the problem.

The article then diverges into other topic areas for which I also have some comments.

• Java is certainly an important language for SCA to embrace and to treat in a first class manner, but it is hardly the only language. Certainly at least BEA and IBM and keenly interested in SCA assemblies with BPEL implementations, but there is lots of activity in other languages. Of course WebSphere is going to focus on Java -- it is a Java runtime. What will be interesting is how vendors choose to slice and dice the type of component implementations they support and in what form factor they will deliver that support.
  
• I didn't quite understand his comments about requiring a higher-level intermediary to embrace WCF components. Certainly WCF components can consume or be exposed as Web Services, using WSDL and XML for interface definitions -- SCA embraces both service consumers and providers. Perhaps I'm missing some other point Andy is trying to make. Certainly, as I've blogged about before, SCA embraces existing (legacy) technology and I don't understand why anything would have to be rewritten. This seems just wrong to me.
  
• I don't agree with the statement that the vendors believe SCA is needed to achieve "tru(e) platform independence." What SCA allows you to do is to compose and assemble applications written in a variety of implementation languages, hosted on a variety of platforms and insulates the business logic developer from having to have unnecessary knowledge of these implementations.
• Microsoft is not interested in application portability, so certainly aspects of SCA are not interesting to them; however, the author does seem to be unaware that SCA, albeit in its original proprietary, has been shipping in WebSphere Process Server 6.0 for some time now.
• Service Data Object is not an optional subset of SCA. SDO is orthogonal to SCA, but is rather complementary... to be honest, I just don't know what Andy was trying to articulate in his closing paragraph about SDO.

At the end of the day, I suppose its nice to see some articles coming out regarding SCA.... even if the ideas in the articles, I can't get my head around.

Integration of Google Gadgets in WebSphere Portal

Since a while, we have worked together with Google to create a generic portlet called "IBM Portlet for Google Gadgets" in order to easily and seamlessly integrate any Google Gadget into WebSphere Portal. We first mentioned and demoed this new integration capability at Lotusphere 2007, issued a press release more recently, and subsequently presented this new capability for WebSphere Portal at IBM Impact 2007.

The IBM Portlet for Google Gadgets is available for WebSphere Portal customers to download from here: http://catalog.lotus.com/portal?NavCode=1WP1001AJ

It allows portal administrators or users to easily select which Google Gadgets they want to integrate in portal pages using an AJAX-based user interface giving access to Google's gadget catalog. The selected gadget is then displayed on the page exactly like any local portlet and can be customized by end users like any local portlet, i.e. for end users, the integration of Google Gadgets in WebSphere Portal is seamless.

More information on this topic can be found here.

"My Tasks" in WAS V6.1

Here's a handy little feature in WebSphere Application Server V6.1: "My Tasks" in the console. In a nutshell, it allows you to quickly customize your console navigation to only include the navigation options that you care about. You start by selecting "My Tasks" as your view:









Assuming you've never been here before, it prompts you to add your first task. Clicking that options gives you a lit of navigation options. You can either choose an entire category (like "Applications") or a sub-category (like "Secure administration, applications, and infrastructure"):



















After clicking Apply, voila! You now have a customized navigation that only shows what you care about.

It's a Dessert Topping AND a Floor Wax

There has been some recent blogging about general confusion on whether or not SCA constitutes a new programming model or not; for instance Dave Chappell blogs here, Mike Rowley of BEA here, and Sanjay Patil of SAP here.

Of course SCA defines a new programming model, however, it also specifically defines an invocation model, a component model, and an SOA assembly model which embraces other, non-SCA programming models. Blur in the fact that the term "programming model" has specific language connotations (at least in my mind), while SCA and its cousin SDO were designed to be specifically language neutral.

What we need for building SOA applications is a contract to describe dependencies, policies and implementation with as little knowledge of or need to impact existing business logic. It needs to lift us out of the computer science goo and into building business logic that is meaningful to the business.

The fact that one can or cannot use SCA with or without another container, or as a client with any at all is less important in my mind as the importance of its design points of separation of concerns and insulating the business logic from specific protocol and data bindings which lead to fragile, inflexible applications.

Steve Kinder

IBM WSRP Producer for IBM WebSphere Application Server

Recently, I heard from my colleagues Richard Jacob and Joachim Loeffel that the IBM WSRP 1.0 Producer for IBM WebSphere Application Server they have been working on has now been published to the WebSphere Portal Catalog, enabling WAS 6.1 to make JSR 168 portlets running on it available as WSRP services.

The IBM WSRP Producer for WAS is a light weight WSRP producer which can expose JSR168 portlets deployed on IBM WebSphere Application Server Version 6.1 as WSRP services. These services can be integrated into any spec-conformant WSRP Consumer like IBM WebSphere Portal Version 6, IBM WebSphere Portal Version 5.1, as well as portal products by other vendors. The WSRP Producer for IBM WebSphere Application Server is stateless (with the exception of session data) and pushes portlet customization to the WSRP Consumer (client).

The code can be downloaded from http://catalog.lotus.com/portal?NavCode=1WP1001BA

More information on WSRP can be found at http://www.oasis-open.org/committees/wsrp/