my dog learned polymorphism*
The moose likes Web Services and the fly likes Lessons learnt from San Francisco Component Framework Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Java » Web Services
Bookmark "Lessons learnt from San Francisco Component Framework" Watch "Lessons learnt from San Francisco Component Framework" New topic
Author

Lessons learnt from San Francisco Component Framework

HS Thomas
Ranch Hand

Joined: May 15, 2002
Posts: 3404
Paul , as you were close to this initiative you could give us some insight.

I've listed a couple of the lofty goals of SFCF and some lessons.
Goals of San Francisco Component Framework
==========================================
1: Building a library of reusable business objects that could be used with ease in any part of the globe.
Lesson : Business systems are more complicated than operating systems and GUIs.Note we have many View Technologies but few whole component frameworks.
BTW, what are initial impressions of Spring Framework ? - (it seems to be an MVC for any type of distributed technology, at first glance.)
I could add that there is a gap between the language of the framework and Business Analysts who didn't seem to accept that they should learn the framework or UML for OO but prefered an unconstrained approach.
"Light came to them sideways, behind and sometimes from the front"
Unfortunately or Fortunately , I think this attitude is still true. Perhaps your book can be used for effective communication with Business Analysts ?
2: A Component Framework for effective OO development
Lesson : Without design patterns it would not have even been possible.
Did any of the SF Patterns survive into J2EE Patterns, or patterns in your book ? Loss of Policy Patterns - any regrets. Business analysts love policies..
regards
[ December 05, 2003: Message edited by: HS Thomas ]
Paul Monday
Author
Ranch Hand

Joined: Aug 28, 2003
Posts: 41
First of all, I'm getting VERY curious as to your background and what you do now (not for recruiting, just out of complete curiosity). You'll have to shoot me a note offline if you are willing: pmonday@comcast.net.
I do have a bit of a different perspective on this...
Originally posted by HS Thomas:

Goals of San Francisco Component Framework
==========================================
1: Building a library of reusable business objects that could be used with ease in any part of the globe.
Lesson : Business systems are more complicated than operating systems and GUIs.Note we have many View Technologies but few whole component frameworks.
BTW, what are initial impressions of Spring Framework ? - (it seems to be an MVC for any type of distributed technology, at first glance.)
I could add that there is a gap between the language of the framework and Business Analysts who didn't seem to accept that they should learn the framework or UML for OO but prefered an unconstrained approach.
"Light came to them sideways, behind and sometimes from the front"
Unfortunately or Fortunately , I think this attitude is still true. Perhaps your book can be used for effective communication with Business Analysts ?

Building reusable component frameworks for business is "hard" for a few reasons:
- Business processes are largely organic and viewed as a "value" for a business (though this is changing), therefore, generalizing a business process and creating "plug" points essentially commoditizes a business process (not something businesses sometimes even accept as possible)
- You are right about the "gap", though I would push the gap even farther. With so much given to you off the shelf, there was a substantial amount to understand and learn...often, individuals feel they will be more adept at building it themselves than having to learn all of this "stuff"
- The framework suffered from a lack of standardized business process languages and workflow engines (much of this was built into the framework in a specific fashion...like lifecycle management)
- There is a severe gap in knowledge between a technical team building a framework and the type of people who have to use the framework (to be adept at SF you had to have good knowledge of OO patterns and the SF patterns, yet the closer you get to a customer, the less of this can be exposed...by the time you are IN a customer site, you are dealing with consultants and IT folks that frankly don't have time to learn SF design patterns since SF is a part of their toolkit, not their only tool).
- There are already business processes in place at enterprises that don't always match the coarseness and granularity of SF...further, there is DATA in place. This is where standards in BP models would be a huge help in the technology sector, and it in turn would help customers open up their choices. This change will take years... Until that happens, I suspect it will be hard to have an accepted business framework that gets used for generalized infrastructure.
- The user interface and user experience was always secondary in SanFrancisco which led to a gap between customer UI needs and how the FW handled transactions and moving data to clients.
Now, what's interesting is whether SF SHOULD have addressed these gaps. IBM is very good about not competing with their customers...they don't build general software solutions (like Retek, PeopleSoft, Oracle and SAP do), they supply infrastructure. So you have to listen to people about how far "up the stack" you can go...whether SF's "license" was too small to be successful could be an interesting debate...
Originally posted by HS Thomas:

2: A Component Framework for effective OO development
Lesson : Without design patterns it would not have even been possible.
Did any of the SF Patterns survive into J2EE Patterns, or patterns in your book ? Loss of Policy Patterns - any regrets. Business analysts love policies..
regards
[ December 05, 2003: Message edited by: HS Thomas ]

I would, again, suggest you get the SF Design Patterns book. These patterns are definately applicable WITHOUT SF and in a J2EE environment. Some of the "foundation" patterns and constructs are in J2EE (especially with respect to persistence).
Also, IBM still supports SF (I saw they just extended support through 2004) as there are applications deployed with it. Finally, last I knew, IBM did still use an EJB version of the upper tiers in professional service engagements.
I did a patterns tutorial for IBM devWorks before I started at Sun. I did use some of the SF patterns in the tutorial as examples of "moving beyond GoF".
Your last comment is interesting...IBM spent a LOT of time working with domain experts and listening to them about processes and policies. The SF Design Patterns book is SO well written because it talks about WHY these things were necessary....and btw, I think it still comes with SF Version 1.3 :-)


Paul B. Monday<br />Author, Web Service Patterns: Java Edition
HS Thomas
Ranch Hand

Joined: May 15, 2002
Posts: 3404
Thanks Paul, that's very enlightening.
My brush with San Francisco was at the very early stages of EJB and the internet was very young then. Security would have been a huge issue if it were not for IBMs involvement but SFCF and the project departed company. In fact the project eventually left these shores (UK) for Canada for some serious Business Process Model development (still under British management,
but the skills/political climate was more conducive to component development.) I believe bits of the new infrastructure are being adopted by companies in Britain.
At the moment I'm catching up on various technologies which seems to have nuclear mushroomed and trying to look for a Bigger Picture than I worked with before; My main interest is balancing People,Process,Technology ,really, on the shop floor as it were. As one can tell from my three favourite forums Meaningless Drivel, Process and OO/UML Designer.
I'd be really interested in studying Business Analysis with Systems Analysis using components and web services at the fore - force the issue a bit. But the time may still not be right ; what do you think ?
Actually I think you have answered the question here :
This is where standards in BP models would be a huge help in the technology sector, and it in turn would help customers open up their choices. This change will take years... Until that happens, I suspect it will be hard to have an accepted business framework that gets used for generalized infrastructure.
There's some mega development tools out there now like Eclipse and new ways of managing like XP, Test Driven Development. If development teams take to these naturally businesses may not be slow in realising how quickly it is to adapt or adopt new business processes and take advantage of that, IMHO.
[ December 06, 2003: Message edited by: HS Thomas ]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Lessons learnt from San Francisco Component Framework
 
Similar Threads
Part II - Business Domain Model changes
Business forum that uses UML
San Francisco Framework and Web Services
What it takes to be an architect?
I'm now SCEA5 Certified