Re: Application design & architecture

Trevor

Trevor Perry wrote:

Rob,

Go read this article: http://www.infoworld.com/article/06/05/02/77996_HNsoalink_1.html?source=rss&url=http://www.infoworld.com/article/06/05/02/77996_HNsoalink_1.html Quote: "SOA's not hype. SOA and Web services are moving beyond the 'connect things together' stage. We're at a point where it's becoming a part of the mainstream," Schmelzer said. "That's a bit less sexy, because you're getting down to brass tacks: implementation details, not the big news stories," Schmelzer said.

This told me very little.

Ok, you have asked a LOT of questions. I will take the bait. I would suspect, though, that you would be better off doing your own research rather than argue with mine.

Doesn't it pull together existing tools, languages etc. If so, even if
it provides a solid foundation for them, those programs, modules - call
them what you will - will be the lowest common denominator and be the
weak points of the SOA solution.

Certainly your existing applications, if they are using outdated approaches, will be weak points. There has to be some form of modernization to allow your existing code and applications to be re-used. For example, you may have some business rules inside an RPG program. These rules are effective in running your business, and now you wish to extend their use beyond their current scope. For example, a customer of yours may wish to know the status of their order. Use your existing order inquiry code, repackage it as a web service, expose it to the web securely, and allow your customers to consume that web service inside their application. If your current order inquiry code is not modular, then making it modular would be the first step. After that, your weak points now become strong points.

How long is the learning curve before someone could start to develop a
useable robust scaleable SOA solution?

Yes. How long is a piece of string? How long did it take you to learn _____?

The answer is that it depends on your approach. Most System i shops that have had success with SOA 'solutions' have started with XML.

They find a business reason to consume a web service

and integrate that into their current application suite. This has the added advantage of allowing them to learn more about SOA from the bottom up, by understanding the concept of a web service - that is, what is a business process, and how is it defined. One small step, and you are on your way.

What is the approximate percentage improvement in development
productivity compared with traditional methods TAKING THE WHOLE
DEVELOPMENT CYCLE?

This is not a starter question. And again, there are too many variables. What skill set do you have in your IT shop? What business applications do you have? Are you already modular/ILE? Are you able to introduce change? Do you have strategic thinking business management?

In what way does SOA help to simplify the processes of development?

Many ways. Here are five:

1) Modularization. Maintenance of modules has proven to be much cheaper than maintenance of legacy linear programs.

2) Re-use. IBM preaches governance, and consider this key to SOA. If you know your environment, then you will know when a module can be re-used.

Instead of traditional subroutine repetition, business processes will be built and linked together when needed. 3) New applications. As your business processes are already built, new application development will comprise more choreography and orchestration than new coding. 4) Leveraging partner development. When you have a business process that is required in an application, and it has been developed by someone else - let's say a customer credit check - your application can consume the partners service. You have less coding, and therefore less maintenance. If you want to argue about the quality of a partner's code, why would you be in business with them if you did not trust that?

5) Loosely coupled. When your business needs change, and you partner with someone else, switching your web service to consume a credit check from a different business partner does not require re-coding. SOA includes open standards like web services for this purpose.

To what extent does SOA automtically enable reuse of
methods/objects/code etc?

It does not. Your Architecture dictates how re-use will happen.

Certainly, governance will assist in the ability to re-use processes. Moving into an SOA world will require better standards than we traditionally have.

Does SOA allow incremental development without the need for a most
detailed specification before development begins?

Building applications should always require a business specification. To what extent you detail that specification is up to your SOA. In the end, if you are writing code, it seems obvious that a program specification should be written.

The difference is that the SOA has defined the interfaces, the structure, the foundation, etc..

Does SOA require physical file design?

SOA is not technology. It is not software or hardware.

Then what is it?  Smoke and mirrors?

Once you are building the application to conform to the Architecture, you will be designing physical files. If your Architecture dictates normalization, then you will design accordingly.

How does the performance of SOA applications compare with other methods?

SOA is Architecture. The concept of performance is going to be defined by your environment. Sure, the Architecture will leverage your existing infrastructure, and it will certainly be aware of performance, but SOA 'applications' will perform as well as they are written. There certainly are performance issues to be concerned about. For example, XML is used as a common transport mechanism. XML is text-based, and if you were to send large amounts of data, you could easily impact performance negatively. If this were to be the case, your SOA might offer alternative transport mechanisms as the standard between applications.

In what way does SOA help to simplify the processes of maintenance?

Modularity. Leveraging partner applications.

I.e. it doesn't

Does SOA allow you to change file layouts without shutting down
applications?

SOA is not technology. It does not require a language or hardware or software - that will be dependent upon the business and their infrastructure. If your development tools require this, then I would assume they will continue to require this - SOA or not.

How does SOA help to provide 24/7 solutions with automatic parallel
duplicate databases for rapid recovery after a major disaster?

It doesn't. This is infrastructure, not architecture of business applications. DR or HA would be part of your business strategy, and certainly the SOA would recognize that.

So SOA adds nothing

How does SOA overcome the inability of relational databases to model the
muti-dimensional complexity of the real world?

SOA does not overcome the inability of the developer to do anything. SOA is architecture. With a valid Service-Oriented Architecture, business are truly interoperable in a way we could not fathom when relational databases were introduced. The inability of relational databases to model anything should not be a factor in building an SOA.

Does SOA require greater or less technical skills than existing methods?

SOA requires additional skills,

because most developers do not have an understanding of the tools needed to consume or expose web services. Most System i developers do not have an understanding of modules, but with their existing skills, they could easily learn these next steps. SOA does not require the programmer to be any better, it requires that they understand where their code fits into the big picture.

What hands-on experience do you have of actually using SOA?

Smart-ass questions do not help explain SOA.

Thanks for your attention. Next challenge?

Are you meaning to imply that you succeeded in that one?

Rob