Busting the UBR Revisionists

I'm sorry - that whole thing about the UBR being an interoperability test really bugged me. And it wasn't just Microsoft that sent out the BIG FAT LIE, IBM did it too.

So, how do you prove 'revisionist' thinking on the web? That's easy - you go back in time. Yes, you visit the WayBackMachine!

And I quote from the Microsoft UDDI site:

"How can you get involved in UDDI? If you are a business, you need to start thinking about how you will transition your company to the world of Web Services. IT architects should read through the UDDI specifications and start thinking about which Web Services your company will define and publish in the UDDI Business Registry. If you are a software developer, you should download the Microsoft UDDI SDK. If you are a software company or an ecommerce portal, you need to start thinking about how you will integrate your products and services with the UDDI Business Registry."

Or do you prefer this one:

Most importantly, UDDI involves the shared implementation of a Web Service based on the UDDI specifications. This Web Service -- the UDDI Business Registry -- is an Internet directory of businesses and the applications they have exposed as Web Services for trading partners and customers to use. Business programs will use the UDDI Business Registry to determine the specifications for programs at other companies in a manner similar to how people use Web search engines today to find websites. This automated application-to-application discovery and integration over the Internet will help eliminate many of the configuration and compatibility problems that are preventing businesses from more widely adopting B2B, despite B2B's potential for cost savings and improved efficiency.

What I don't understand - is how these marketing-whiz-kids thought that they wouldn't get called out on this. This is the age of the Internet - where everything is archived.

See it for yourself:
http://web.archive.org/web/20040718020748/uddi.microsoft.com/about/default.aspx

Some Past Predictions...

Ok - I nailed almost all predictions... except I missed it all by one year.

http://schneider.blogspot.com/2003_12_28_schneider_archive.html#107314457798165610

Take a look at #1, 7 & 10 - oh yea - can you say SCA?


BTW - here is the 2003 list:
http://schneider.blogspot.com/2003_12_28_schneider_archive.html#107262788720914053

And yes, hind sight is 20/20...

Obsolescing J2EE

Without a doubt, the biggest story of 2005 has been the radical obsolescing of J2EE. As much as I would like to say that the J2EE was completely obsoleted, that would be incorrect. Service Component Architecture (SCA) only makes about 75% of J2EE obsolete. Remember, SCA targets: invocation, data structure and composition mechanism.

My Java friends hate when I refer to J2EE as a "deprecated API". Of course, this is an exaggeration - no one actually deprecated the standard. More accurately, one could say that "SCA has superseded J2EE". Or if you want to be politically correct you could say, "SCA represents an abstraction layer to the J2EE component, data and invocation model." Yes, in the short term you will likely use J2EE API's significantly inside of your SCA components. But later, the vehicle of choice will likely become the DSL that 1. Does the job the best 2. Reduces the impedance mismatch.

For those of you that are building out your SOA Reference Models and Architectures, MomentumSI is now recommending a section that discusses the "SOA Programming Model". And of course the most common will be:
1. Java Web Services (JAX-RPC, JAX-M, JAX-B, etc.)
2. Service Component Architecture (SCDL, WSDL, etc.)
2.A SCA with Java only bindings
2.B SCA with XYZ bindings
3. Microsoft Windows Communication Foundation
4. A combination of 1-3 (the most common answer)

So, if we obsolete Java 2 Enterprise Edition - any guess what is obsoleted after that? Bulls eye. Ya gotta love the variation of "embrace and extend" called "Abstract, Replace and Transition"... I can just hear it now... "We warned you about the JCP!" Bam!


---- S I D E N O T E
SCA doesn't mandate domain specific languages like JSP. So, yes JSP is safe - from SCA that is. However, it is clear to me that the AJAX, Ruby on Rails and the Web 2.0 movement will redefine the enterprise reference architectures for the Presentation and Collaboration Layer. The bottom line is that the tolerance continuum allows us to use light weight protocols, dynamic languages and late binding at the presentation layer. Why? Because humans are the best 'fault handler'. Remember: "tolerance over rigidity on the presentation layer!" So although SCA isn't directly attacking J2EE presentation layer, I believe that J2EE presentation vehicles will lose to more tolerant solutions.

