Publishing SOAP Calls

WSDL doesn't completely suck. But it isn't the friendliest vehicle for giving a person access to some piece of information.

Let's get real. WSDL as it exists today was largely designed by distributed computing gurus who have added the art of aspect oriented programming to the art of IDL design, while plopping it all on top of our latest markup language, XML.

The Interface
Now, one thing that I do like about WSDL is that I can define the contract (or interface) without specifying an implementer (the binding / port). This allows me to head down the 'contract-first' design path. It also allows me to create a service contract and easily share it with other people. Interfaces with aspect oriented, or declarative resolution of non-functional requirements are pretty damn cool too. Well done.

The Service
A service is created by binding an interface to an implementation (i.e., listen for the call on port 80, with HTTP...). Thus, a service not only specifies the contract (Types, Messages, PortTypes, Operations & Fault), but one that also specifies the aforementioned deployment considerations (Service, Port, Binding).

Design Time: When you are designing your functional solution, you knock your contracts (interfaces).

Deployment Time: When you are designing your non-functional solution (scalability, availability), you knock out your services.

Publish Time: Now, an interesting question arises when I want to publish my contract and its binding for others to consume. As developers, we tend to think that of sticking a pointer to the WSDL in the UBR or shoving it into Xmethods. Nothing wrong with this, as long as you realize that WSDL isn't easy to consume and that it is very likely that someone will give it a shot and eventually give up because the WSDL didn't give enough information to actually be used for its intended purpose. For that matter, they may just look at the 25 different operations specified in the Port Type and realize that they don't even know which operation to call.

Calls
This leads me to Calls. A Call is an instance of an invocation to a Service. Put another way; it is the SOAP envelope all filled out. In many cases, this is what people really want. Consider this: what if instead of publishing my WSDL (with many operations), I merely publish a single operation with many of the parameters all filled out (default values). Now, instead of exposing a WSDL that has a PortType holding 25 different operations to my Calendar Server, I simply publish a SOAP document that performs a call:
What: CalendarAgendaRequest
Who: Jeff Schneider
How: Use the SOAP format and send it to WS-Addressing( location XYZ)

Prior to the WS-* specs, publishing a call didn't do any good. The calls were self-contained (contractually), but were not self-contained from a service perspective (binding). That has all changed. This means that for the first time, we can pre-populate SOAP calls, save them off and make them available to our end users. This is a HUGE leap forward in usability.

Now, developers will have two options: 1. Create a WSDL will all operations and combinations (for power developers) and 2. Create a SOAP message, partially pre-populated (for business users). Now, in order for this to work, it means that we have to quit writing applications that only suck in WSDL's (like InfoPath, Excel, etc.). In addition, you will have the option to pass in a URL to the SOAP envelope (AKA, SOAP Poiner).

Again, the reason for publishing a call is to make it EASY for a non-developer to gain access to some operation.

Indigo documentation

I finally found some documentation on Indigo:
http://msdn.microsoft.com/Longhorn/understanding/pillars/Indigo/default.aspx

InfoPath to BizTalk

I was just browsing an MS slidedeck on Infopath & Biztalk... One slide pretty much summed it up:



See:
http://download.microsoft.com/download/8/d/7/8d71c8b0-0a3e-4b7d-a301-ba9c9ccf5a9b/ ebz301%20Woodgate.ppt

IT Doesn't Matter - Smith & Fingar

I look forward to reading this one. I really enjoyed his last work.



A new book by Howard Smith and Peter Fingar

From the authors of the bestselling Business Process Management: The Third Wave, read Howard Smith and Peter Fingar's critical analysis of Nicholas Carr's infamous IT article in the Harvard Business Review.

Smith and Fingar have been busy expanding on the BPM breakthrough through a number of articles and this new book. What prompted the book was an article in the Harvard Business Review in May that triggered a flurry of debate in business and high-tech circles, and even some calls from Harvard's business school to sever its links to the venerable Business Review. The sensationally titled article, "IT Doesn't Matter," declared that information technology has matured to the point where it no longer gives companies competitive advantages. Now comes the in-depth monograph that debunks the underlying assumptions and conclusions of the article. A Washington Post feature provides an apt summary of the new book, "In IT Doesn't Matter-- Business Processes Do," Smith and Fingar, draw the opposite conclusion: "The strategic importance of IT is actually increasing as the recent 'business process rEvolution' allows companies to innovate the way they do business." As you pursue your work and spread the word about BPM to your current and future business customers, you'll no doubt be confronted with the IT doesn't matter way of thinking--but now you you have a concise resource to explain how value is linked to IT by basing IT on BPM principles.

Commerce One: All Hands Meeting

Commerce One, developer of a 'composite process management' solution has been facing difficult times. I've been told that their 'all-hands-meeting' this week was not favorable. They have laid off just about everyone and are keeping a skeleton crew around to service existing customers.

Best of luck to those who fought the good fight at Commerce One.

WS-* Extensions for Axis??

Does anyone know if the WS-* extensions have been written for Apache Axis, or are in process?

I've been thinking about kicking off a sourceforge project to start knocking them out. I don't want to duplicate efforts if someone else is already working on them though... send info to: jschneider @ momentumsoftware.com
thx. jeff

Borland Exec Reads McKinsey Report...I'm packing my things

Here's a great quote from news.com:
"And because the aging baby boomer generation is nearing retirement, the United States may be headed for another work force shortage, said William Miller, professor emeritus at Stanford University and chairman of Borland Software. In the meantime, displaced IT workers should get training and be willing to relocate to find new jobs, he said. " - Now there is an individual really thinking on his own!

Here's another interesting one: "People have to be prepared to move," Miller said. "That will be one of the requirements of the work force in the future; people must be willing to move where the jobs are." - Does this mean I will have to move to India?



Moving to India will be a blast. I could go bike riding with all of my other American software associates. I can't wait!!!

My only concern is that all of the jobs in India get moved to China. But surely, India has an aging baby booming problem too... perhaps I could take care of their elderly.

Conference sells out

When is the last time that you remember a software conference selling out?



They are turning people away...

Radovan has something up his sleeve...

Ok, Ok, I give... what is it?

http://radovanjanecek.net/blog/archives/000026.html

Where did "service fabric' come from?

I recently had someone tell me that when 'graham glass invented service fabric...blah, blah, blah...", to which I commented... you know, I don't know who invented the term 'service fabric', but Microsoft has been using it for a while now...

---- from DevX --- *a few years ago*
In the following paragraph from the same HailStorm announcement, Mark Lucovsky, HailStorm's primary architect of HailStorm, explains the architectural structure for developers:

We have a thing that we're calling the "service fabric," which is the glue that holds [HailStorm], that makes this system possible. It's a common infrastructure that we've built that all these services to run under. It's a common way to name the services. It's a common way to think about the services. It's a common set of interfaces that if you're writing a HailStorm service, that service must expose in order to have uniform query across all the different services, to have uniform data manipulation. So if I want to add a chunk of XML to a service, I don't have to learn a new way [to do it] for Calendar versus an Address Book. It's the same add method. The data might be different. The schema for that particular service might be different, but the programming model and the service fabric and the glue that holds it all together is uniform.

anyone? surely one of you dinosaurs will tell me that Iona invented it, or it was an MPI term or some shit like that...
:-)

Top 10 Reasons Why the UBR Sucks...

I thought I'd do a top ten list on the UBR - but first, I am reaching out to you... send me your thoughts on why the UBR sucks (or doesn't)... jschneider @ momentumsoftware.com

10.
9.
8.
7.
6.
5.
4.
3.
2.
1.

I'll publish the results in a couple of weeks.

Netscape 7.1 - So far, so good

About three years ago, I switched from Netscape to MS IE. I felt guilty when I did this. To rid my guilt, I have been downloading Netscape about every 6 months waiting for a version that 'works'. Well, I have to admit that Netscape 7.1 might just be the version I've been waiting for...

http://channels.netscape.com/ns/browsers/download.jsp

Services Oriented Enterprise

Sonic has dropped a reprint from "Enterprise Architect" at their site, titled "Services Oriented Enterprise".

Basically it says that the SOE is coming. More exciting, David Chappell got a nice picture of himself posing over a marketing piece showing JMS hooking up to parnters in a bus topology.

COMPLETELY UNRELATED.... here are some pictures of crashed buses:







ROTFL - jeff.

Iona to release web services product on Monday

Although web services are still an emerging technology and part of a long-term investment program; Iona has stated that its new product "Artix" is part of a "get back to profitability" program:

http://zdnet.com.com/2100-1104_2-5093213.html

If I remember the BCG product portfolio matrix correctly, the Cash Cow is supposed to sustain your profitability. The Rising Star is supposed to bring new profits...

This poses a common dilemma - what to do when your Cash Cow runs out of milk and your Rising Star is still in early adopter stage.

Gartner has nice clipart

I just previewed the new Gartner presentation on, "The Business of Web Services: Models and Opportunities" by Whit Andrews.

Despite the amazing lack of substance, Whit managed to find some real nice clipart. However, I am now of the opinion that the clipart drove the message of his presentation. If you are looking for substance on web services, you will likely need to go somewhere else, however, if you are looking for clipart, Gartner is the place to be!

Keep up the fine work. :-)

Market Yawns at WebMethods

If three acquisitions in the same day won't move the stock, what will?

The Mind Electric is Acquired

See:
http://news.com.com/2100-1012_3-5090102.html?tag=nefd_top

Offshoring and Wiping Baby Boomers Bedridden Asses

