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.

Girthy Protocol Stacks

GXA (A.K.A., WS-*) is creating a girthy protocol stack, that is, the distance around the circumference of the protocol stack seems to grow daily.

The girth for the base internet protocol stack was pretty small: UDP, TCP, DNS, etc. - The cohesion within the protocol was high. However, the coupling between the protocols was moderate-to-high. That is, there were a significant number of times when a given protocol called out a "unique binding" rather than calling out "a requirement for a concern".

In the world wide web, the girth was minimal: HTTP, URI, HTML, etc. In the world wide grid, the girth seems to be rather large: SOAP, UDDI, WSDL, WS-Inspection, WS-Transaction, WS-Security, WS-ReliableMessaging, etc.

Girthy protocols worry me only when they are mandatory. If I can choose the specific protocols that I want to use in the stack, rather than having to accommodate each layer in the stack I have increased flexibility and decreased the problems associated with girthy protocol stacks.

Protocols become mandatory when the cohesion between protocols is high. This occurs when a protocol SPECIFIES that you MUST use another specific protocol. This is what I call a "unique binding". It occurs all the time in the web services protocols. Rather than stating that one protocol requires the remedy of some concern (e.g. addressing), the protocol calls out a specification by name. In these cases, we end up creating "protocol frameworks".

The creation of protocol frameworks that are bound and versioned via a profile (like WS Basic Profile) may be required given the state of the art of protocol design. However, as we begin to adopt the ws-* stack we must be aware of the cohesion and versioning issues that will arise in the future.

The World Wide Grid

Well, I finally took the time to write down my thoughts on the future of the Web Service Network. I have taken the liberty to give it a name, that is, "The World Wide Grid" or just, "The Grid".

I hope you enjoy:

http://schneider.blogspot.com/wwg.htm

The Client-Side Platform: Part I

The Conversation
“We just converted the last of our client/server applications to thin-client!” exclaimed a friend of mine at a local Fortune 500 company. “Why?” I asked. “What do you mean why? We changed our architecture to n-tier with application servers and browser interfaces.” To which I could only ask, “Why?”

I could see that I was irritating him, but I thought I’d let him hang for a minute. This was a technically adept, well-paid engineer. He commented, “We went to n-tier because we could reduce our deployment costs. All the applications are now delivered to the clients without requiring p.c. administrators to install them! We can also deliver applications to our business partners over the Internet.”

“Those are all great things. You must be proud. Did you give up anything to accomplish this feat?” I asked. “No, I don’t think so – what do you mean?” he asked. “Well did you increase your server side costs? Did you deliver the application with the same robust user interface that you had in the client/server world? If I remember correctly, the client/server version used to connect to a bar-code reader on the pc, was that hard to do in HTML?”

Now he was aggravated. I had just pointed out three things that were worse in the new system that he preferred not to talk about. Conversations similar to this one are popping up in virtually every Fortune 500 I.T. shop. Why did we compromise on so many items? The answer is simple; the immediate advantages of the browser out-weighed any other solution that was presented at that point in time.

The Browser
The web browser was designed to enable a simple method for linking information across physical locations and rendering structured documents. These goals were met with overwhelming success. The browser was so successful that people began thinking of it as the sole method of sending and receiving information. Even other traditional applications like email were redesigned for this new model. It was apparent that the software designer could kluge just about any piece of software to work in this paradigm. As time went on, the software community began to realize that stuffing every application into the same architectural model would not adequately serve the needs of the user or the engineer. The intentions behind the web browser were noble. No one could have predicted that an entire generation of developers would have attempted to transition all of their programming needs to this new model. Had they, the browser would surely have a different design.

Before the browser we had some pretty powerful features: robust user interfaces, access to local peripherals, client-side computing and storage, etc. Plenty of sophisticated features were traded for the promise of ubiquitous graphical rendering. Well, today we have ubiquitous rendering but none of the other features that developers consistently need at the client. We have tried to remedy this issue but met with limited success. The Java applet failed to achieve significant success due to the limited support in the Microsoft Internet Explorer browser, while the ActiveX control remained ridden with security issues.

