Friday, August 29, 2003

Offshore Backlash

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

More confusion on course / fine grained at Syscon


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

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

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

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

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


Thursday, August 28, 2003

Stuck in Java Land

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

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

Monday, August 25, 2003

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:

Sunday, August 24, 2003

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:

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:

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...

Friday, August 22, 2003

Designing Web Service API's

A while back I blogged that we need to learn lessons from the web services API... the implication that I made was that they did it wrong. Since then, others have poked at it as well:
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 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 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.

Saturday, August 16, 2003

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 :

Web Services Choreography Requirements 1.0

The W3C published their "requirements" document for web services choreography:

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...

Thursday, August 14, 2003


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

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

Monday, August 11, 2003

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.


Wednesday, August 06, 2003

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.

Tuesday, August 05, 2003

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.

'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.