I finally broke down and read the McKinsey report on offshoring. This is the report that everyone references when they don't know the facts about the effects of offshoring on the U.S. economy, the U.S. corporation or the U.S. citizen. Instead, people just say stuff like... "well, offshoring is natural. Didn't you read the McKinsey report? It actually benefits everyone!" Normally you need an MBA to make such an asinine statement. I can say, "Yes, I read the report"

Now, I'd like to hold a made-up, virtual conversation between Senator Adam Smith and myself:

Jeff responds, "Yes, I did read the McKinsey report. Well... as I'm sure you know, it isn't actually a "report" - it is a 'perspective' that was published preceding the release of any factual data. Senator, the thing that got me was that McKinsey decided to have a person from India write the report. Now, I'm sure that the author Vivek Agrawal didn't have any conflicts of interest - nor did McKinsey - even though their entire customer base is mostly globalized corporations that get short-term benefits from laying off American workers and replacing them with cheap offshore labor. But, I’m sure that when they put out their final report it will be under FULL DISCLOSURE.

The report was a good read. I really liked the part where they referred to laid off workers as being, "freed up to take other jobs" - holy shit, Senator - that Vivek really has a way with words!

Senator Smith comments back..."Come on Jeff. You're being critical. What Vivek was saying is that by reducing labor costs we are able to produce goods at a lower cost. This will have an immediate positive margin effect on the business owner and investor, allowing them to reinvest, which would lead to hiring new workers."

Jeff comments, "Come on Senator, new jobs? Doing what? These people can't fight the Asian pay scales. They're screwed. "

Senator Smith quips, "Now Jeff, they're not screwed. You saw the report. America is aging. The baby boomers will be retiring soon. This will deplete the workforce and create a new burden to take care of the elderly."

"So what you're saying is that for the sake of corporate profits, American lawmakers will tell well educated software professionals to move into health care? Sir, with all due respect, many of these guys have masters degrees in computer science, 10 years of experience and more importantly - THIS IS WHAT THEY LOVE DOING". You can't just tell them to start wiping baby boomers bed ridden asses as a new career, can you?"

Now Senator Smith is agitated. "You know I'm not recommending all software people start wiping asses for a living. I'm just saying that in order to remain competitive, we do.... well, what we have to. And you saw the McKinsey recommendation. They recommend that we offer a new insurance to those that groups most affected by offshoring. Thus, the employee will get 70% any difference in wage losses."

Jeff smiles. "Great, now I get to wipe asses and get sympathy insurance.... and I'm still not making as much as I used to. This makes me feel great!! But wait... if the employer gets stuck picking up the tab for ‘offshore insurance’ of 'freed-up workers' and the 'freed up' worker can't get a job then won't this lead to higher insurance premiums. And won't those premiums negate most of the benefits of going offshore in the first place?"

Senator - "Yes! Now you're getting it. The insurance package will have a payment system that penalizes corporations for laying off workers when the talent pool is high. Thus, if a corporation is only laying off people because they want cheap labor and there are lots of 'freed-up' American workers, then they should have to pay higher premiums."

"But Senator, when the economy is poor we usually see two things, 1. people getting laid off and 2. corporations trying to figure out how to make a margin. What you are telling me is that when corporations really need to squeeze out margins they won't be able to move work offshore because it will be cost prohibitive due to insurance premiums. That doesn't make sense.

On that note, why would I hire American workers at all - knowing that I'm going to get stuck paying for offshore insurance? So, let's say that I start a new company with some of that money I saved by laying off my American employees. Now, why would I hire Americans? Not only are they more expensive, but now they have a offshore tax that is associated with them."

Senator, "Well, Jeff... maybe you wouldn't. Maybe you'd just go offshore and take the higher margins the whole way. Then again, maybe you would hire locally because the job was better suited for proximity-based labor," commented the Senator.

Jeff sighs. "Gee Senator - I sure wish that I could believe the McKinsey report. I wish I could believe you. But for some reason, it just doesn't make sense. It is rare to find occasion where it is a true 'win-win' - I've found that usually one party wins, the other party wins, or it is a zero-sum-gain. I clearly see how the Indian government wins. I clearly see how the Indian corporation wins. I clearly see how the Indian employee wins. Conversely, I clearly see how the American employee (ass wiper) loses. What is less clear is the fate of the U.S. government and the U.S. corporation. I could see where the U.S. corporation could take short-term gains by 'freeing-up' labor. But 'freed-up labor' makes less money, has less purchasing power and ultimately buys less from those same corporations - which means that the U.S. government is collecting less sales and income tax. Senator, if I could make one suggestion?"

"Sure Jeff, what is it?", says the Senator.

"Senator, read the McKinsey report. I mean actually study it. Keep track of who wins and who loses (US government versus offshore government), (short term versus long term), (employee versus employer). My gut tells me that you're not going to like the outcome of your matrix. McKinsey has a great reputation - but I got a feeling that this one could end up being a real embarrassment for them. "

"Jeff, that sounds like solid advice. Can I get you another glass of wine... I think it's French!"

Microsoft just gets it...

Microsoft just plain gets it. They understand web services and they understand developer needs.

Take a look at this screen shot from the MS WSE documentation. One nice set of docs around all the WS-* specs. It is a thing of beauty...

Public SOAP Router

I pistol-whipped one of my consultants into putting up a public SOAP router. It is the WSE 2.0 impl. If anyone wants to donate another impl, I'll gladly put that up as well.

For now, there is no dynamic routing algorithm.. just a static routing table. We are going to use 'to' fields in WS-Addressing as the final destination (for now).

We are also hoping to put up an unreliable-router soon (to test WS-ReliableMessaging, along with a static WSRM Policy Assertion).

This is super-duper beta kind of stuff. Send me an email if you are interested in testing out the public router: jschneider@momentumsoftware.com

We are building an HTML front-end so that you can add your own entries but this isn't out yet. Til then, you'll have to email us your endpoint information.

[[try to use 'pistol-whip' in a casual sentence when talking to friends - it will likely bring a smile to your face!]] LOL

Microsoft & Amazon link up via web services

By integrating Amazon Web Services, Amazon.com Research Services for Microsoft Office System will provide Microsoft Office System users with access to Amazon.com from within Microsoft productivity applications via the Research Task Pane. Users can access Amazon.com information and make purchases without launching a browser or leaving a document, email message, or presentation. For example, a customer reading a bibliography in a Word document could click on a book title and purchase it from within the Research Task Pane without leaving the Word document. Alternatively, a user will be able to add a footnote, bibliography entry and cover art for books without manually entering the information into a document.

See: http://www.econtentmag.com/Articles/ArticleReader.aspx?ArticleID=5611

Logical Services

In web service composition (service piping, orchestration, etc.) you have the ability to make one service front-end multiple services. In BPEL, every orchestration is exposed as a web service despite the fact that it potentially encapsulates *many* web service calls.

I've blogged in the past about how the granularity of the service shouldn't matter. Granularity should be adjusted on the fly (when possible). I've blogged about *cheats* - that is, in-process calls that never actually used the network services (TCP & HTTP) - or even web service calls that were too lazy to use XML Schema - they realized that they were running in the same JVM or CLR and just used shared memory. These concepts are related to my vision of SODA (a concept popularized by Darryl Plummer at Gartner) or Service Oriented Development of Applications. The fact is that SODA doesn't work unless you cheat. You must have both static and dynamic optimizations of service-to-service calls.

When you do this you begin to realize that the piece of code that you called your 'service' was aggregated with another piece of code also called a 'service'. After a while, you realize that all of your services were really just logical things that could have their boundaries redrawn.

Web services are logical - hell, software is logical. The interfaces, the boundaries, the messages between them - all logical. Thus, the ability to recombine them in new ways is not only possible and practical, but perhaps inevitable. Future SODA tools will have the ability to *compile* multiple services together into single service.

Now, what does *compile* mean? Hmm... interesting question. Well, it could mean actually compiling. Or it could mean orchestrating. Or perhaps, just redelivering the service to a runtime container that knew how to *cheat*. Any way you look at it, the art of SODA will be about the ability to combine services in a variety ways. It should protect the black-boxed nature of the service while still giving the developer all of the functionality and performance of a compiled application.

SODA is the evolution of programming; when should an object be a component? When should a component be a service? If you answered these questions based on interface granularity then you don't understand SODA.

Stencil Group Changes Mission: Conspiracy Theorists

Ok. Just kidding of course. The Stencil Group does great work - however, I really, really don't understand the conspiracy piece that Bill Robins wrote about at news.com.

Why would IBM and MS share the stage to promote web services? The answer is simple. They need to create a compelling reason for their customers to buy the next generation of software suites. The major advancement in the suites is web services - and yes again, interoperability is required. IBM and MS must do more sessions with top people demonstrating this in order for them to convince the customer base of the primary value proposition.

One more time...
A compelling reason to buy.
Microsoft makes decisions based on making money... selling products... providing value; it is real simple.

Becky Dias at MS is blogging

I just found the blog for Becky Dias, the WSE product manager at Microsoft.
Check out: http://blogs.gotdotnet.com/rdias/

Interwoven release SOA version

See:
http://www.interwoven.com/news/press/2003/0721sdk.html

Cape Clear has a nice WSDL editor...

So I needed to hack up a quick wsdl - so I sucked down the free one from Cape Clear.
It rocks. However, I didn't fully understand this:

Web Services Enterprise Edition

What is the standard .wsdl for a workflow engine to expose its state?

What is the standard .wsdl to expose a message queue? What about a pub/sub topic?

What is the standard .wsdl to expose LDAP?

What is the standard .wsdl to expose POP? SMTP? FTP?