Is REST Needed?

Mark "I won't rest until you REST" Baker is at it again. In a recent presentation, Mark tells the population:



He goes on to state:



and the follows it up with several slides like this:


Yes Mark, you can order a pizza with SOAP, with REST, with CORBA, with RMI, with EJB and more. What's your point? The world needs REST? Let's be clear: "REST" is unnecessary - as is all of this stuff! If we want to build our distributed systems with Sockets and EDI we could - BUT WE DON'T!

Mark - if you want to compare and contrast REST and Web services than do it right. This is crap and you know it. The funny thing is, I'm a REST fan - I just can't stomach this one-sided bullshit.

Bye Bye MS UBR!

Just received this email:

You are receiving this mail because you have registered as a publisher on the Microsoft node of the UDDI Business Registry (UBR).

The primary goal of the UBR was to prove the interoperability and robustness of the UDDI specifications through a public implementation. This goal was met and far exceeded, and now the UBR is discontinuing its operations. As part of this process the Microsoft UBR node at uddi.microsoft.com will be permanently unavailable for all operations beginning January 12, 2006. Data stored in the UBR may be retrieved until January 12, 2006 and used in accordance with the UDDI Business Registry terms of use available at http://uddi.microsoft.com/policies/termsofuse.aspx. You may find the UDDI Data Export Wizard useful for retrieving your data, and it is available here: http://www.microsoft.com/downloads/details.aspx?familyid=9D467A69-57FF-4AE7-96EE.

For more information, please see the frequently asked questions related to the UBR discontinuation at http://uddi.microsoft.com/about/FAQshutdown.htm. You may submit feedback to Microsoft at the following location: http://uddi.microsoft.com/contact/default.aspx.

Thank You,
Microsoft UDDI Team

Did I just read that..."The primary goal of the UBR was to prove the interoperability and robustness of the UDDI specifications through a public implementation." Revisionist history is a true thing of beauty. Any chance Microsoft could resend it the email and replace the aforementioned sentence with this one:

"The UBR was a really dumb idea and we apologize for making you sit through lectures on a service oriented yellow pages hosted in the cloud."

Mr. Don Box,

Mr. Don Box,
It wasn't too long ago that you were sniffing around JBI - asking all the right questions. It was clear that you had concerns - as did I.

That said, what's your take on 'Service Component Architecture'?

More precisely, do you agree with the approach given the capabilities of the Java language (and knowing that the Java binding was key)?

Secondly, do you see an SCA binding to .Net components being valuable for your large customers that have mixed platforms?

Respectfully submitted,
Jeff

SCA and Location Coupling

For some reason, I'm fairly obsessed with coupling. I've written a few things on the subject: Dynamic Coupling and A Coupling Index.

I've been monitoring the progress of the IBM/BEA Service Component Architecture for quite some time now. One area of interest to me is the concept of 'spatial' or 'location' coupling (or decoupling, if you prefer).

On many occasions, developers create a model whereby they make an assumption about the caller:

1. The caller will be local (not incurring network issues)


2. The caller will be remote (incurring network issues)

In our quest to progress down the decoupling continuum, the issue of 'location assumption' must be addressed. Hence I was quite pleased to see the following text in the SCA whitepaper:

"Components and their service interfaces can be designed for purely local use by other components, or components can be designed for remote access, either from other parts of the business or from other businesses. Local components can use interfaces optimized to exploit the co-location of the service client and the service implementation. Services designed for remote use must take account of the potential for the client being connected over a remote link and so must offer interfaces that are compatible with this remoteness."

I've been wondering... what will end up being a bigger event, the release of SOAP/WSDL or the release of SCA/SDO. Only time will tell.

Refabricating Architecture

I just finished reading the book, Refabricating Architecture. The book isn't about software; the domain is the architecture associated with 'building construction' (apartments, homes, etc.) I enjoy reading these books as part of a personal cross-training program. There are a couple items that I wanted to share:

"The way to art in much twentieth century theory and practice would be by means of a thorough transformation of production. Architecture as a mass-produced product would transform both access and perception; it would become a thing, a commodity, a vernacular shelter for the twentieth century. Great architecture is today equated with art. Commodity, most believe is the creed of the philistine. It is possible, however, to see commodity instead as the crucible of art itself and to recognize the process engineer - not the design engineer - as the high priestess of this new art. It is not the engineer as the designer of artifacts that we applaud, but rather as a designer of processes that show the way forward in art."

Authors, Kieran and Timberlake, go on to state:

"The single most devastating consequence of modernism has been the embrace of a process that segregates designers from makers: The architect has been separated from the contractor, and the materials scientist has been isolated from the product engineer"

First, let me state my position. I am interested in the commoditization of software architecture. I am embarrassed by the current state of voodoo architecture, wizard architects and clean-sheet implementations. Don't get me wrong, I'm not stating that we should quit inventing or innovating. There is a place for 'material scientists', just not inside of every Fortune 500 I.T. shop...

SOA has the potential to act as the 'material enabler' of the commoditization of software architecture. Modern methodologies will act as the 'process enabler'. Pure and simple - this is my goal. I realize that wizard architects will refute this. They'll hate the concepts of the software factory, mass customization, template architecture and meet-in-the-middle methodologies (not top down). It attacks their creativity and their personal income potential. The true professionals however, will see the ultimate value and find the art in the discipline.

I Hid the Turd

Dear Mr. CIO,
I regret to inform you that I've been hiding a massive turd from you and the business units for several years now. The turd is the "3-tiered silo application". The stench was horrid - I was forced to get some industrial grade air fresheners that I called "EAI and ETL". I feel very bad about this, as does my staff. Although, there were several times where you called us into meetings and we all had those 'shit-ass grins' on our face and you thought we were making fun of you - good news - we weren't, we were laughing about our hidden turd.

But I don't take all the blame. You remember when you asked us to do 12 major initiatives and we told you that we didn't have the staff? Yea - well, we didn't. So we cranked out as much as we could and patched the crap together with messaging. From an architectural perspective, it's a freaking mess!! We've got data replication, batch transfers, multiple message formats, multiple transports, platforms, vendors - wow, I can't believe you didn't fire us!!

The reason that we are 'coming clean' is because we believe we've found an answer. It turns out that using simple protocols and a network programming model that isn't vendor specific will allow us to build connected systems. Also - we discovered this other wacky thing - this new model called SOA actually aligns to the needs of the business.

Now that we're being honest with each other, I feel it necessary to inform you that this SOA thing... is right, but - it actually takes a bunch of planning and architecture. It's like - ya-gotta-use-your-brain-kinda-stuff. And not to drop another bomb on you - but a bunch of these guys around here are morons. Now, I know that you have deep pockets and short arms and don't like to pay for real talent, but I think your screwed if you don't. So, it's your call.

In the meantime, the Turd guys, came up with this new turd-containment concept that they call an ESB. I don't know what it stands for but I talked to some smart guys and they said that it was supposed to be SOA but the vendors missed their deadlines - so they just repackaged their old turds with some new SOA stuff. So, just beware - were probably going forward with the turd-containment stuff and later we'll have to go with real SOA stuff. Sorry for hitting you with all of this.

Sincerely,
Your Entire Staff

Requirements & Specifications in Service Oriented Systems

I couldn't help but notice that the cover story for CIO magazine was about the requirements process and the awful state that it is in. I tend to agree. When I visit customers I see one of two things:
1. The company has perfected requirements for silo based systems
2. The company stinks at requirements all together

I've looked at many systems that people wanted to upgrade, rewrite or replace using service oriented techniques. As a habit, I ask for the original requirements document for the production system. I then play this game to see if I can trace 'silo' or 'closed' characteristics back to the orignial requirements and specifications. In general, these characteristics are usually described in the 'supplementary specification' or in a supplemental 'non-functional requirements' document. And in virtually every case I am able to trace the issues back to the original documents.