Clean Sheet of Paper
Developers are now re-thinking the role of the browser. What would client-side computing look like if you had a clean sheet of paper? Should it be the primary mechanism for delivering fat client side code? Should it always be a client and never a server? The answer to these vatic questions are leading many to believe that the client may be ready to undergo yet another major transformation. No one is suggesting that we do away with the browser, rather that we use it for what it was originally intended to do, rendering structured documents with hyperlinks.

The new goal is to balance a few simple concepts:
· I need continued access to my thin-client applications and web sites. Anything that I had in a browser I want to continue to have!
· Sometimes I work offline and I should be able to keep working when I’m not connected to the network.
· I need to communicate and collaborate with co-workers and business associates, often in real-time.
· I don’t want complicated installs nor does my I.T. department want to roll out new applications.
· Some personal information I’d like to keep on my computer rather than at a remote server.

Client Side Platforms
Five years ago I.T. shops were against adding anymore to the client than was absolutely needed. Today, as CPU performance is skyrocketing and disk and memory prices plummeting, there is a less emphasis on the hardware restrictions and a renewed interest in delivering more robust applications to the user. Also, software developer are tired of cursing HTML, trying to make it do things that it was never meant to do.

Returning many of the basic features that we had before browsers is the goal of the next generation of client side platforms. The CSP is really not a new concept. The CSP is merely a combination of those technical features that software developers need when writing client-side systems, while stressing strong (yet loose) integration between those components.

(more coming soon...)

Patricia Seybold on BPM and SOA

Patricia Seybold, suggests:
"Beware of Business Process Management: Be Careful about Adopting Internally-Driven Business Processes; Instead, Design a Customer- Adaptive Enterprise Using a Services-Oriented Approach"

http://www.psgroup.com/doc/products/2003/5/PSGP5-8-03CC/PSGP5-8-03CC.asp

ZapThink reports on the professional services space

ZapThink has released a new report on consulting firms that specialize in web service and service oriented architectures, see:
http://www.zapthink.com/reports/ZTR-WS109.html

I was happy to see Jason use the term, "Service Oriented Enterprise"... now, if I can only get the World Wide Grid to catch on :-)

Jim Waldo is still ticked off

Jim Waldo is a smart man. Sit down and talk with him and you'll quickly realize that he spends a significant amount of time thinking about software and distributed computing. Jim was early into distributed systems with CORBA and more recently led the Jini effort at Sun. For those of us that know the Java specs - we all know that Jini was one nice piece of software. We also know that it wasn't widely adopted. And Jim is still ticked off.

Most recently, Jim took aim at the use of standards:
http://www.artima.com/weblogs/viewpost.jsp?thread=4840

When I last talked to Jim, he was pissed off at the JXTA group for getting both the attention as well as getting the internal Sun research dollars. In "Waldo-World" everything can be done inside of Java! No need to worry about all that "other stuff" (RPG, COBOL, .Net, etc.) In my humble opinion, Jim is smoking dinosaur dope.

Communications (a superset of distributed computing) is based on ubiquitous protocols. Why do we have them? Uh, to speed up adoption and to make all of the "unique" things in the world (including Jini) actually talk to each other. Does it slow down innovations? Yes sir. Does it make inter-application, inter-department, inter-business, inter-nation computing possible? Yep.

Jim has a ton to offer the web services community. If he would quit ragging on standards, reverse engineer Jini and publish it in terms of open standards - I would back him 100%. Until then, good luck with Jini. FYI, my Jini book sits on my bookshelf right between my CORBA books and my DCE books.

The Burton Group on Web Services

See:
http://www.burtongroup.com/promo/columns/column.asp?articleid=145&employeeid=3