You know, it's great to have one-off wsdl's over at xMethods. But at some point we are going to have to pull together a 'library' (or profile) of wsdl's to expose the technology architecture. The library should be consistent in style. After we finish it we should throw it away - because it will be wrong. Then we should start over.

The end of BPM-1, the beginning of BPM-2

I dropped a few comments on BPM-2 at 'Loosely Coupled'. I'll try to elaborate on this article in the coming days.

Also, I seem to be losing the battle to change the name of an ESB to something that makes sense. So, if you can't beat'em join'em. Message oriented services with durable load tempering devices is a solid concept. It's still a stupid name - but I'll get over it.

EAI vendor revenues continue to topple

Wow... if this is our bull, I'd hate to see the bear!

7 Things Great Software Architects Have

1. Friends that are also great architects
2. Loyal associates that are great designers and programmers that will work with them no matter what the project is
3. Extensive experience on at least 3 platforms (mainframe, J2EE, .net, CORBA, TOGAF, etc.)
4. A bookshelf that is about to topple over and a mechanism for demoting bad books
5. 3 or more candidate architectures or software architecture documents (SAD's) on your hard drive
6. Your personal ontology of non-functional requirements
7. 'Success Patterns' - things you know which have worked on previous engagements

Lou Dobbs - Exporting America

WOW - I just watched Lou Dobbs. He is running a special series called, "Exporting America". He is spot lighting the overwhelming move of American jobs to low wage countries like India and China. Lou is one of only a small handful of people that have had the balls to stand up and fight for the American I.T. worker and the current unfair trade policies that exist.

Tonight, he had Adam Smith, congressman from Washington on the show. Adam has initiated a study with the GAO to look into the effect of the multi-national corporations decision to fire American workers and hire cheap offshore labor.

What was extremely disturbing was that Adam Smith seemed to already have his mind made up. He commented that he didn't have any issues with the H1B program, and thought that there *might* be some issues with the L1B program. Adam Smith are you nuts? The American I.T. worker has taken it up the ass.

Last week my company had some job openings and I did the interviewing. I had three candidates in a row all come in who were on an L1B program, hadn't had a job in months, continued to stay in America and were commenting that they would work for "whatever I wanted to pay". I asked them who sponsored their visa and they all told me names of different Indian based 'body shops'. Naturally, I asked if the shops that brought them in employed them. They then explained to me that the Indian shop provided them a plane ticket. In exchange for the ticket, the individual would have to pay the sponsor 20% of all of their wages while in the U.S. It was the individuals responsibility to go and get a 'real employer'. In essence, they were indentured servants to the company that bought their ticket. Adam Smith this is reality. Don't believe me? Get an employers account on Monster.com, do a search for "Java" - you pick the city, call the first ten results and ask the individuals their situation. I dare you.

Here is the contact page for Adam Smith:
http://www.house.gov/adamsmith/contact/contact.html#
Take the time and fill out the form. Please.

The 2-pin theory.

Sean McGrath wrote a thought provoking piece.

I caught myself responding on one of the news groups & thought I'd share...
===================================

Wow - nice piece from Sean. Thought provoking.

Is the *magic* of the interface related to the *2-pin* theory (i.e., do(x)) or it related to advancements in protocol negotiation? Does USB work better because of the number of pins or because of the structured negotiation between participating components? What about BlueTooth?

WS-* is moving into a world where dynamic protocol negotiation for non-functional requirements will be able to happen on the fly.

An example of two web services talking to each other (think consumer:producer) :
Service 1: Can you do encrypted?
Service 2: Yes, I do TripleDES, Do you?
Service 1: Yes, let's do it!
Service 1: Do you do Reliable Messaging?
Service 2: No, not for this operation.
Service 1: Can you treat this operatin as part of a transaction?
Service 2: No, I can't, but I do have a compensating mechanism, see URI:xxx.wsdl
Service 1. Great, I'm going to use it.


Now, an interesting question is how did databases servers get away with a small number of interfaces / operations? The answer is that they created languages which could be shipped across a wire to perform more complex functionality. Thus, the database has the notion of the do(x) - or if you'd like, you could say that it had:
do(DDL)
do(ANSI SQL 92)
do(stored procedure), etc.

Back to the conversation:
Service 1: Now, it is time for us to do some real work, I need some data, do you support XQuery 2.0?
Service 2: Of course! Send your query on over!
Service 1: Ok, here it is: (query blah, blah, blah)
Service 2: Great! Here is your result (some data, ....)

Now, of course, you wouldn't want the conversation to be anywhere near this verbose... but you get the idea. Simplicity in interface doesn't just happen by creating a magic "do(x)" - you have to actually have some meat behind the operation. Web service protocol designers are attacking both of these fronts (NFR protocol negotiation and ubiquitous, shippable languages like XQuery).

IMHO, looking for simplified interfaces is good - just be careful not to throw away your meta-data just to make a clean WSDL.
Jeff

WSDL of the Day?

If Don Box can do a Win32 API of the Day... surely I could do a 'WSDL of the Day' !

Hmmm... sounds like a lot of work. Anyone want to help? (If not, it will likely turn into WSDL of the Month :-)

OASIS to look at EVERYTHING

I just stopped by the OASIS Messaging and Coordination page and got a good laugh. It appears that Karl Best and friends have decided to take on a few more specs. So, in addition to BPEL, we have:

Business Transaction Protocol (BTP)
OASIS Asynchronous Service Access Protocol TC
OASIS Web Services Composite Application Framework (WS-CAF) Technical Committee
W3C Web Services Choreography Working Group
Web Service Choreography Interface (WSCI)
Web Service Composite Applications Framework (WS-CAF)
Web Service Context (WS-CTX)
Web Service Coordination Framework (WS-CF)
Web Services Transaction Management (WS-TXM)
Web Services Choreography Description Language (WS-CDL)
Web Services Conversation Language (WSCL)
Web Services Transaction Framework
Web Services Atomic Transaction (WS-AtomicTransaction) [replaces WS-Transaction-V1, Part I]
Web Services Coordination (WS-Coordination) [Version 2]
Web Services Business Activity (WS-BusinessActivity) [to replace WS-Transaction-V1, Part II]
Web Services Transaction (WS-Transaction) [Version 1]
Web Services Coordination (WS-Coordination) [Version 1]
WS Choreography

A Bounty
Ok, enough is enough. Can we put out a bounty to be paid to anyone that manages to kill a working group? Honestly, I will kick in my fair share. For starters, let's whack WS-Choreography - I'll pay $500 USD to the person that disassembles this working group. Surely there are others that will kick in too... My fear is that as quick as we knock them down, the fine folks at Oracle, Sun and Iona will create new ones to replace the old ones. Hence, I propose that we find the professional spec writers at the aforementioned companies new jobs. Got a startup? Offer one of these guys a job! Not because you need them... because you'll have to spend less on marketing to educate the world on why your product doesn't support some bullshit specification that these people made up. In the end... it will all pay off
:-)

OASIS to look at Methodology

Name of the TC: OASIS Framework for Web Services Implementation (FWSI)
Technical Committee

Statement of Purpose

The purpose of OASIS FWSI TC is to facilitate implementation of robust
Web Services by defining a practical and extensible methodology
consisting of implementation processes and common functional elements
that practitioners can adopt to create high quality Web Services systems
without re-inventing them for each implementation.

It solves the problem of the slow adoption of Web Services because of
lack of methodologies to implement Web Services, and a lack of
understanding of whether solutions proposed by vendors have the
necessary components to reliably implement an application based on Web
Services.

Model Driven Services

The model for creating business software has leveraged the concept of utilizing a base engine (or server) and extending its functionality with specialized models, templates or other consumable metadata. In J2EE, we use a JSP template engine to consume JSP's, we use an EJB container to consume EJB's, etc. Typically we then chain together engines (JSP engines + EJB engine + DB engine) to fulfill some use case.

Many of the web services that I have created were "home grown", that is to say that they were written from scratch and didn't leverage any engine. The more I looked around, the more I realized that others (including vendors) seemed to be caught in the same boat. Moving web services into the (model + engine) world is obvious.



I found myself asking how come we haven't seen more model driven services? I think one reason is that many developers are too concerned about the SOA triangle (producer, consumer, directory). The SOA triangle is an architectural pattern that will be used over and over again inside of service-based applications. However, it isn't the end. Extending the triangle, or leveraging other patterns is absolutely necessary.



So, here are some interesting questions to ponder....
1. To what extent does one attempt to standardize authoring environment interfaces?
2. Does an authoring environment service provide a default UI customizer that is shippable (JNLP style)?
3. Should the customizers (models, meta data, etc.) be logically held together at the use-case / scenario level?

IBM, Batty, Autonomic Computing

I've been blogging how IBM is Batty on a few subjects... most recently on web services, grid (OGSA), model driven architecture (MDA)... and now autonomic computing.
See:
http://www.research.ibm.com/autonomic/

The convergence of the aforementioned technologies could create one interesting model!

From UML to BPEL

Keith Mantell at IBM wrote an article on using UML and MDA concepts to gen your bpel. See:
http://www-106.ibm.com/developerworks/webservices/library/ws-uml2bpel/

He creates a UML profile that has the semantics to represent bpel and then discusses making a map from the model to the bpel code. The base process is represented as a class and the orchestration is modeled as an Activity Diagram.

All in all, it is an interesting concept. One concern that I have is that people don't try too hard to shove a square peg (UML) into a triangular hole (SOA & BPEL). The base UML models were developed some time back and don't always represent the concepts that we need. For instance, I use a Service-Based Sequence Diagram rather than Activity Diagrams to represent orchestrations... just seems easier.

Web service testing ... no fun