One of the significant changes in the 'service oriented enterprise' is an renewed emphasis on: portfolios, product lines, business processes, enterprise requirements and cross-cutting concerns. We are stressing to our customers that they MUST revisit the requirements process and move to an 'enterprise grade' method. That said, I am proud to announce a new course from MomentumSI, "Requirements & Specifications in Service Oriented Systems"

The course is directed at the Business Analyst, but would valuable for anyone that participates in the requirements & specification activities.

---

Course Outline

• Overview of SOA for the Business Analyst
  
• The Business Impact of SOA
  
• The Awesome™ Method for Business Analysis
  
• Strategy, Portfolio Analysis and Business Case Development
  
• Generating Stakeholder Requirements
  
• Coordinating Enterprise Requirements
  
• Validating Stakeholder Requirements
  
• Generating Engineering & Procurement Specifications
  
• Managing Change throughout the SDLC
  
• Examples and Cases

---

I firmly believe that those companies that continue to use 'silo based' requirements processes will fail in adopting SOA. We will begin offering this course in January. If you're interested in the full course description, just send Alex an email: arosen [at] momentumsi.com

The SOA Ecosystem

MomentumSI is a consulting company that specializes in SOA. We help companies with their SOA strategy, plans, vendor selections, architecture, infrastructure, education and business projects. In this role we have a birds-eye view of the SOA landscape, and one thing is clear:

"An SOA Ecosystem is quickly evolving and those inhabitants that fail to recognize the rules of the system will likely wither and die. "

In the year 2005, one significant event took place in the SOA ecosystem. Vendors that were amorphous found shape and structure. Full fledged product categories emerged: SOA Registry & Repository, SOA Management, SOA Intermediaries, SOA Governance, SOA Security, SOA Data Services, SOA Process & Workflow, SOA Testing and SOA Legacy Integration.

As the organisms explored the ecosystem, they found each other. They stared, sniffed and prodded. They identified competition, but most importantly many of them found cooperation. After first contact, emphasis was placed on removing their overlap and short-comings and they began the process of morphing themselves to become "SOA Eco-Friendly".

The SOA Ecosystem will be governed by the laws of all ecosystems. And I strongly encourage those inhabitants to know the laws:

• Symbiosis is an interaction between two organisms living together in more or less intimate association or even the merging of two dissimilar organisms.
• Parasitism, in which the association is disadvantageous or destructive to one of the organisms and beneficial to the other.
• Mutualism, in which the association is advantageous to both
• Commensalism, in which one member of the association benefits while the other is not affected.
• Amensalism, in which the association is disadvantageous to one member while the other is not affected.
• Predation is an interaction between organisms in which one organism, the predator, attacks and feeds upon another, the prey. (wikopedia)

I've been flying around the country talking with large and small SOA product companies about the ecosystem. As a preferred 'SOA integrator' we see the problem from the view of the customer. And as the champion of the customer, we are unable recommend products that exhibit characteristics which negatively affect the customer. Examples include:

1. Portfolio Coupling - Single vendor solutions mandating a daisy chain of products all from the same vendor. Example: If the vendors Process Server requires the vendors ESB which requires the vendors Application Server and the vendors Database Server.
2. Product Coupling - A single product that contains multiple capabilities, where each capability is really a standalone product. (First generation BPM products fell victim to this).
3. Closed System - A product that fails to have integration points into the other inhabitants of the SOA ecosystem. We don't have the equivalent of a J2EE specification for the service oriented / Web service world. The burden to identify and specify integration points and mechanisms is placed on the vendors by the customers and consultancies.
4. Inch Deep, Mile Wide - In the early days of SOA, many vendors were chasing the 'SOA platform'; they provided a little bit of registry, a little bit of orchestration, a little bit of mediation, etc. but failed to excel in any one area. The Darwinian nature of the SOA ecosystem will kill off those vendors that fail to specialize (a mile deep). IMPORTANT: This will force some vendors to abandon entire products or modules and to replace this functionality with 'open system' integration points to best-of-breed providers.