"There really isn’t a big mystery as to why the Web services framework—the standards that define an XML-based distributed computing architecture—have gained a credible foothold so quickly. Competitive pressures, the need to reduce costs, and a variety of other business factors are driving enterprises to integrate business processes and IT. Enterprises are creating both internally and externally facing systems that tie employees, customers, partners, suppliers, contractors, and other constituents into their business processes, for example."

Phil Wainewright Kicks ASS

I just finished reading the Loosely Coupled blog - and I realized that Phil kicks ass... and that's all I have to say about that. :-)

Web Service Stack Implementations in the OS

Although it isn't clear, it appears as though Microsoft will embed the web service protocol stack right into all of their many operating systems. Their release of the WSE as an add-on library, and it's relationship to IIS suggests that Microsoft feels that (like everything else) web services should be close to the kernel. Usually, I disagree with their monolothic OS thinking, but this time I tend to agree.

If MS does this, it may force others to follow suit, namely Linux and other branded Unix flavors. This may cause a problem for IBM, BEA and other companies that want to sell you an application server (with web service enhancements). If MS drops the WS stack in the OS, this may cause IBM do to the same and then the Linux flavors may have to get in the game as well. I'm no rocket scientist, but this doesn't sound like good news for BEA and the other web service platform vendors. They would have to claim that either they had a superior implementation of the stack or rely on sales from the tooling (IDE, etc.) - which is a tough business. I also anticipate OEM relationships between groups like RedHat and groups like Systinet, Cape Clear and The Mind Electric...



I'm no Kernel specialist, but wouldn't the X-Kernel architecturesupport the WS-* stack?

WS-Choreography Can't Differentiate

So, I'm sitting here reading the meeting minutes from the W3C WS-Choreography, see:
http://www.w3.org/2002/ws/chor/3/04/29-minutes.html

and they can't seem to figure out what they are doing that has any value. They seem to have realized that just about everything they dream up has already been covered by BPEL or BPSS... yet they seem hell bent on keeping a working group together - from what I can tell, the purpose of the working group is to determine the purpose of the working group. I can only assume that the people that participate in this group don't like real work and would rather participate in a completely irrelevant working group.

Personally, I'll go with BPEL. As the W3C participants debate what ws-choreography is - my company has finished our orchestration implementation of BPEL Now we are moving on to finding snafu's and areas for improvement that can be fed back into the spec...

If it sounds like I think the W3C is dicking around with specifications that have already been written - you are right. KILL THIS WORKING GROUP.

XML 2002 presentations

I just ran across the XML 2002 presentations:
http://www.idealliance.org/papers/xml02/slides/index.asp#s04-02-05

For your viewing pleasure...

Service Oriented Aspects - or - Aspect Oriented Services

I had a great conversation yesterday with one of the IBM guys. He was very excited about aspect oriented programming, while I was promoting the service-oriented model. As we got deeper into the conversation, we realized that the concept of aspects were very applicable in the service oriented world.

In the SOA, we "apply" new functionality or "aspects" to a service via one of several mechanisms. For talking purposes, let's use the "logging" example. That is, an aspect that can be applied across a set of objects (or services) that log all the calls.

There are several ways that we can add functionality. Perhaps the most straight forward in the service oriented world is by using the pipe & filter. Here we simply pipe the output of our primary service into a new service (like logging) - and we've created a discrete, assembly line approach to adding functionality. The down side is that the each participant in the pipe chain must be explicitly called and the programmer is exposed to a significant amount of raw details that they may wish to avoid.

A second method for performing this feat is to create a "tightly coupled web service" - here we just hard code the stuff right into the web service. So service 1 is hardcoded to call service 2 (logging). Perhaps not the best idea, but likely the most common means in the first go-round of creating web services.

A third method is to describe the functionality at the protocol layer. Take WS-ReliableMessaging, this information gets baked into the stream and now both participants know that they should "apply" extra functionality to make it work. This is a great way to force the adoption of functionality with minimal impact on the programmer, but is really targeted at scenarios where 2 or more participants must engage in a conversation and have a minimal agreement. Dropping too many "aspects" into the protocol will create fat and rigid protocols that are hard to debug.