Anyone that has had to serious testing of web services knows that it is no fun - just noticed that Optimyz has put out version 2.0 of their tool:
http://www.optimyz.com/product_overview.html

and not to forget the fine folks at Mindreef who have released version 2.0 as well:
http://sdtimes.com/news/085/story13.htm

Web Services Enable New Front Ends

I've seen a couple of these now... new portals that use web services to collect information from a variety of sources:

http://www.anacubis.com/amazondemo/

Although still early, I anticipate many sites to begin incorporating cross-site, cross-database integration.

StrikeIron Web Services Analyzer

I've been playing with a tool to invoke web services from StrikeIron. Overall, I think they did a pretty good job!

One thing I like is how they are displaying the results in a grid-format, rather than having you traverse a tree. One thing I don't like is that you can't abend run-away queries.

Offshore Backlash

You know that an offshore backlash is in effect when 'The Economist' publishes pictures of 'Casual Friday' at an offshore company like this:

More confusion on course / fine grained at Syscon

STOP THE MADNESS!!

Yet another article has come out saying that we should write our web services using course grain interfaces. Authors, please stop writing this nonsense.

The course/fine grain issue does not have a 1:1 relationship with web services.
The course/fine grain trade-off is often related to distributed computing, but even that is incomplete.
The course/fine grain trade-off is an issue of latency and usability.

A web service that implements fine grained interfaces and is meant for local invocation is PERFECTLY FINE.
A web service that implements fine grained interfaces and is meant for distributed invocation and is on a low-latency network is also PERFECTLY FINE.

I really wish that Doug Kaye would get on the bandwagon and speak out on this issue - many, many people have misunderstood his book. I do like the SO design guidelines Mr. McDowall has going, note that he doesn't mention asynchronous or course grained (thank God).

Now that both the Microsoft WSE and WebSphere 5.02 both support local in-proc web service calls without hitting the socket or marshalling the data to an XML format, we need people to QUIT saying that web services should be designed with course grained interfaces - it is wrong. Design web services using a course grained interface when you know that there is a latency issue - or when it just plain makes it easier (usability) on the end developer (and has no side effect).

See:
http://sys-con.com/webservices/article.cfm?id=641

Stuck in Java Land

I just caught the thread in "The Server Side" where the 50+ people all tried to say that Don Box was full of crap for commenting that SOA will eclipse OO as a programming model, see:

http://www.theserverside.com/home/thread.jsp?thread_id=21132&article_count=39

Well, this seems to be the typical response that Java dudes have to web services and SOA. Now, if it was Bill Joy or James Gosling that made the comment these guys may have taken it seriously. So, BEA is on the SOA bandwagon - they seem to get it (thank Adam?), IBM gets it... but doesn't really have the evangelism going. I look forward to the day when the masses 'get it' and quit dogging on thought leaders like Box.

Sun sees BPM, just doesn't know what the acronym is...

Sure, 99.9999% of the world believes that BPM stands for Business Process Management, but to SUN it stands for Business Process Machines - good going. Alright, it is no secret that I think that Sun has screwed up their chance to dominate enterprise computing architectures in the coming years. By fighting the web services trend and running after Java-only platforms and CBD style programming, they gave IBM and Microsoft the keys to the kingdom.

In an attempt to get back in the game, Sun is pursuing a strategy called JBI or Java Business Integration. This venture acknowledges that Java needs more than API's for calling web services, thus the JAX solutions are merely bridges between old and new environments (Java CBD and SOA). JBI, however, is a restating of the problem. It acknolwedges that first order concerns in architectural design are interoperability and integrate-ability.

In their words,
JBI is intended to support the full range of integration solutions,including simple,synchronous point-to-point EAI or more complex B2B business process automation incorporating long-running transactions and complex workflows. However, it is especially well suited for business process automation problems, with the goal of enabling much simpler development of solutions that today are complex and time consuming to implement. Examples of the solutions JBI will facilitate include:
•Self-service customer portals
•Enterprise employee portals
•Customer relationship management (CRM)integration
•Supply chain integration
•EDI replacement

And what will the approach look like?
JBI will support an RPC-oriented Web services programming model as well as a message-oriented Web services programming model,in particular,the constructs of:
•Components as services with interfaces that are publicly and explicitly described by standard metadata,for example,the Web Services Description Language (WSDL)
•Document-centric processing where component services act on standard,structured XML documents that contain both business data and metadata,which provides context for service execution
•Asynchronous communication between components with support for long-running transactions

And the scope is?
The current scope of the JBI architecture standard, as described in the approved JSR 208 proposal, is not to specify how components are themselves implemented. Instead, it only specifies the interfaces they must support for plugging into the JBI environment to use its services and interact with one another to request and deliver services. Thus,JBI is at least initially about system programming interfaces (SPIs)and not about application programming interfaces (APIs), and therefore pertains more directly to those who build integration servers and tools than to those who build solutions with them.

You know, I really like this idea. However, I have this bad feeling that Sun will screw it up. They will likely continue to treat their language (Java) and platform (J2EE) as their primary concerns and treat JBI as an add-on (rather than the other way around). Sun will have to throw away their notion that everything is either an API or is Java P-code and move towards protocols and language neutral interfaces. Lastly, they will have to quit fighting IBM on EVERYTHING. If IBM & Microsoft agree on a new specification, just go along - and win with the implementation. They must stop trying to win the ego battle. Perhaps a tough job for a company run by McNealy.

For more on JBI, see: http://www.webservices.org/papers/JBIwp70903.fm.pdf

Microsoft Changes Group Name

The group that housed the MS web services team was known as GXA (Global XML Architecture). They are now called WSA (Web Services Architecture).

Also of interest is that MS has taken WS-Routing off the list of WS standards they support. This should mark the official death of it, with WS-Addressing superceding it:
http://msdn.microsoft.com/webservices/understanding/specs/default.aspx

IBM is batty over OGSA

From what I can tell, three major themes are coming out of the IBM software group:
1. Model Driven Architecture (a byproduct of purchasing Rational)
2. Web Services (a byproduct of being in bed with Microsoft)
3. OGSA (a byproduct of wanting to beat Microsoft)

The OGSA is an interesting beast and at the heart of it you will find web services:



For more information on OGSA, check out:
http://www-106.ibm.com/developerworks/webservices/library/gr-visual/

One thing I didn't really get was why they have OGSI services laying on top of web services, and their explanation didn't help:

Let's look more closely at the two main logical components of OGSA -- the Web services-plus-OGSI layer, and the OGSA architected services layer. See Figure 2. Why are they separated like this? The GGF OGSA working group believed it was necessary to augment core Web services functionality to address grid services requirements. OGSI extends Web services by introducing interfaces and conventions in two main areas.

First, there's the dynamic and potentially transient nature of services in a grid. In a grid, particular service instances may come and go as work is dispatched, as resources are configured and provisioned, and as system state changes. Therefore, grid services need interfaces to manage their creation, destruction, and life cycle management.

Second, there's state. Grid services can have attributes and data associated with them. This is similar in concept to the traditional structure of objects in object-oriented programming. Objects have behavior and data. Likewise, Web services needed to be extended to support state data associated with grid services.

IMHO, the ws layer should front end all of the service - both of the aforementioned issues seem resolvable. Perhaps the IBM boys will set them straight...

Designing Web Service API's

A while back I blogged that we need to learn lessons from the Salesforce.com web services API... the implication that I made was that they did it wrong. Since then, others have poked at it as well:
CBDI
Phil Windley

Recently I had to design some web service api's for various types of services. One client required a read/only ws api that proxied data from their database. In addition, they wanted all insert/update/delete to go through the business tier.

My design turned out interesting - for the WS proxy api to the database, it looked very close to the SF.com api.
read( xyz)

For the ws api for the business services, it looked very much like Amazon:
AddEmployeeRequest( xyz)

Different services will require different invocation and granularity models. I think the SF.com got the api correct if you merely want to front-end a database. It is a bad design if you want to front-end business services. And the vice-versa is true with the Amazon way.

I'm going to try to be more careful when I blog service oriented designs... they are obviously context sensitive. One mistake that I see made is people saying that web services should be designed as 'course grained'. Well, you sure need course grained if you're going across a network with latency, but 'fine-grained' is just fine if you know that all your calls are In-Proc. Which, is an out-of-the-box function of the Microsoft WSE-2. My point is that we (bloggers) must be careful not to report 'generic' solutions without putting them in context - I'm as guilty as the next guy.

Job Openings - Web Service Consultants

Momentum Software has recently opened several new positions in our Web Services Practice:

Title: Web Services Architect
The Web Services Architect is responsible for:
- Translating business requirements into technology solution
- Designing the service network (security, directory, queues, management, adaptors, routers, balancers, etc.)
- Identifying vendor solutions
- Leading small teams of implementation consultants
- Some pre-sales support activities, including estimating jobs and candidate architectures for proposals
- Knowledge transfer to client teams

The successful candidate will have:
- 10+ years experience in software, 4+ years in architecture
- Very strong background in WS space (primary specs from WS-I, OASIS and W3C)
- Strong background in J2EE, .Net or both
- Strong background in distributed computing (CORBA, DCE, etc.)
- Strong background in non-functional requirements (quality attributes)
- Ability to document architectures
- Great interpersonal and communications skills (written and verbal)
- Able to travel within U.S. greater than 70%