The SOA ecosystem must place the customer at the center. Modern SOA infrastructure must be capability oriented and loosely coupled via standardized policies, metadata, protocols, formats and identifiers. Vendors must recognize the architectural ecosystem, the elements, their relations and constraints. As corporations spend millions of dollars to decouple applications, they MUST place an equivalent emphasis on procuring from those vendors have eco-friendly offerings.

Judith Hurwitz on SOA

With the boot camp consuming my time, I've had to queue up lots of blog posts on recent topics (SOA Maturity Models, Frankenstein, SOA Analysts, Big 5 SOA methodology / scribblings, etc.) But I thought I'd lead with a piece found at the CIO magazine - only because the Judith/CIO magazine combination influences a crowd that needs correct information.

Judith Hurwitz presents her 'ten principles of SOA' in a piece on SOA: Battle of the Titans. My comments follow.


SOA is real. It is not a quick fix. It is a ten year journey (or longer) that requires considerable planning. It is also as profound and far reaching as, for example, e-commerce.

Agreed.

SOA is build upon 15 years of experiments in creating highly distributed computing environments that take into account everything from load balancing, software distribution, security, and data management including meta data management and registry. SOA embraces all these aspects of computing and takes them into account.

Agreed.

SOA will only work if organizations lead with manageability. SOA by its very nature demands the aggregation of IP from many different sources. Scalability within SOA will come from managementÂ?not development.

It was funny listening to all of the vendors at the boot camp. Each one told us what to lead with - 'Lead with the Registry!', 'Lead with Mediation!', 'Lead with security!'. Now Judith might be talking about SOA Manageability or about general governance - it's impossible for me to comment on what she meant. Regardless, I'm comfortable stating that you should lead with SOA strategy and incorporate a closed loop infrastructure. All of the components must complement each other - no one component is at the heart.

SOA will only work if it is implemented within a business process context.
SOA is predicated on leveraging business services that constitute the component parts of your business.

Yea - this is wrong. It is common for a newbie to watch a demo of BPEL/XLang/BPML orchestration and think that they just saw the future of computing. Better yet, they grasp the concept of a 'business service' but fail to realize that this is the ONE thing in SOA that will see the LEAST amount of reuse. Don't get me wrong - there will be some instances whereby SOA enables process-driven applications, but this is merely one of a dozen or so benefits.

SOA requires a container that creates a composite application.

I'll remind Judith that she characterized SOA as working in "highly distributed computing environments". Service based applications come to life by activating services in well known sequence. The composition (or invocation) of these services are distributed. The app server/container metaphor takes on a new meaning. Service oriented applications have 'invocation points' or 'composition points' at multiple layers in the architecture (virtual business service, business service, virtual data service, data service, etc.) The key here is to not accidentally use the term 'container' in the singular. How about, "Composition of service based applications is usually distributed, with no central composition point or single container."

SOA requires standards that can be depended upon across all vendors implementations of SOA.

The ONE truth about SOA is that we CAN NOT DEPEND on standards across all vendors implementations. If you don't understand this, you don't understand SOA. The reason that SOA will work is because we have factored out the non-functional concerns and created transformable protocols, formats and identifiers of the standards which are MEDIATED.

SOA assumes that you will begin to write applications differently as a series of tightly defined services implemented in a loosely coupled manner.

I guess... :-)

SOA assumes that each component part is equipped with a clearly implemented web services interface based on standards.

Agreed. They just don't have to be the 'Web Service' standards, nor do they need to be ubiquitous. They just need to be federated, virtualized and mediated.

SOA dictates that change is the norm since this approach to software mimics the way a business operates and evolves.

SOA is a pain in the ass that, in the short term, will slow down your ability to rapidly deliver software to your customers. SOA doesn't provide rapid change but it does provide a framework for 'scaling capability'. As the number of enterprise concerns rise (consistent data, consistent logic, fulfilling regulatory mandates, process as a first order concern, one-face-to-the-customer, etc.) we need a framework to allow us to change EXTREMELY complex systems. SOA enables the insertion of capabilities in an incremental (and almost linear) manner.

SOA is complex. Explaining it to CIO's is even harder. I wouldn't expect Judith to go to the detail that I just did for the audience she was catering to. However, the amount of poor advice provided is, in my humble opinion, disappointing.