A fourth method for addind functionality to a service is to create a "composite web service". Here we have one web service front-end several services. A great example is using BPEL4WS. This allows you to call a single service and a script of services that it turns around and calls for you. BPEL is designed to be loosely coupled, where new services can easily be added. The neat thing is from the outside, a BPEL looks like web service - and it is. The BPEL method is a great way to create loosely coupled service composition, but it does it by standard flow-control mechanisms. Thus it takes on a loose coupled version of the pipe & filter model.

What I am looking for is the 5th way - and as far as I know, it doesn't exist (yet). I'm picturing a WSDL model that understands pre & post conditional apsects. Here the WSDL can have declarative aspects attached to it. The closest thing I've seen is "XL", see: http://xl.in.tum.de/publ/www2002.html
I'm not sure that this is the right way to do declarative, aspect based constructs for a service oriented world, but it sure the hell advances the thinking.

Implementation strategies for WS-ReliableMessaging

IBM has published a nice article on usage of WS-ReliableMessaging, see:
http://www-106.ibm.com/developerworks/webservices/library/ws-rmimp/

Sun Joins OASIS' BPEL Committee

See: http://www.eweek.com/article2/0,3959,1061476,00.asp

In an unexpected move, Sun Microsystems Inc. said it will join the Organization for the Advancement of Structured Information Standards' (OASIS') Web Services Business Process Execution Language technical committee.
A Sun spokesman told eWEEK that Sun will be joining the WSBPEL technical committee and will be in attendance at the first face-to-face meeting of the group, slated for May 16.

"Absolutely, Sun will be joining," the spokesman said. "We will be there at the first meeting on May 16. No rep named yet but we will have one by then."

The move indicates something of a turnabout for Sun, which is supporting an alternative specification to handle Web services orchestration, known as WS-Choreography. That standard, also supported by Oracle Corp. and others, is being developed under the World Wide Web Consortium (W3C).

UDDI v2 becomes OASIS Standard!

From OASIS,
"OASIS is pleased to announce that the UDDI v2 specification has been approved as an OASIS Standard. The UDDI Spec TC is to be congratulated on the work they have done in developing this specification."

World Wide Grid (WWG) - A Challenge!

I'm going to put my marketing hat on for a minute....

It occurred to me that we techies have failed to create a name for the web service based Internet. You know, that thing that is service oriented, message driven, self-describing, standards-based, loosely coupled - yet structured? Roughly, it is the universal services network sitting on top of the Internet and the wireless Internet shooting XML specified messages around according to specifications driven by the non-profits and the computing giants. For a while people called it, Web II or Web V2 - but those have faded away. Today, I propose "World Wide Grid" or "WWG" as the name for the aforementioned network.

"Huh?", you say...still don't get it?? OK, one more attempt, it is the combination of the WS-I Basic Profile (SOAP, UDDI, WSDL, XML Schema) + the new WS-I Security Profile + an addressing & routing scheme (WS-Routing, WS-Addressing) + a reliable messaging scheme (WS-Reliability) and a transaction scheme (WS-Coordination and WS-Transaction). These protocols will be complemented by a series of protocols that will be optional. The optional protocols will be utilized in a "Must-Understand" scenario between conversing parties. This will include everything from billing, provisioning and SLA's, to logging.

But why the WWG? Doesn't "grid" sound too much like a high-performance, distributed computing grid, like the efforts at Globus? Maybe - but before too long the "low-performance" and "high-performance" grids will have a significant amount of overlap and may likely become one grid. What about the OGSA efforts? That's easy - many people (like IBM marketing) tend to use grid to mean "run-time dynamic allocation of resources (CPU, Disk, Memory, Network) - this is clearly part of a grid - the part that many companies will promote to customers as having a near term advantage (cost savings through server consolidation), but it only touches on the real opportunity of creating a secure, messaging network where anyone in the world can participate. Call me old fashioned, but what many call grids are not much more than advanced versions of MPI - - and this in my opinion is missing the boat.