Title: Web Services Consultant
The Web Services Consultant is primarily responsible for implementing service-based solutions. Activities include:
- Consulting on application and enterprise re-designs
- Front ending legacy applications with web services
- Designing and implementing new services, including service frameworks
- Coding JAXM, JAX-RPC, JAXB, .Net IIS Web Methods, GXA & WSE (Java, C# or both)
- Designing XML Schemas, schema to Bus Obj maps, schema to Er maps

The successful candidate will have:
- 4+ years experience in software, 1+ years in WS related activities
- Strong background in J2EE, .Net or both
- Very familiar with base technologies (XML, SOAP, WSDL, UDDI, JAX*, WS-*)
- Great interpersonal and communications skills (written and verbal)
- Able to travel within U.S. greater than 70%
- Orchestration development is a plus

These are new positions - note that traveling is mandatory. Please indicate your desired role (Architect or Consultant). Along with your resume indicate your compensation requirements, citizen status and ability to start. Send your resume to : careers@momentumsoftware.com

Web Services Choreography Requirements 1.0

The W3C published their "requirements" document for web services choreography:
http://www.w3.org/TR/2003/WD-ws-chor-reqs-20030812/

This just might be the biggest piece of crap that I've ever had the misfortune of reading. I'm not just saying that because I think that the W3C should get out of the business of 'business process languages' - I mean it.

Seriously - look at the document. Remember it is a requirements document. I've read it twice now - for the mercy of spec readers everywhere - can someone please kill this working group???

The Mindreef Team

Currently, I do not use the Mindreef software.

I was considering using it so I checked out their home page. And, like many people, I went to the 'team' page to see if I knew any of the guys working on it. I didn't, but they had a great team picture:



Wow. These guys look like geeks. I mean that as a compliment. I am much more likely to download and use their software after previewing the team photo. This seems silly doesn't it? The fact is, we've all worked with great engineers - and generally speaking they... kind of look alike. Now, Graham Glass may be the exception to the rule:



Anyway, if you have a 'mindreef' looking team, it may be in your best interest to post the pictures :-)

I'll go drink some coffee now - I'm sure I have something slighly more insightful to say than just this...

WSEE

Anne Thomas Manes wrote a piece on a topic near & dear to me, see:

http://www.sys-con.com/webservices/articleprint.cfm?id=627

The only thing she didn't do was give the set of services a name... like... uh... Web Services Enterprise Edition (WSEE).

WS-I Basic Profile 1.0 has been approved

All -

I am pleased to announce that the WS-I Basic Profile 1.0 has been approved as final by the WS-I membership.
Congratulations to the Working Group for a job well done.

cmk

Apache Geronimo: A waste?

I don't follow the open source J2EE stuff very much.The decision for the Apache group to write yet-another J2EE implementation has me exhasuted.

I personally feel that the J2EE programming model is out dated. Yea... it was good in its day - but the service based model is here and J2EE is "last-gen". A platform architecture that is hard-baked to three tiers is not going to survive.
When I saw that Apache was going to re-write the entire J2EE stack, I felt really sad. It was so disappointing that a group would attempt to rewrite the same last-gen stuff that has already been written a dozen times over.

I just wish they would consider doing something NEW, rather than yet-another-impl.

Service Oriented versus Service Based

I found myself in a debate with some people around the term 'service oriented'. I fought that the term referred to the architectural pattern - that is, the triangle - producer, consumer, directory. My worthy opponent fought that most people that are building service based architectures are leaving out the directory. He went on to argue that if in the majority of the cases people were only using 2 of the 3 legs of the triangle, that we shouldn't refer to it as a 'service oriented' architecture. I agreed. We actually threw out the term Service Based to refer to a set of architectural patterns that revolve around services.

Thus:
'Service Oriented' refers to the triangle pattern.
'Service Based' refers to the set of patterns that leverage services (service oriented, pipe & filter, pipe-to-pipe, etc.)

It is clear that confusion still exists in this area... more work neeeded.

Java Pet Store as a BPEL Orchestration

Recently, I've been working on rewriting the classic "Java Pet Store" application as a BPEL orchestration. It has been a great exercise to understand how one might develop entire applications using a service based model. The application ties together a variety of services (Presentation Services, Logic Services, Data Manipulation Services, Data Persistence Services, etc.)

Now, to make the effort fun, I decided to use an all .Net orchestration engine (OpenStorm) and to utilize services written in Java (on the J2EE model). What I am finding is:
1. The granularity of the J2EE model is currently too fine grained to be mapped directly to a service based architecture
2. The J2EE programming model is "location aware", that is, it has been designed with 'tiers' in mind
3. The concept of "Location Transparency as an Aspect" is still in infancy
4. The UML Sequence Diagram may be used to create a candidate architecture for a service based application
5. MOF, or some other meta data facility MUST be a key component of the fabric

I'll dive into each of these items later.

Can it be done? Yes.
Will it be 'clean'? Hmmm... parts of it will, parts of it won't.
Will it be fast? I think it will be fast enough, but hopefully TSS won't benchmark it ;-)
Will it be agile? Absolutely.

Consulting in Web Services is up...

I don't need Gartner to tell me that more companies are buying consulting around web services - I just ask my sales team. And the news is good. More and more companies are calling us to kick off engagements.

The majority of what we are seeing right now is actually driven by the web service vendors. Companies that supply web service platforms, networks, security, transformation and management platforms have been asking us to help with client engagements. This is great news. It means that the product vendors are selling their products and the engagements are large enough to bring in hired guns.

We are also seeing new engagements where we are helping companies:
- Define a roadmap for becoming 'service oriented'
- Evaluate web service vendors & packages
- Integrate systems using web service technology
- Define corporate standards, policies and procedures around web services
- Educate internal staff on web service technologies

The most interesting area where we are getting involved is in helping companies create whole new methodologies around what we call a "Business Driven Architecture". Here, we discuss business strategy and measurements. This moves into identifying key business processes that they would like integrated / automated. We then spend time creating new artifacts to describe Digital Process Execution. From here, we create a service network to act as a substrate. Lastly, we 'service enable' legacy applications and orchestrate them to support the desired 'to be' business process.

It really feels good to give customers a BPM solution that is built the *right* way.

Invasive vs. Non-Invasive Architectures

must a fabric be invasive?
can bpel avoid it?

If we standardize the concerns and remedies and interfaces, can we commoditize the fabric?

The Service Fabric

Here is my first attempt at defining a Web Services Fabric:

Definitions
Concerns are the non-functional requirements (ilities if you will) - Scalability, Availability, etc.
Remedies are architectural components that attempt to resolve the concerns (clusters, etc.)

---
Every architecture has multiple components (database, presentation server, etc.)

Every architectural component has concerns (scalability, availability, security).

And every concern has at least one remedy (scalability is remedied by load balancing).

Every remedy has its own concerns (the load balancer must be secure).

And the concern to a remedy has at least one remedy (the load balancer will use secured authentication)

---
When the remedies to concerns leverage other remedies within the architectural circle, a consistent architectural fabric is created.

Service oriented architectures have the potential for creating such a fabric.

A service fabric is an integrated set of services that utilize each other to satisfy their architectural requirements.

Webify comes out of stealth

Webify, a company headed by Manoj Saxena (formerly of Exterprise; acquired by CommerceOne) has come out of stealth mode.

The company vision statement states:
"The promise of the Internet is an open e-business platform where companies can do business spontaneously with anyone, anywhere, anytime. Business Services Networks fulfill that vision.

We envision every company publishing standards based business services and processes that customers and business partners can discover and self-provision into their own business processes with a few clicks of a mouse. Companies will build on each other's services, creating new loosely coupled applications and industry-transforming, network-centric business models."

Webify is Austin based - and a neighbor of mine. I had a chance to speak with Manoj a few months back and I think he gets it. It is interesting to see that he is bypassing the 'chasm' theory though. I'll have to ask him why he is attacking FiServ, Health & MFG all at once.

It is also interesting to see how much they are basing their products around BPEL (and J2EE). I anticipate this to be a trend for some time to come. Webify has also had to harden the current IBM implementations to include early versions of reliability, security, isolation, etc.

I look forward to following their progress.

Blue Titan in WSM Fabric Space

I had heard of Blue Titan from their web advertisements but had lumped them into the 'web service management' space along with AmberPoint and friends. Their more recent product literature describes their offering in the 'web service fabric' space - which really is a distinct category.

According to the Blue Titan literature, the 'fabric' facilitates the following functions:
- Register web services
- Associate policies with services (security, management & monitoring)
- propagate policies to endpoints for enforcement
- Capture endpoint runtime execution information, report data
- Feed statistics from endpoints back into the process, repeat as needed

Now, I haven't used the product - but it looks like it sits on top of Web Logic and leverages an Oracle database. This means that it is more than just 'a set of libraries'. It has a library that a service designer would incorporate into their services and it has servers. It is a full blown closed-loop web service management enforcement product.

So, why would they call it a 'fabric'? My best guess is that unlike other products the service management substrate must be built into the software that you are building. It is not an add-on (servlet filter) or a bump on the network (promiscuous sniffer). By providing a library, they are able not only to listen and monitor, but also to control and resolve. Assuming I got the product concept right - it sounds like a good idea.

This raises an interesting question, "what is a service fabric?" I'll attempt to answer that later, for now I think it is safe to say that a fabric must be integrated into the code / services that the developer is writing. It isn't a passive bump or a container. It is an integrated library. Can the library depend on other well known servers / services (or must it be fully encapsulated)? In my opinion the answer is that it can (and often will) have outside dependencies that will be described via WSDL.

For now, I am going to call the Blue Titan offering a 'fabric based web service management platform'. This will distinguish them from the passive bumps and those that monitor via the run-time container (vm, app server, etc.). It is also clear that 'web service fabric' is too open-ended. The Blue Titan offering has some overlap with the TME GAIA, but I would not consider the two direct competitors.