SOA Boot Camp: Days 14, 15, 16 & 17

It's done. Thank God - boot camp is done.

17 days of training seemed like a lot and it was. My friends were joking that I wasn't trying to train the consultants - I was trying to brain wash them. Well - perhaps I was. But it was great for them to hear different views of the same story from so many different people. By the end of the boot camp we had almost 20 different instructors participate. I really need to thank Hjalmer, Melissa, Stephen and Alex for supporting the effort. They did everything from booking hotel, air, car to making sure we got fed - to validating content. I couldn't be happier with the team effort.

Well - the boot camp ended just as strong as it had begun. We were lucky enough to have Sam Boonin from Cisco present the AON vision. I must admit that Cisco has the unique ability to make a complex topic seem simple. Their proposition for relocating functionality from the application layer to the network layer is profound. Naturally, we pushed them a bit on the standards support which was less than what we'd hoped, but it was clear that it was in Cisco's best interest to move the standards forward and that they were on the right path.

And if the Cisco vision wasn't big enough - we followed it up with Microsoft. Our discussion started with a history lesson (COM, DCOM, remoting, WSE, Indigo, WCF) and quickly led into the next generation tools. We went over the new white boarding capabilities in Visual Studio (formerly White Horse) and then was briefed on BizTalk orchestration (and next-gen human workflow). It is clear the Microsoft will be an on-going leader in the SOA space.

We were also lucky to have Peter Yared and his crew from Active Grid talk to us about their next generation tools. His team has done an amazing job of enabling software developers to be productive in no time at all. Peter also made it clear that the 'service oriented' design center was core to his product road map.

The last vendor session was on the SAP ESA story. Our own Scott Campbell presented the SAP vision for service enabling EVERYTHING. SAP is breaking away from their past of being only a packaged application solutions provider. With NetWeaver they are pushing infrastructure (Java, Portals, etc.) and are doing it all with an SOA facade.

And naturally we went back and covered the basics - even managed to get a bit of BPEL coding in. Boot camps are a ton of effort - but at the end, you feel good about what you've accomplished - and you've made a bunch of friends. We passed out boot camp tee-shirts - and headed home to see if our wives still loved us. I declared it a success. We've opened up additional SOA consulting positions and have scheduled the next boot camp for the 2nd week of January.

SOA Soldiers Wanted - the weak need not apply.

SOA Boot Camp: Day 13

After two days of rest we returned to boot camp in Austin where Luc Clement and Chuck D'Antonio of Systinet arrived to update us on the status of Systinet's Blizzard Platform. Many boot camp participants have pointed to Systinet as playing a crucial role in SOA governance. Their Governance Interoperability Framework (GIF) has gained traction among several of our key partners so we were eager to hear more details from the source. Clearly the company has an aggressive set of capabilities they are looking to build out and we were able to drill down on their current and upcoming products.



Luc started out by building the case for SOA governance. We have been discussing this daily but Luc has been probing multiple customers and developing an excellent list of challenges being faced in the field and Systinet's roadmap to solving them. The focus this year is around policy management but provisioning challenges are going to be addressed soon.

There have been many controversies around the UDDI spec and it was excellent to hear Luc's point of view about how the spec developed (including Bill Gates' role) and what parts should be ignored. Systinet dominates the UDDI compliant registry space, but where the registry maintains references only, there is a need to manage the metadata that is an essential component of a contemporary SOA. Luc helped clarify what the Systinet repository product will and will not do and how they avoid creating overlap with other repositories.



Luc also gave us a look at Contract Manager. This product pushes SOA metadata to a necessary further step that involves tracking service consumers rather than just the producers. Solving many the lifecycle management challenges SOA presents is going to require this additional knowledge in the infrastructure.

Chuck led a drill down into the Registry product including the process Systinet is using with their customers to bring a registry up. While some people cringe when the subject of UDDI tModels comes up, obviously Systinet knows this stuff cold and Chuck helped the team get a solid grounding and understanding of some of the finer points. When deploying Registry, Systinet leads their clients through a workshop process and Chuck helped us see inside how Systinet is approaching the design decisions involved in creating initial taxonomies and how we could add value to the process.