Back to marketing - I imagine the T.V. commercial where Bill Gates, Tim Berners Lee, Larry Ellison, Scott McNealy and Sam Palmisano stand up together and tell the world that they are backing, creating and selling the next web, the WWG. They go on to explain that it will connect every business, enable extended supply chains and create efficiencies that have only been dreamt about... I then imagine the NASDAQ once again being a popular place to make investments.

Web services are a network. And the network needs a name.

I know that many people read my blog - and many of you blog as well. So here is my challenge - support me in creating a new name for this next generation network -- OR -- make a better (or different) recommendation. Blog it and let's revisit.

IBM WebSphere adds grid capabilities based on Web services

WebServices.org reports:

1 May 2003 -- IBM Corp says its new WebSphere software will help companies get more value from their existing IT resources by allowing them to automatically manage multiple applications running on multiple clusters of servers as a single environment.
IBM says by virtualizing the resources available across a grid of WebSphere servers, the new technology -- called IBM Server Allocation for WebSphere Application Server -- allows customers to simultaneously increase application performance and resource utilization.

The technology, according to IBM, will enable companies to manage business applications running on different servers, and with differing priorities, usage patterns and computing profiles, as a single environment that can automatically adapt to sudden changes, much like the electrical grid. The company says it uses open Web services standards and will be enhanced as emerging Open Grid Standard Architecture (OGSA) protocols mature.

More details: http://www-916.ibm.com/press/prnews.nsf/jan/66F0366806B9363785256D19004988C4

Plugging Leaky Business Cases

Jack Keen has written an article at CIO Magazine on validating business cases. He introduces a couple bullet items which are fairly basic. The reason I mention it is that I am a fan of Business and I.T. Alignment. At Momentum, I preach to the consultants about tying business cases and use-cases together. Many software people tend to believe that the use-case IS the business case. This just isn't the case... the use-case brings the business case to fruition. I reccomend prioritizing the business cases, then identifying the use-cases for each business case, then prioritize the use-cases within the high priority business cases. Also, I recommend documenting the association of a business case to a use case. For example,

Business Case #32:
Theme: Increase Customer Satisfaction
Objective: Resolve Technical Support Questions Quickly
Measurement: 80% resolved on first call

Business Case #42
Theme: Remain Fully Compliant with Government Regulations
Objective: Answer questions around hazardous material
Measuerement: Have access to all MSDS information / per product

// More business cases go here....

and then later....

Use Case: Display Material Safety Data Sheet
Business Case : #34
Overview: blah blah blah
Pre-conditions: blah blah blah
Post-conditions: blah blah blah
// rest of use case...

// More Use case goes here

I find that too often software developers are building new components or fixing old ones - yet they have no indication on why they are doing it. Relating the use-case back to the business case gives the engineer the knowledge to better understand and/or challenge the users about the work effort.

Memory Lane

Just took a jog down memory lane, see:
http://www.jxta.org/servlets/ReadMsg?msgId=4658&listName=discuss
The issue was that you shouldn't try to get an opensource community to rally around a crappy specification - just doesn't work.

SOE and Corporate Strategy

The guys over that the Balanced Scorecard Collaborative produced a way to link the Service Oriented Enterprise back to the Key Performance Indicators of a corporation. They have created an XML Schema for structuring the reporting of on various metrics. This effort is called the, "Balanced Scorecard XML Standard". Although I'm not sure about the longevity of this particular standard, it does represent the thinking that a service network will be able to monitor active processes inside a corporation and send off alterts to a real-time business intelligence (or as I prefer, Process Intelligence) monitoring station.



One can anticipate that the XML Schema will eventually be complemented by some WSDL and may be aligned with pre-canned BPEL abstract processes. The era of strategy focused, process driven, service oriented, platform ready computing is coming. It is great to see the guys at BSCOL working on this problem from the top down...

Gartner Matrix on Business Rules Engines

Gartner released their matrix for Business Rules Engines for April of 2003:



The full report is here.

The report comments, "There is an emerging concept that service-oriented architecture (SOA) and its associated Web services also should include rules sensitivity. This may occur through 2004; the momentum has yet to be determined."

Although Gartner loves the, "Software as Service" story, they don't seem to be as bullish as one might expect on the exposure of business rules as services. The report does not mention the syndication of business rules for highly regulated industries (HIPAA, Patriot Act, Sarbanes-Oxley, etc.). However it does mention that one must consider the SOA:

"We believe that new agile applications will be composed of flow rules and services that leverage SOAs. Therefore, large vendors such as IBM and Microsoft must buy, build or integrate rule engines. We expect it will take 18 months or more for IBM and Microsoft to deliver the kind of functionality that can compete effectively in this market. Ultimately, there may be too few stand-alone rule vendors to justify a separate market. "

What happened to the DragonFly project from Microsoft???

Web Services Exercise #1

The marketing department at a Fortune 500 company has realized that 10% of their revenue is being generated from their online Internet presence. The Web group has also determined that almost 50% of all of their traffic is being directed to them by the Google search engine. In an effort to increase web traffic the company has decided to create software to monitor and report their “ranking” on Google. The software has the following requirements:

1. Every Monday at 4AM, a snapshot of the Google rankings should run.
2. The software should read from a set of stored keywords (supplied in advance) that the user would like to query Google.
3. The software should loop through the keywords, send the query to Google and retrieve the results.
4. The results should be turned into an HTML page that can be saved to a web server and rendered later.
5. Every Monday at 9AM, an email should be sent to a distribution list (supplied in advance) notifying them that the report has run. The email should also contain a link to the report.

Design this system using a service oriented approach. Leverage web service interfaces to the SMTP, the job scheduler, the HTML report writer, file persistence, FTP and the search engine. Leverage BPEL to tie it all together.

To do:
1. Create service interfaces, including WSDL & XML Schemas
2. Create any BPEL documents (if needed)

What is wrong with last-gen EAI?

Customers are tired of having proprietary EAI solutions and want to standardize on the integration mechanism.

The old EAI platforms didn’t do a good job of communicating between each other (Tibco to MQ Series, etc.). Since different businesses picked different vendors, it made it difficult to use these systems to connect independent businesses (or often different business units).

The old EAI platforms were not tuned for ‘long running transactions’

The old EAI platforms didn’t provide ‘compensating transactions’

The old EAI platforms didn’t recognize Web Services / SOAP as a ubiquitous communication device.

The old EAI platforms had proprietary solutions to transformations rather than moving to standards like XSLT.

The old EAI platforms had proprietary solutions for security – they didn’t employ standards like WS-Security for universal security needs.

The old EAI platform all had proprietary solutions for reliability – they didn’t standardize the ‘at-least once, at-most once, in-order, on-time’ delivery functions like is employed in WS-Reliability.

The old EAI platforms had proprietary solutions for node-to-node routing. Thus passing payloads with an itinerary required the vendor solution at each node. Today this may be accomplished by having components that support WS-Routing.

The old EAI platforms focused more on integrating legacy systems than on creating integrated business processes.

The old EAI platforms didn’t have the ability to create abstract versions of a process. Thus the ability to create standardized processes between businesses was nearly impossible. This has been advanced with the BPEL abstract process capabilities.

Customers think that the old EAI price tags are just too expensive.

BPEL4WS moves to OASIS!!!

Infoworld has reported that the control of the BPEL4WS web service orchestration specification has moved control to the OASIS standards body.

"The Business Process Execution Language for Web Services (BPEL4WS) specification is expected to be submitted to Organization for the Advancement of Structured Information Standards (OASIS), Carol Geyer, spokeswoman for OASIS, confirmed.

"We anticipate it will probably be tomorrow and a charter will be submitted tomorrow or maybe Thursday," Geyer said. The proposing companies still are making modifications to the charter for BPEL4WS that they submit to OASIS, she said. "

