Client-Server -> SOA.... Is it really a transition or a big development ?

[Former Member]

Hi,

In all sources related to SOA/ESA by SAP, it is said that, transitioning from Client-Server Arch(CSA) to SOA is the same as transitioning from Mainframe systems to Client-Server Arch.

If we think about Mainframe and CSA, it is obvious that there had been big differences in that transition. Such as, the INTELLIGENT CLIENT concept had appeared to replace the DUMMY CLIENTS, so this had changed the way of IT Business. There would be a main application providing several functionalities(server) and other applications which want to use those functionalities (clients) would connect to the server using some functionalities on its own (that means a client appliction should also have some functionalities in order to at least connect to the server, so that made them different from the DUMMY clients of the mainframe era)

Now, when I look at the differences between SOA and CSA, I cannot see that incompareble differences.Why ? Let me explain :

- One of the most important differences between SOA and CSA is, SOA is vendor and platform independent, so that any application can call any applications functionality as long as they are using Web Services. That is true. But the question arises here : It is still the case that someone is calling some others' functionalities (services), so there is still a client/server mentality, isn't there and We will still be using several client/server programming languages in order to realize the main functionality of the web services but this will be transparent to the user and the integration. The main difference is, SOA is vendor and platform independent. But I don't think this can be commented as a missing feature of CSA. Because the aim of CSA was to make the clients more intelligent and not to make them vendor/platform independent. And also architectures like CORBA and DCOM have also tried to achieve that independency (even though they have restrictions compared to Web Services, one of the main reasons for this is using Web as a transport/communication protocol) but they are still treated as some extensions on top of CSA because they are using CSA beneath. But if we compare Mainframes and CSA, even though I haven't seen manframe ages, I think it is clear that CSA does not use any architectural functionality of Mainframes. They are completely different.. But is SOA and CSA completely different ?

I agree with all reasons why today business needs sth more agile, more flexible and it is becoming clearer day by day that SOA and Web Services provides this environment, BUT, I still cannot make it clear, WHY it is accepted as a transition from CSA and why it is not treated as a big development over CSA while using the main features of it.

Any comments will be appreciated.

Regards

Ahmet Engin Tekin

[Former Member · Accepted solution]

Ahmet,

I would like to add also my 2 centimes (of euros) to the debate.

I think the starting point of SOA is the recognition that no single application can be built today in a monolithic architecture, the days of well layered architected systems integrated with other well layered applications are over.

Today, an application cannot be built without leveraging some data and business logic somewhere. Take the simple example of calculating tax rates on a purchase order in global economies. Why should every company in the world own a component that calculate tax rates. This component would almost need to be updated everyday in a global context because rules and regulations change almost daily at the scale of the world.

SOA and its associated technologies such as web services enable an application architecture (composite application model) that can leverage services such as Tax Calculation wherever they are, regardless of the technologies in which they were built.

This requirement is actually profound and is creating the need for new paradigms the most important of which is bring the "message" as the same level of importance as "code" or "data. This is why you see technologies like BPEL taking more importance every day.

Regarding the C/S debate, nothing says that Web Services have to be invoked in a C/S mode. It is actually quite remarkable that Web Services offer a unified model for C/S or peer-to-peer invocations (please see my web cast below).

I have given a presentation at the last TechEd in Vienna that you may want to watch where I developed a pattern to reason about the SOA application model. I call this pattern REASC: Resource representation, Event, Activity, Service and Coordinator. I also provide a new view of the Web Service architecture stack based on this pattern.

The web cast can be found here:

http://www70.sap.com/community/pub/events/2005_09_teched_us/presentations_02.epx

It is called "the standards of SOA"

Cheers,

Jean-Jacques Dubray

Standards Architect

SAP Labs

Palo Alto, CA

[Former Member · Accepted solution]

All,

Thanks to everyone's contributions. Let me say that, I agree with your explanations regarding SOA. It is obvious that SOA is emerged from integration problem. And now the Web Services allow IT and Business to speak the same language. These are no questions.

To summarize the development :

Mainframes-> CSA (Distributable App. Components)-> Best of Breed Apps-> INTEGRATION PROBLEM -> SOA and Web Services

Does anyone object this ? or have more comments ?