Defining the ESB (Enterprise Service Bus)

The ESB or Enterprise Service Bus seems to be the acronym of the quarter. I've been debating some ways to describe the ESB, here are some of my attempts:

"It is a means for a message queue company (like Sonic and Spirit) to make it seem like they do web services when they really spent the majority of their time doing JMS based queues."

or

"It is a cool sounding buzz-phrase that will lure not-so-smart software developers towards a Java API that sounds like it has something to do with web services. On occassion, they will re-describe the JMS API via WSDL!!!"

or

"Queuing companies realized that the message queue was essential in an asynchronous, document based service oriented network - thus, they created a cool phrase that steals from three predecessors ("Enterprise" from J2EE, "Service" from SOA, and "Bus" from either CORBA or hardware buses)."

Just kidding of course... but I do think it is a dumb term. For goodness sake, A BUS? Has anyone ever looked at the topology of a service network? :-)

Web Services Package for Mathematica

See:
http://www.wolfram.com/news/webservices.html


May 29, 2003--Wolfram Research is inviting users to try the beta version of its new Web Services Package, which allows users to interact with web services in Mathematica. With Web Services Package 1.0, Mathematica users can dynamically access new data and functionality located on the network, creating an automatic extension to the Mathematica environment. The release of Web Services Package is yet another demonstration of Wolfram Research's commitment to providing freely available, cutting-edge technology and support to fulfill the needs of the Mathematica community.

Commentator comments on BPEL

Kendall Grant Clark made some comments on BPEL. I think he has some valid points around the fact that BPEL isn't the only player or final player in the Web Service Based Integration space. See:
http://webservices.xml.com/pub/a/ws/2003/07/08/ws-deviant.html

WSE 2.0 Technology Preview Released

See:
http://microsoft.com/downloads/details.aspx?FamilyId=21FB9B9A-C5F6-4C95-87B7-FC7AB49B3EDD&displaylang=en

"WSE 2.0 Technology Preview builds on the security, routing, and attachments capabilities with new features including a policy framework, enhanced security model, message-based programming model, and support for multiple hosting environments. "

Databases & SOA

Sean McGrath & John McDowall have touched on a subject that is important to me - the use of the dbms in the soa. Yes, one of my first jobs was working for an RDBMS vendor on the mainframe (Must Software - Nomad). Everything we did was based on the relational model. Everything COULD be done via a database (if we wanted to). Hell, you want two applications to share data?? Stick it in the database!!! We preached Boyce-Codd normal form, we used terms like "sargable predicates" and "shippable selects" - we were cool.

Well, we ended up misusing the database and creating ER-models that glued everything together. Later, the middleware people (CORBA, EJB) figured out how to front-end these meshed data-spaces with services, but they didn't actually un-screw the data normalization problem. The fact is that we use surrogate keys and auto-gen id's because they are efficient for the dbms and they are easier to use in our SQL. However, generally they are vendor specific and implementation specific. We all know that "Data Coupling" is the exposure of internal data to the external world, leading to the coupling of two distinct systems (failure to encapsulate internals). Want to see something funny? Take a look at the sForce web services api and see how they dealt with the issue. Ask yourself these questions:
1. Did they expose internal database Id's to the outside world?
2. Do they provide any queryable artifacts to access the constraints (e.g., I need a Customer record before I can insert a Customer Order record)
3. Do they provide ER-Diagrams (data view) or some new service view (activity / sequence) diagram?

After you look at these questions, you can begin to see some of the problems that will be surfacing in providing external access to internal data. The art of service enabling the db is still early - let's learn from sForce and advance the art.

Web Service Frameworks (WSF)

I have a strong interest in web service frameworks. In general, I am of the opinion that the WSF is where MS & IBM wil have their next major battle. So, they HAVE to agree on a certain sub-set of functionality (those concerns which must be remedied at the protcol level), but beyond protocols, the field is open and the battle will begin shortly.

Right now, Sun has a set of api's that they call J2EE (JMS, JNDI, etc.) They expose each of these api's in a "java only" format. Microsoft has a similar set of api's on the .Net side. In my opinion, we will quickly be moving to the exposure of technical architectural elements as web services (web services front ending LDAP, web services front ending databases, etc.) We will also see web services frameworks for horizontal domains (accounting, crm, etc.) and vertical domains (insurance, travel, etc.) Each of these horizontal and vertical frameworks will have to pick a substrate layer to work with.

One of the more interesting web service frameworks is GAIA from TME. I like the fact that TME knocked out a quick impl of a soap engine (glue) and are quickly moving into the substrate. They are looking at the world from a set of concerns (scalability, availability, deployability) and identifying remedies (balancing, resilience through redundancy, etc.) Many of the problems that GAIA takes on are concerns that either were done in proprietary hardware (cisco stuff) or concerns that were handled in a monolithic app server (availability through clustering). I am a huge fan of re-addressing these remedies via a consistent web services approach. Using a balancing web service, or a caching web service inside of an orchestration makes a lot of sense.

Other frameworks have popped up, but at a higher level. One such framework is the sForce web services api from salesforce.com. The sForce api is early. It provides some real basic services (insert, update, delete, change password, logon, etc.) You can really view this framework as a "data service" framework - and from this perspective, it does the job. Their choice to use a significant amount of abstract data types (records & maps) facilitates versioning and adding new data fields easily, but has the trade-off of potentially introducing typing errors at run-time. Sidenote: This framework looks a lot like the old MS My Services (aka Hailstorm).

Web service frameworks are now emerging. It shouldn't be long before MS & IBM throw one (or several) out. It will be nice to move beyond protocol crap (ws-boring, service substrate) and into value-add.

WS-Federation Released

Just caught this:
http://msdn.microsoft.com/webservices/understanding/gxa/default.aspx?pull=/library/en-us/dnglobspec/html/ws-federation.asp

Haven't had time to read it, but it looks like it competes with the old Project Liberty stuff; that is, distributed realms of trust. It is part of the larger security profile (ws-security).

Martin Fowler notes some enhancements in UML 2.0

See:
http://martinfowler.com/bliki/Uml2.html

"Time Coupling" Doesn't Exist

Recently, several people in the web services circles have stated that, "synchronicity affects coupling". More specifically, the belief is that synchronous behavior creates a more tightly coupled scenario. Some refer to this concept as, "coupled in time". My belief is that, "time coupling" doesn't exist.

I believe that coupling deals with one participants desire to leverage pre-existing knowledge about another participant’s internals. For example, two services are tightly coupled if one service makes assumptions about another services data or logic that are not obtainable from the interface. Thus, service encapsulation is violated and the two services become more tightly coupled.

One of the coolest things about services is that they can be piped into an intermediary (another service) on the way to the destination. These intermediaries can do neat things like:
- switch the characters from ASCII to EBCDIC (data transformation)
- re-route the message (network transformation)
- switch from a synchronous protocol to an asynchronous protocol or vice versa (timing transformation)

Items (data, routes, timing, etc.) that may be "morphed" or "transformed" en-route to delivery are not issues related to coupling. They exist between interfaces and do not violate encapsulation. In dealing with synchronicity one must be careful; it means different things to different people. For instance:

1. I made the call using an asynchronous protocol, but blocked for the result.
2. I made the call using a synchronous protocol; an intermediary picked it up (synchronicity facade), and re-sent it as an asynchronous message, then correlated it back to me.
3. I made the call using a synchronous protocol, but spun the call off in a new thread (client side handler), thus it didn't block.



So, a service may have stated that, "I use a synchronous HTTP only"... but the fact is the client (consumer) just plain didn't care. Synchronicity can be morphed because it lies outside of the encapsulation boundary. Synchronicity can be decoupled as a concern. In no way does synchronous behavior adversely affects the loose coupling of services. "Time Coupling" doesn't exist.

Web Services White Papers

You can find the abstracts here:
http://www.jeckle.de/ws-rsd/abstracts/

You'll have to google by topic - most of them are on CiteSeer.

Java BluePrints - Designing Web Services

Draft chapters of the J2EE team's new BluePrints book.

Chapters 1, 2, 3, and 5 from the book:

Chapter 1 - Introduction (pdf, 172kb)
Chapter 2 - Standards and Technologies (pdf, 205kb)
Chapter 3 - Service Endpoint Design (pdf, 205kb)
Chapter 5 - XML Processing (pdf, 451kb)

See:
http://java.sun.com/blueprints/guidelines/designing_webservices/

Books I bought from Amazon (2002 & 2003)

Amazon has a nice feature where you can view your entire purchasing history. Here is mine:

Order date June 08, 2003
1 of: OSS Essentials: Support System Solutions for Service Providers

Order date July 12, 2002
1 of: Dictionary of Insurance Terms (Dictionary of Insurance Terms, 4th Ed)
1 of: Insurance Technology Handbook
1 of: Business of Insurance: A Comprehensive Introduction to Insurance

It was interesting for me to see that I am using Amazon less than I used to. I think that I'm continuing to buy the same number of books as always - but, apparently I am now going to the bookstore, enjoying a cup of coffee (and getting out of the house). It is also interesting to see that for the last couple of years the books that I've purchased are more industry focused (Insurance, Telecom, etc.)

Books I bought in 2001 (Amazon)

2001 was an interesting year - lots of reading on natural language, inference engines, distributed transactions, P2P and a variety of other AI mechanisms:

Order date September 23, 2001
1 of: Speech and Language Processing: An Introduction to Natural Language Processing, Computational Linguistics and Speech Recognition
1 of: Wordnet : An Electronic Lexical Database (Language, Speech and Communication)
1 of: Foundations of Computational Linguistics : Man-Machine Communication in Natural Language

