Re: Application design & architecture -- MIDRANGE-L

Bill,

These are great questions!

IBM has developed a product called IBM WebSphere Service Registry andRepository. It is designed to provide governance of your SOA - simply put,it is a list of the services you have available. If IBM are doing it, thenyou know the change management vendors will not be too far behind providingus with better ways of knowing what we have available. Aldon have written awhite paper outlining their support for your SOA efforts. MKS are alsoworking in that arena.

The question of "when to stop" is not an easy one to answer. However, thatis what a good Services-Oriented Architectire is designed to answer - thatis, what level of granularity should be adopted. Obviously, a file "getrecord" is too granular for a business process oriented architecture. And, acustomer order entry system has many processes involved and is not granularenough. And choosing how to build services based on parameter requests isscary - do I write one for all 200 pieces of information about a customer?or, do I write one for each type of information request I have? or, do Iwrite one every time I need to get some combination of customer information?Deciding the level of granularity, and which forms it will take, should beanswered by the SOArchitecture.

I think the issue has been that in the System i world, we have neverencountered a Systems Architect. Getting used to the concept of having anSOA Architect is going to be a difficult transition.


Trevor

----- Original Message -----From: "Bill Meecham"

Subject: Re: Application design & architecture

Isn't that 'mechanism' a registry of objects?  We have modules and service

programs that perform many almost atomic functions but finding the onesthat

will do what you need quickly is a problem.  It's not just naming
conventions, it's available parameters; desired output; and
specialization...and finding the particular components that will help you

build the information you need from the data you have. In that sense,CASE

was the right tool at the wrong time.  I've built a system to register our

modules and service routines to make it easier to find building blocksbased

on category and function and it sure does boil down to a subset of a CASE
tool.

Another problem is knowing when to stop!  Perhaps there are articles that
define this better but that question is always an issue when modularizing
components.  There's a line somewhere between what is functionally
necessary, what is necessary for the business, what is necessary for the
data storage and information gathering, etc.  The line extends through the
programming staff because many want to write a program that completes a
request instead of writing or picking modules that complete a request.

But that's a different problem...back to knowing when to stop; how much

information should be returned in a single request? How specializedshoulda request server be? Sounds like easy questions but in practice, evenaftercareful analysis, there are always those requests that don't fit the moldof

many standards that are attempted.  So then write even smaller pieces and
fit them together?  Back to CASE we go then?  Or back half way at
least...especially if we're able to think in terms of unlimited machine
time.


bill