Anyways, as I've said before, I've started this post, because I've gotten the idea from the presentations that SOA is the new thing after CSA as it was the case btw CSA and M/F. And as we see from the posts here, it is not exactly that. The starting point should be interpered differently instead. So, either I've misinterpreted the ideas in the presentations, or there are some missing points in them.

Regards

Ahmet

[Former Member · Accepted solution]

I would like to add a point concerning transition in the hardware -side.

It is obvious to us that there doesn't need to be a transition in the hardware- or even in the application infrastructure. Instead, we can move to SOA while using current applications on current HW platforms. All we need to do is describe application functionalities as services and exploit them as web-services through a bus.

On the other hand, we are talking about a possibility to change our existing application and hardware infrastructure in the long run. We can forget division into ERP, SCM, PDM or whatever and move into grid-computing for improved scalability and reliability. In a way, the transition is so smooth it may not seem like a transition at first.

[Former Member]

Ahmet,

This is such an interesting topic that I could not resist staying away from it.

My two cents and I would like to look at it from a completely different angle. I would rather compare SOA to EAI instead of CSA. Technically I can plug in M/F applications & Client-Server applications to form an SOA in an IT landscape. for e.g. In SAP’s own language, a M/F system or a Non-SAP CSA can talk to XI (using adapters) which inturn can publish/subscribe services. From this perspective, it would be an evolution from Batch mode interfaces (In Mainframes) to “Point-to-Point” interfaces to “EAI” using hub-n-spoke model and then finally to SOA using enterprise bus. After all, we are using web-services to communicate between applications or “blocks of business functionality” if you can call it from an SOA perspective.

Also I agree with Shivraj’s opinion above that so far all architecture changes have been within the IT domain…This is probably the first architecture change that is extending itself to the business domain.

Regards

Vaidy

[Former Member]

Hi Ahmet

How would you define an application from the VB-Oracle, Powerbuilder , Pro C-Oracle days. A thick client that held the business logic distributed onto individual end user PCs that interacted with a server which hosted the DB for data. I assume CSA refers to this type architecture. In which case there is a fundamental difference between SOA and CSA . But essentially I think we have moved outof "this kind" of "thick C"SA ages ago with the introduction of app server and web based delivery and limited footprint client namely the browser.

And thus introducing the "thin C"SA , eventhough multi tiered with business logic in a tier of its own , its still a silo, monolithic , not always integration ready.I think in this context SOA is big shift atleast in the server/integration layer providing granular integration/orchestration ready services and repositories for service registration and discovery.

Just my thoughts....

Regards

Pran

[Former Member]

Hi Pran,

I agree that SOA has many differences regarding many issues (integration,flexibility, etc..), BUT, If you compare R/2 and R/3 you can see the differences in architecture because Mainframe and CSA are completely different architectures. But, I cannot imagine SAP will publish a new ERP that has completely built on SOA and not using CSA. It looks almost impossible, because, as far as I can see, you can build ESA only on a CSA, at least to use the DBs of servers. So, CSA->SOA is still not a replacement but a big development for me. Maybe I'm focusing on the wrong thing, I don't know. That's why I've started this post.

Anyone out there from SAP, working on ESA/SOA who has some more detailed answers ?

Regards,

Ahmet

[Former Member]

Hi Ahmet

Can you define what you think is CSA , because in one ways everything is CSA ,even the mainframe, the dumb or green terminals are clients by which users access applications residing in the server.

If you are trying to define CSAs as those architectures that have intelligent clients then what are examples of such architectures?

Regards

Pran

[Former Member]

Hi Pran,

Thanks for the posts. I know that SAP probably is not wrong and SOA is a transition but I'm trying to figure out how ?

Your sentence "because in one ways everything is CSA" is interesting. It is ok. So can we make it clear, what does it need (not specific features but what type of things) to be a transition in IT Software architecture, so that we can apply it to Mainframe->CSA and then to CSA->SOA ?

Regards

Ahmet

[Former Member]

Well you can look at it this way:

With CSA you had to know all the endpoints:

client and server knew of each other, had to know of each other in order to communicate.