Order date April 11, 2001
1 of: Principles of Distributed Database Systems
1 of: Data Replication : Tools and Techniques for Managing Distributed Information

Order date March 31, 2001
1 of: Peer-to-Peer : Harnessing the Power of Disruptive Technologies

Order date March 04, 2001
1 of: An Introduction to Kolmogorov Complexity and Its Applications (Graduate Texts in Computer Science)
1 of: Fluid Concepts & Creative Analogies : Computer Models of the Fundamental Mechanisms of Thought
1 of: Applying Case-Based Reasoning : Techniques for Enterprise Systems

Order date February 06, 2001
1 of: First Order Mathematical Logic
1 of: First-Order Logic
1 of: An Introduction to Support Vector Machines : And Other Kernel-Based Learning Methods
1 of: How to Solve It : Modern Heuristics

Order date January 21, 2001
1 of: The Tipping Point : How Little Things Can Make a Big Difference
1 of: Cognitive Science : An Introduction
1 of: Introduction to Neural and Cognitive Modeling
1 of: Common Lisp : The Language

Order date January 20, 2001
1 of: Artificial Intelligence: A Modern Approach

Books I bought in 2000 (Amazon)

2000 was also an interesting year. More readings on AI, parallel computing, video compression and interactive tv. You can also see some of the board of directors stuff sneak in there.

Order date December 18, 2000
1 of: The Channel Advantage : Going to Market With Multiple Sales Channels to Reach More Customers, Sell More Products, Make More Profit
1 of: The Channel Advantage: How Top Companies Connect with Their Customers

Order date October 26, 2000
1 of: Neural Networks for Pattern Recognition
1 of: Compilers : Principles, Techniques, and Tools
1 of: An Introduction to Genetic Algorithms (Complex Adaptive Systems Series)

Order date October 01, 2000
1 of: Introduction to Probability Models
1 of: Techniques and Standards for Image, Video, and Audio Coding
1 of: Foundations of Multithreaded, Parallel, and Distributed
1 of: Introduction to Parallel Algorithms (Wiley Series on Parallel and Distributed Computing)
1 of: Introduction to Data Compression, Second Edition

Order date September 16, 2000
1 of: Handbook of Image and Video Processing
1 of: Computer Vision and Applications: A Guide for Students and Practitioners (With CD-ROM)
1 of: Computer Vision and Human-Computer Interaction
1 of: Dynamic Vision : From Images to Face Recognition (Image Processing)

Order date August 16, 2000
1 of: Basic Physics : A Self-Teaching Guide (Self-Teaching Guide)
1 of: Perpetual Motion (New Canadian Library Series)

Order date July 02, 2000
1 of: Harvey Penick's Little Red Book : Lessons and Teachings from a Lifetime in Golf
1 of: Ben Crenshaw - The Art of Putting
1 of: The 8-Step Swing by Jim Mclean