As night fell Chuck took the team through a deep dive into Policy Manager. Policy permeates an SOA and we have had heated discussions about where it should be created, stored, and managed. We were pleased to hear the degree to which those designing the product are engaged with its earliest adopters. We'll be working with the product in our lab to help guide their efforts as well.

SOA Boot Camp: Days 10, 11 & 12

Day 10 was the culmination of a lot of hard work; we took all that we had learned about clients, services, intermediaries, architecture, design and pulled it all together under the 'composite application' umbrella. Deborah Scharfetter, VP of Products from Above All Software walked us through the advanced features of their application composition suite.

Above All definitely understands the idea of rapid composition. Their suite in some ways looks like a 'service oriented powerbuilder'. They have some interesting design concepts in the product: 1. Leverage SOA whenever possible, but don't punish the user if SOA isn't possible 2. Make it easy to tap into packaged applications (SAP, Siebel, etc.) 3. Leverage WYSIWYG concepts to enable rapid development 4. Assume that there will be multiple delivery channels (thin client, portlet, rich client, mobile client, etc.) 5. Services will be combined with other services to create composite services, which in turn will be exposed to the service network.

For some reasons "SOA" doesn't seem to hit home until people see a user interface on it. Composite applications seems to create that 'aha' momentum for many.

Day 11 focused mostly on managing & monitoring services in an operational environment. Jason Hollander and Chris Bowlds from Actional went over their SOAPstation and Looking Glass products. Both products looked strong. It was also clear that Actional was taking a stronger interest in the security side of equation than many of the other vendors. SOAPstation has been carefully designed to do both fine grained and coarse grained access control. This is in addition to a real nice UI for quickly adding in ws-sec attributes (signature, encryption,etc.)

The Looking Glass product focuses on the monitoring of services. The product appears to be well designed and full-featured. However it is unclear to me how it will compete/complement with the Tivoli/BMC/HP trio. I really like what Actional has done I just see a potential crash course with the big three. For now, they'll have no trouble fending them off - their offering is advanced and buyers that need a solution today will find an easy answer.