With SOA all becomes much more complex (or simple) and the environment is "virtual". The client (or BPEL process ?) does no longer need to know where each service is provided. All the client needs to know is how to connect to the bus. It can then request the corresponding service. If you change the provider of the service (from Unix to M$ or MF or Linux on Intel...) the client doesn't need to know about it. All you do is change the registration of the service with the Bus. This is a HUGE change in paradigm.

Your services are no longer bound to a specific implementation... They become "Plug&Play" and the client is none the wiser for it.!!

Enjoy

[Former Member]

Good point..Actually those are the things clearly known but it becomes a bit confusing to build clear sentences when it comes to declare the differences. Anyway, here are my additions :

- Mainframes were centralized systems which had their own hardware architecture as well. All processes/applications were running on 1 central DB/system and everyone in the company had to use the same functionality and interface.

- In time, as a result of business demand, people needed different functionalities/applications regarding different business needs. This could either be done by extending the higly-costed big mainframe systems/softwares OR a new approach had to be developed in order to solve those problems. At this point, (thanks to IBM,Macintosh and Xerox) PC and ethernet concepts had emerged. That was a completely different hardware architecture which allowed less costly systems and also distributing the process load and/or applications to different systems in one landscape (app servers, intelligent clients - 2 tier, 3- tier arch.). Thus, while those were happening on harware side, new communication and programming models/languages emerged on software side. As a result, people started using different applications on different systems according to their needs and thus an efficient solution had been provided to the business need (described above).

To criticise, this was really a big transition. Not only software concepts but also hardware concepts are also changed drastically. Actually, it is not wrong if we say, developments on the hardware side, allowed changes on the software side

- What happened next ? Companies started using so many different applications by different vendors with different business logic and programming models (thanks to CSA). But in times, this has emerged the biggest problem of the CSA era : Integration.

We all know the rest. "Web Services" concept emerged with SOA as well. So that, the boundaries between the systems began to disappear.

So, is this a transition ? Well, yes it is.. The point that made it confusing (at least for me) is that this time there is no hardware transition (yet) but only a transition in software side. But I still insist that the IT transition during Mainframe->CSA was like a revolution (forget what you've left behind) but from CSA to SOA; it is more likely to be an evolution (the next best thing)

Anyone have more comments ?

Regards,

Ahmet

[Former Member]

hi there,

IMHO we have a real tansition.

the CSA of the 90ies was mainly a client-to-application-architecture, even if THE application was distributed over several machines or tiers. If THE application's function relied on some other application's functions they always had to be kind of 'taped' together.

SOA and it's actual 'implementations', in my opinion, is the first working concept for real distributed computing; distributed not in it's traditional meaning of distributing an application over several technical systems, but in the meaning of building a process from distributed building blocks - services.

Think of far ranging processes like Order-to-Cash or Procure-to-Pay.

Within this concept, client-server looses it's meaning a bit, being replaced by something like a UI-process broker concept.

Within SOA you can think of an agency(the former server), plumbing together a number of services (which the agency owns none of them and doesn't operate them technicaly)into a process, which you (the former client) are accessing to solve your business task.

In my opinion this is way different from the traditional client-server(or client-application) paradigm.

just my 2 cents,

anton

[Former Member]

Ahmet,

I think you are trying to relate the hardwares associated with Mainframe and CSA into the hardware of SOA - which is acting as a block.

SOA is not related to hardware associations. Comparing the transition to CSA->SOA to Mainframe->CSA, somehow doesn't justify its importance.

The transition to SOA is not actually from CSA. It is more like a transition from rigid business processes to flexible business processes. Both Mainframe and CSA are rigid architechtures. Changing a business process in these earlier era technologies was very difficult. Any change to an existing process has to be developed from scratch.

It is a transition from closed "business" architechture to an open one. In this sense, I feel it is even more important and is a total revolution compared to the transition from Mainframe to CSA.

Regards,

Sivaraj.

[Former Member]

Sivaraj,

Yes I've already pointed that considering hardware has become a block for me. Anyways, what you say is not wrong, regarding SOA's transition is from rigid business apps to flexible business prosesses. BUT, as you are probably also aware , in most of the presentations/documents (including SAP), SOA and Web Services are presented as the next step from CSA. If we assume this is not the case, then this post should terminate itself

Regards

Ahmet