Order date June 18, 2000
1 of: An Embedded Software Primer
1 of: The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary (O'Reilly Linux)

Order date May 26, 2000
1 of: The Inside Story of Interactive TV and Microsoft Webtv for Windows
1 of: Residential Broadband : An Insider's Guide to the Battle for the Last Mile
1 of: Cutthroat : High Stakes & Killer Moves on the Electronic Frontier
1 of: OpenCable Architecture (Fundamentals)

Order date May 06, 2000
1 of: The Essential Guide to Digital Set-Top Boxes and Interactive TV
1 of: The Cluetrain Manifesto : The End of Business As Usual
1 of: Web Development with JavaServer Pages

Order date March 09, 2000
1 of: 21st Century Corporate Board
1 of: Your Roles and Responsibilities As a Board Member (Carverguide Series on Effective Board Governance, 2)
1 of: Chairpersons Role As Servant Leader to the Board
1 of: Planning Better Board Meetings (Carver, John. Carverguide Series on Effective Board Governance, 5.)
1 of: Board Assessment of the Ceo (Carverguide Series , No 7)
1 of: Strategies for Board Leadership (Carverguide Series on Effective Board Governance, 10)
1 of: Boardroom Basics: A Pocket Guide for Directors

Order date February 13, 2000
1 of: Building a Career Development Program : Nine Steps for Effective Implementation

Order date January 04, 2000
1 of: Essential Guide to RF and Wireless, The
1 of: Programming Applications With the Wireless Application Protocol : The Complete Developer's Guide
1 of: The Art of Systems Architecting (Systems Engineering Series)
1 of: The Cell Phone Handbook : Everything You Wanted to Know About Wireless Telephony (But Didn't Know Who or What to Ask)

Books I bought in 1999 (Amazon)

1999 looks like a pretty good mix between business and technology (Java & UML):

Order date December 14, 1999
1 of: Document Management for the Enterprise : Principles, Techniques, and Applications

Order date December 03, 1999
1 of: Solaris Guide for Windows NT Administrators
1 of: Sun Performance and Tuning: Java and the Internet
1 of: A Practical Guide to Solaris

Order date November 30, 1999
1 of: The Strategy and Tactics of Pricing : A Guide to Profitable Decision Making
1 of: Power Pricing : How Managing Price Transforms the Bottom Line

Order date October 17, 1999
1 of: The Return of Depression Economics
1 of: Business Cycles : Durations, Dynamics, and Forecasting

Order date September 07, 1999
1 of: Acts of War : The Behavior of Men in Battle
1 of: On Killing : The Psychological Cost of Learning to Kill in War and Society
1 of: Nineteen Stars : A Study in Military Character and Leadership
1 of: Follow Me I : The Human Element in Leadership

Order date June 27, 1999
1 of: Understanding and Deploying Ldap Directory Services (MacMillan Network Architecture and Development Series)
1 of: Implementing Ldap

Order date June 24, 1999
1 of: Inside Java 2 Platform Security: Architecture, API Design, and Implementation
1 of: Enterprise JavaBeans

Order date May 21, 1999
1 of: Enterprise Javabeans : Developing Component-Based Distributed Applications

Order date May 02, 1999
1 of: Practical Guide to Structured Systems Design (Yourdon Press Computing Series)

Order date April 25, 1999
1 of: Specification of Software Systems (Graduate Texts in Computer Science (Springer-Verlag New York Inc.).)
1 of: Gems of Theoretical Computer Science

Order date April 01, 1999
1 of: The Unified Modeling Language Reference Manual (Addison-Wesley Object Technology Series)
1 of: The Object Constraint Language : Precise Modeling With Uml (Addison-Wesley Object Technology Series)
1 of: The Unified Modeling Language User Guide (The Addison-Wesley Object Technology Series)
1 of: Rational Unified Process (Addison-Wesley Object Technology Series)

Order date March 30, 1999
1 of: Pattern Languages of Program Design 3 (Software Patterns Series)
1 of: Pattern Languages of Program Design
1 of: Pattern Languages of Program Design 2

Order date February 06, 1999
1 of: Pricing Strategy : An Interdisciplinary Approach

Order date January 04, 1999
1 of: The Pims Principles : Linking Strategy to Performance
1 of: The Economics of Strategy
1 of: Competitive Advantage : Creating and Sustaining Superior Performance

Books I bought in 1998 (Amazon)

1998 looks like it was mostly about business strategy with a bit of planning thrown in as well:

Order date December 02, 1998
1 of: The Mind of the Strategist : The Art of Japanese Business
1 of: Competitive Strategy : Techniques for Analyzing Industries and Competitors
1 of: Competitive Intelligence : How to Gather, Analyse, and Use Information to Move Your Business to the Top

Order date November 17, 1998
1 of: Cases in Competitive Strategy
1 of: Levers of Control : How Managers Use Innovative Control Systems to Drive Strategic Renewal

Order date October 29, 1998
1 of: Inside the Java Virtual Machine (Java Masters Series)

Order date October 17, 1998
1 of: The Rise and Fall of Strategic Planning : Reconceiving Roles for Planning, Plans, Planners
1 of: The Balanced Scorecard : Translating Strategy into Action

Order date September 16, 1998
1 of: The Art of Strategy : A New Translation of Sun Tzu's Classic, the Art of War
1 of: Developing Business Strategies
1 of: Contemporary Strategy Analysis : Concepts, Techniques, Applications

Order date September 08, 1998
1 of: Portfolio Management for New Products

Order date September 06, 1998
1 of: Say It With Charts : The Executive's Guide to Visual Communication

Order date August 29, 1998
1 of: Marketing Management : Analysis, Planning, Implementation, and Control (9th)
1 of: The Market Planning Guide : Creating a Plan to Successfully Market Your Business, Products, or Service
1 of: Advertising Campaign Planning : Developing an Advertising-Based Marketing Plan

The Best Book on Designing Web Services

I've spent too much time in book stores looking for good books on software design (including SOA and web services design). Yet the one book that I find myself most frequently referencing has been on my bookshelf for years, it is:
"The Practical Guide to Structured Systems Design"

The first thing you'll note is that the book was published in 1988.
The second thing that you'll note is that the book never mentions web services, service oriented architectures, XML, etc.

What you will find is some clear, actionable information on modular design, cohesion, coupling and design strategies. Is it a bit dated? Sure - but many developers are designing modular services for the first time. The book clearly explains data coupling, stamp coupling, control coupling, common coupling and content coupling. Well done!

Synchronicity and Coupling

Are synchronous calls more tightly coupled than asynchronous? If so, why?

Consider this; in an asynchronous call I have to deal with an extra piece of information: a message correlation token (extra requirements adds to coupling). So, that's bad, right? Yes, it is - but it isn't a big issue - deal with it.

If I'm trying to keep the conversational requirements to a minimum, then wouldn't I be better off not stating a preference (agnostic synchronicity)? The very fact that I state a preference increases the coupling level, right? (additional requirements = higher coupling) Yes, it does - but convince the programmer to design an application where you don't know the synchronicity requirements. But all that shouldn't matter. The "ubiquitous protocol" stack (girthy as it may be) will abstract me from the considerations related to "protocol coupling" (correlation in the WS stack), right? Yes, the (semaphore / clock / correlation) issues will be factored into the protocol. Hence, we are having a moot discussion.

Ok, --- try this on: I reduce coupling (and increase flexibility) if I break up the transmission paths of a request/response message exchange pattern (mep). This is to say that I have stated that, "I don't care who sends me the result back". In a synchronous call, the implication is that the ultimate receiver doubles as the ultimate sender on the return path. Not so in an asynchronous conversation. Thus, I increased flexibility by stating that I don't care who sends me the return message. And you could argue that by adding to the **I don't care** attitude, I have decreased coupling.

Some might argue that long running transactions are facilitated by asynchronous calls. I believe that this is an implementation issue and not directly an issue of coupling. LRT's can be hydrated and dehydrated to maintain high performance. I will argue that synchronicity has very little impact on coupling. Now, I will also argue that synchronicity has a SIGNIFICANT impact on distributed computing performance. The ability to take a request and spawn it off to some other agent and have it return the results on your behalf is powerful (alternate return path). The ability to receive 1,00,000 request, sit on them for 72 hours (LRT's) and respond without your system blowing up is powerful as well. The ability to use SOAP over HTTP on the in-bound call and switch to SOAP over SMTP on the out-bound call is also powerful. All good things, but are they related to coupling?

I've been sitting on this blog for over a month now. The question I keep posing to myself is, "do synchronous calls increase coupling levels", and the answer that I keep coming back to is, "they do, but by such a small amount that you shouldn't care - however, synchronicity can DRAMATICALLY affect system performance and flexibility".

I've also landed on, "who cares". So what if synchronicity is a performance/flexibility issue and not a coupling issue. The point that people are making is that you have to strongly consider synchronicity in your distributed architecture. The real goal is to make your systems work with your business partners while not requiring a fleet of mainframes to make the system perform. I just don't want people to get in the habit of throwing too many things in the "coupling bucket", when they are actually more strongly related to other non-functional aspects of distributed systems design.

Am I right? Honestly - I'm still not sure.

MS RTC and SOAP?

Surely, Microsoft will use their new "Real-Time Communications Server 2003" at the heart of their office messaging infrastructure., see:
http://www.microsoft.com/office/preview/rtcserver/default.asp

The RTC Server uses ietf standards like SIP for session control, SIMPLE for presence detection (am I sitting at the computer) and RTP for transmitting the data (most likely over UDP, potentially on top of TCP) and RTCP for controlling the flow.



What seems to be missing is the SOAP binding to RTP.

This seems a bit too obvious. Perhaps we will see an "enterprise" version that is shipped with the binding and resolves SIP addresses to WS-Addressing addresses. Don't know.... if anyone out there knows, shoot me a note.

MS has a good whitepaper on the technology.

Prediction: Microsoft will Acquire BEA

O.K. --- this one might seem like a stretch, but I'm going for it. Within 12 months, Microsoft will acquire BEA Systems.

Why?
1. MS isn't concerned about competing against IBM at the SMB level. IBM has never been able to compete in organizations under 1,000 employees and that isn't going to change soon. However, BEA does compete in this space - and they are a pain in the ass to MS.
2. MS doesn't care about languages or vm's. It's a moot point in the web service world. In MS-land, they want you to buy their service framework (personalization services, commerce services, content mgmt services, industry services (HL7, CPFR, etc) from MS. They really don't care what silly language the service was written in. Who cares about the language?
3. Well, the MS customers care about the language. Enterprises just trained thousand of employees in J2EE. MS is ok with this. Program your home-made extensions in Java, perl or whatever else. Expose them as web services and make them work with the new MS Service Framework.

Does it sound like the service oriented model is an "embrace & extend" play on the platform? It should. It is.

At the end of the day, MS is a money making machine. They don't let silly things like languages or platforms get in their way. They will find a way to do what their competition won't do. MS would be able to say, we have the best Java platform and the best .Net platform - - and, we've weaved them together with web services -- -- so, why would you buy from IBM??? It's about the customer, remember?

Is sForce a Web Service Provider?

As I read through the sforce description (for the third time), I realized that Salesforce.com was attempting a hybrid WSP offering. In essence, they were going to offer:

1. ISP services (a hosted infrastructure, bundled)
2. WSP Extensions (Tooling like WebLogic and .Net services)
3. Horizontal WSP offerings (their SFA, plus partner offerings)
4. Horizontal WSP Service Framework (their base utility services)






What seemed missing from the sforce picture was the "base WSP" offering. That is, the whole infrastructure around creating a managed web services offering up. I'll have to dig deeper, but the initial documentation focuses on building custom applications (SFA-ish) using services.

After talking with some of the sForce partners, I got the feeling that they didn't really understand what sForce was all about. Personally, I think it's an interesting idea, but it seems like they missed the whole "common infrastructure" part of the problem. Perhaps they'll circle back?

WS-EndpointResolution

In the telecom world, people refer to the difficulties of getting high capacity lines (like fiber) to the home or neighborhood as the "Last Mile" problem.

In software messaging there is a similar problem. Often, there will be a need to send some message to a specific computer. This isn't a problem unless the address of that computer changes (due to DHCP, NAT, etc.) In this case, the address of the computer must be resolved at "received time" rather than at "delivery time". This is an old problem that peer-to-peer systems have had to overcome. However, the problem doesn't end there. In many cases, some application (X) will want to send a message to another application (Y) running on another computer. Using delayed addressed translation, we are able to make sure that the message gets to the right computer. But now, the message must be delived to the right application (MS Word, Excel, etc.) Further complicating the situation, I might have two instances of the same program running (e.g., Excel) - now I need to know which instance of the application the message was intended for.

This is one scenario that WS-EndpointResolution along with WS-Addressing hopes to remedy.
1. Getting the message to the right computer (The Last Meter)
2. Getting the message to the right application (The Last Centimeter)
3. Getting the message to the right instance of the application (The Last Millimeter)

The second scenario is the more general server-side scenario where you are using a dynamic addressing scheme to reroute messages for the purpose of scalability or security. This scenario is mostly handled under the WS-Addressing scheme. Together, WS-Addressing and WS-EndpointResolution will work together to move your SOAP messages to your intended receiver.

Microsoft TechEd Concludes

I got to swing by the Microsoft TechEd for a couple of days. It was a great show - well run - attendance around the 9,000 mark.

I must admit that I was disappointed at the attendance of the web service talks. While excellent presentations like "Reliable Messaging with Web Services" were only drawing handfuls of people, talks like "Excel Macros" were drawing thousands. I guess this is the pyramid effect. Web services won't hit the mainstream until all those "Excel people" need to start using "departmental, service oriented macros" or something like that... who knows, maybe that's the killer app... Excel Macros as Web Services.

Ultimately, I do expect some mainstream app (like InfoPath or Excel) to be the driver for enterprises to get their Service Oriented Enterprise strategy figured out.

The Race is On

Yesterday, Microsoft launched BizTalk 2004 beta. This product facilitates BPEL and web service orchestration.

Today, Salesforce.com launched a new offering that they are calling "sforce". This is a hosted, web services model that allows developers to build applications (or services) and host them at a remote location. The remote location is enabling the developer to leverage some predetermined infrastructure. In this case, sForce will be offering local services for content management, searching, etc. This is what I have been calling a WSP (Web Service Provider). It is interesting to see that the services that the WSP will provide goes beyond metrics, billing and authentication. Please see: http://www.sforce.com/us/

Between these two announcements, I think it is safe to say that this week marks the beginning of the "Software as a Service" era. SalesForce is also calling it the "client/service" model.

The race is on.

Jupiter now BizTalk Server 2004 --> Beta out

Check out:
http://mymsevents.com/MyMSEvents/search.aspx?s=1&keywords=biztalk&keywordtype=3&track=0&speaker=0×lot=0&catFast+Tracks=0&future=0










Also, see: http://www.microsoft.com/biztalk

Which is larger?

Which is larger, Microsoft or the following 41 software & service companies combined (by market cap) :

(Quest Software, Inc. + Tibco Software, Inc. + Documentum, Inc. + Take-Two Interactive + Activision, Inc.+ Hyperion Solutions Corp. + Sybase, Inc. + Macromedia, Inc. + RealNetworks, Inc. + Business Objects S.A. Cognizant Technology Sol. + Red Hat, Inc. + Satyam Computer + J.D. Edwards & Company + Autodesk, Inc. + CSK Corporation + Network Associates, Inc. + Konami Corporation + Compuware Corporation + Trend Micro Incorporated + Cognos Incorporated + Mercury Interactive Corp. + VeriSign, Inc. + Citrix Systems, Inc. + Cadence Design Systems + BMC Software, Inc. + Amdocs Limited + BEA Systems, Inc.+ Synopsys, Inc. + Siebel Systems, Inc. + Check Point Software Tech + PeopleSoft, Inc. + Infosys Technologies Ltd.+ Symantec Corporation + Adobe Systems Incorporate + Intuit Inc. + Electronic Arts Inc. + VERITAS Software Corp. + Computer Associates + SAP AG + Oracle Corporation)

If you guessed Microsoft, you would be correct. Yes Microsoft is worth more than the 41 next largest software companies combined.