Perhaps some of the critics claiming too much confusion in the orchestration space will now come around.

Also, I was glad to see OpenStorm mentioned!!

Bob Sutor on Web Service Standards

Taken from, http://news.com.com/2008-1082-995956.html

But is there any one hot-button issue that people can't agree on?The one spot where people are still facing off is on choreography and that really goes to the politics of the standards organizations themselves. But the momentum for standards for Web services has clearly shifted to OASIS (Organization for the Advancement of Structured Information Standards). The W3C has decided that it wants to start a group around Web services choreography; IBM doesn't necessarily think that's the right choice or right venue, but we'll see how it works out.

Will IBM abide by the decision?
In what sense?

If they decide on something that's not to IBM's liking, will you be good soldiers and abide by the decision of the group?
Who's the group though? The W3C staff or the 500 member companies? That's where it gets little difficult because if you look at the models of the W3C and OASIS, they are very different. The W3C has a very strong centralized model of control; OASIS is far more decentralized so it doesn't necessarily make any difference what the OASIS staff feels about standards. They are more focused on providing the environment for people to get together. So you have this tension between them.

Process Driven Organization

I'm proud to announce that we are launching a new educational site called the "Process Driven Organization". This site is part of a series of sites Momentum Software is launching to paint a vision for the future of enterprise computing.

A Process Driven Organization treats its business processes as a portfolio of valuable corporate assets. Business Process Management techniques are used to explicitly define and execute processes in a manner that creates significant benefits.

The fundamental shift made by a Process Driven Organization is that business processes are built for agility and they are liberated from the IT applications that support them.

HP & Web Services

"Hewlett-Packard (HP) plans aggressive investments to position itself as the dominant vendor in Web services management. To succeed, HP must execute better than it has done on other software initiatives."

See: http://www4.gartner.com/DisplayDocument?doc_cd=113541

Sun News Letter - Web Services Expo

Taken from, System News for Sun Users, Vol 62 Issue 1

9437: Vaughn Spurlin Reports on the Second Annual Web Services Expo
Event Focuses on Currently Operational Web Services Projects

"In his account of the Second Annual Web Services Expo,sponsored by the Software Development Forum, Vaughn Spurlin reports that the focus was on currently up-and-running Web Services; the huge ROI that well-placed Web Services projects can deliver; the need for a detailed, convincing business plan if obtaining funding is the object; the pall on buying technology simply because it is new and different; and the emergence of SOAP as a four-letter word not to be used in polite company. Spurlin also includes summaries of each of the 14 presentations, among which were:
Intel Chief Strategist, Chris Thomas, stressed the need for "occasionally connected computing" (OCC), which would enable work to continue when no net connection was available. Web-based ordering should download data by subscription, he said, eliminate server lag and use drag and drop to enable completion of forms offline. Reggie Hutcherson, manager of the Technology Evangelism team in the Technology Outreach Group at Sun Microsystems, outlined the phases of Web Services adoption: Web Services over HTTPS (happening now), Enterprise Application Integration (EAI) Web Services (beginning), and business Web Services --including UBL and ebXML (2004 plus). He said more work is needed in Quality of Service, security and Identity Management and stressed Sun's focus on Java TM 2 Platform, Enterprise Edition (J2EE TM ), ebXML and UBL, and the Liberty Project. The Sun TM Open Net Environment (Sun ONE) provides a deployment mechanism for Web Services, he said.

Finally, Christine Clevenger, SAP VP for Industry Business Unit High Tech, explained her company's new solution, NetWeaver, which she said customers will use to integrate existing multiple SAP installations within their enterprise. Synchronizing master data is the key to interoperability.

P2P & Web Services - - Was I wrong?

Some time back, I wrote an article on, "The Convergence of Peer and Web Services". At the time I was trying to build some software on top of JXTA and realized that what it really needed was web service interfaces. The JXTA team (Sun) was willing to have web service capabilities as add-on's but refused to have it in the core. It was clear to me that this was a failing proposition - my team attempted some things like creating a bridging framework (see Jockey). Jockey was a hack - don't get me wrong - considering the fact that the web service designers were thinking "centrally distributed" (UDDI) while the P2P guys were thinking "resiliency first" it was a happy medium.