Day 12 we split into teams and continued building out some of our reference architectures. We are close to finishing our SOA Security Reference Architecture - we just need to add a bit more around fine grained access and vulnerability detection. We also made progress in knocking out an XML Firewall Buyers Guide (we'll publish it soon). Lastly, we did a first draft on our 'SOA Operations Management Reference Architecture' and 'SOA Presentation and Channels Reference Architecture' (plenty more to do here!)

By the end of the day on Saturday - we all were starting to feel like this was really a 'boot camp'. We're tired - we all hopped on planes and headed home to see our families. We'll kick it back in gear on Tuesday...

SOA Boot Camp: Days 8 & 9

Day 8 (Tuesday) was an interesting day. Oddly enough we were discussing service networking infrastructure (XML transformation devices, mediation and XML firewalls) - and the press release around IBM picking up DataPower came out. Well - that created a bit of discussion. Generally we agreed on a few things: 1. The deal was good for IBM and DataPower 2. The valuation of Reactivity just went up 3. Cisco needs help with AON. We also spent some time and knocked out a 'service networking buyers guide' which we will make available to our customers.



Day 9 (Wednesday) focused on 'service oriented business intelligence'. Eric Zerneke and y of Service Integrity taught us the essentials of using SIFT. This was a welcome change. We'd been spending a significant amount of time looking at the non-functional concerns of SOA that it was great to learn about a product that was much more focused on providing business value. From a geek perspective, SIFT focuses more on the information found in the SOAP body. So, many people talk about 'business services' - well, accompanying those services are 'business messages'. SIFT presents a solution for 'intercepting' business messages, applying cross-message analytics for the purpose of near-real time event resolution. Unlike traditional ETL/Cube/Analyze/Report solutions, SIFT presents information to a user when the information is still action-able (not post-mortem analysis). They also do a great job of aggregating the data and making it available to a variety of output devices (rich client, portal, etc.) One thing that I'd like to see is a closer integration into intermediaries.

SOA Boot Camp: Days 6 & 7

Day 6 (Saturday) focused on SOA security. We started off by reviewing the typical security concerns found in a distributed computing world: message authenticity, confidentiality, non-repudiation, distributed trust, etc. Part II reviewed the protocols available to remedy the issues: (WS-Security, XML-Signature, XML Encryption, WS-Trust, WS-Federation, SAML, TLS, etc.) Part III reviewed the actual architectural elements that implement the remedies (XML Firewalls, I&AM, Federated Identity, PKI, platform libraries (AES, etc.), intermediary based PEP's, etc. Part IV focused on the Momentum SOA reference architecture (usage of protocols, reference elements, architectural patterns & practices and use cases). At first glance, SOA security appears to be a real beast, but once you break it down it is actually not too bad.


Day 7 (Monday) was an in-depth review of 'decoupling in the network'. Frank Martinez of Blue Titan discussed the protocol resolution to the non-functional requirements of distributed computing (message formats, passed predicates, transports, reliability, security, transactional integrity, etc.) And how each of those issues can be viewed as potential coupling issues. He then addressed the use of intermediaries to mediate the differences between architectural participants. The outcome was an architectural approach that promotes consume-ability by making a service tolerant to the various requirements imposed by clients.

SOA Boot Camp: Days 4 & 5

I was way too tired to blog about the boot camp last night - so now I'm playing catch up...

Day 4 focused on service design: best practices in message creation, encoding types, scoping the port types, importing common types, etc. We all agreed that the current documentation around 'best practices in service design' is still pretty weak.

We also had the whole class do contract first design - and then bind it back to platform implementations, in our case Java. As a reference, we went through Axis, ActiveSOAP and XMLBeans just to give everyone a feel for the various components.

Day 5 moved into testing. Roland Lynn and Wayne Ariola from Parasoft gave us a serious lesson on SOA based testing. Their suite has extensive capabilities for generating test suites and executing the tests across just about any configuration (encodings, transports, attachments). We were also educated on static analysis techniques and scanning for malicious attacks. The session ended with an impressive view of their SOA based load testing capability.

SOA testing is going to have to enter mainstream. It was really kind of odd to see that the state of the art in testing is beyond just about all other aspects of SOA infrastructure. Who'd of thought?

SOA Boot Camp: Day 3

Another tough SOA Boot Camp Day!


Most large enterprises have a number of legacy systems in place - and many of them running on the mainframe. SOA and Web services provide a great way to access those business and data services.

Momentum has a number of clients that are choosing to use services as a stepping stone to migrating functionality off of the mainframe. In this way they are able to create a standard interface and have the clients plug into it. Later the implementation of the interface can be moved to whatever hardware software platform they choose.


We were fortunate to have Rob Morris and Wilson Rains of GT Software educate on 'service enabling' legacy software. First, it was great to see an organization that understands both the classic mainframe environment and the next generation service oriented enterprise. Most companies that we talk with that come from a mainframe environment really don't get SOA - this was a welcome change.

The other item that we quickly noted was the depth of their product suite. We've evaluated a number of similar packages and many of them have quasi-connectivity solutions. As an ex-IBM 390, MVS, VM guy, I know that there is a real big difference between those that understand this environment and those that don't.

SOA Boot Camp: Day 2

Day 2 - Today we covered more of the advanced WS-Specs and what it means to distribute a loosely coupled systems across a network. The focus was on 'creating a virtual application' by using "RST" (reliability, security and transactional integrity).

Most of knew this stuff already so we started the 'Requirements Analysis' workflow early. The first step focused on what has changed in capturing business stakeholder requirements (processes, collaborations, interactions, etc.) The second half focused on the changes in specifying a software system (candidate services, enterprise concerns, etc.) One thing that we all agreed on is that the requirements stage has significantly changed and that we need a specialized course. We landed on "SOA for Business Analysts" which will update the RUP concepts (Vision Document, Use Cases, etc.) with more up-to-date techniques.