I recently had to write some code to parse up WS-Inspection documents and it hit me that WS-Inspection was a first step towards P2P based web services. I was happy that the location of the inspection document was easy to find, easy to parse and physically close to the service it described. Ultimately I think that WS-Inspection was designed correctly - however, it needs complementary specifications to address some additional aspects - like:
- Show me the services that have consumed me lately (a most recently used-by list)
- Show me other endpoints that agree to this contract (a list of same service, but other providers)

Now, some of this is covered in UDDI - and perhaps that is where this stuff will land. However, the UDDI spec seems to be growing and growing and growing. It's growth seems to be more around how to make one big ass, formal UBR. This is good and bad - the requirements for a golden repository with slaves are similar to a peer-to-peer contract repository. Thus, UDDI (although overkill) might just do it.

One of the things that the P2P guys got right (IMHO) is that they realized that finding services (peer or web) isn't always a formal process. In a P2P world, as you bump into servers, you are informed of additional services. In essence, each peer brags about the services it knows about. In the Web Services world this doesn't happen - the only way find a service is by intentionally hitting a UDDI, WS-Inspection or knowing a URL. This sucks. Perhaps it is time to formalize, "My Favorite Web Services".

All in all, I don't think I was wrong - perhaps early. One thing that is clear to me is that it will be web services in the forefront and p2p used as an add-on (e.g., SOAP binding for JXTA, SOAP binding for Jabber, etc.) Then, each of these transport providers will have to provide translation services (translate idl contracts, translate transaction contracts, etc.)

Eventually the concepts between these domains will merge. Now the question is, will it be Graham Glass setting the standard or Microsoft?

E-Week Editorial

I just read the latest e-week editorial:
http://www.eweek.com/article2/0,3959,985606,00.asp
They comment that SOAP will be challenged because security wasn't built into the 1.2 specification. I'm getting the feeling that the E-Week editorial board isn't familiar with the WS-I security profile work. I also get the feeling that they are still in 1990 land and want a BIG-ASS spec that ties all of this stuff together in a single spec rather than having a building block structure to specifications.

WebMethods White Paper

Web Methods has released a white paper, "An Introduction to Web Service Based Integration (WSBI)":

http://evals.webmethods.com/wmcontent_root/evals/ews/An_Introduction_to_Web_Service-Based_Integration_WSBI.pdf

Let's Dump BPEL and use JavaScript!!!!

HOLY SHIT! O'Toole at Cape Clear thinks we should dump BPEL4WS and use JavaScript instead:

"I asked O'Toole if he expected Cape Clear's customers to proceed blindly with developing Web services that are devoid of any notion of orchestration or transactional state. O'Toole claimed that complicated protocols like the Business Process Execution Language for Web services (BPEL4WS) or the Web services Choreography Interface (WSCI) are extra baggage and that any functionality that those specifications are designed to handle is easily covered by something found in virtually every system: JavaScript (also known as ECMAScript). "

ARE YOU NUTS?

He goes on to say that application servers can go as well. I get the feeling that anything that isn't in his companies product portfolio (yet) isn't worth the while.... very sad.

Not Loosely Coupled

David Chappell makes some sound comments on the fact that loose coupling is poorly defined and that usually it is a bunch of crap:
http://www.davidchappell.com/HTML_email/Opinari_No5_3_03.html

I think the point that David is trying to make is that we need agility with out fragility. That is the essence of loose coupling.

BPEL White Paper

The guys over at Collaxa ran this nice white paper down:
http://tmitwww.tm.tue.nl/research/patterns/download/qut_bpel_rep.pdf

Hermes Message Hanlder

I just ran across this free implementation of the ebMS specification:
http://www.freebxml.org/msh.htm

I have no idea how well it works...