 I am Sushil Rajgaonkar and I belong to the center of excellence within Elintin-Potec. And one of the areas within the center of excellence is service oriented architectures. So we look at how we have been working on it for about 3-4 years now and we looked at starting with what the standards are, what the tools are, moving on to helping customers, creating services. So what I am going to share today actually is three ways. We look at SOA adoption and since it is a big topic we will try to classify the SOA adoption being done at customers so that it simplifies or it helps us to understand the motivation for SOA in a particular case. And that we will, I will use that theory sort of in the case studies which I will be talking about later. So the second item is the case studies. Finally I will conclude the presentation with some of the challenges which we have seen while implementing SOA at our customers place. So I am sure that will help you at least that can be a consideration for you when you start your journey, right. Now when we look at SOA adoption now you have for the past 3-4 days you have looked at how to create a service, you know, you have looked at what are the standards, you have worked with some of the tools to build services, maybe you have built some applications to consume the service, okay. But that I would say is creating services at an application level. Now when we talk of the industry and the, you know, customers at large who are actually going to implement SOA, it is the enterprise perspective we have to keep in mind, okay. And one of the challenges or the problems there is the context becomes very different. When you talk of application you still have, you know, lot of things in your control so to speak, you are the application owner you can talk to, he can give you, you know, how the application was built, he will have some documentation and things like that. But when it goes to the enterprise context, there the landscape entirely changed. One is the set of applications remain as a variable if I have to say what are the variables which you have to consider when you go on to the enterprise scope is one is the application in themselves. But then there are a lot of applications spread over a lot of the geography. And then, you know, you have then many other aspects to cover or talk about. So what we thought is when we talk to customers and when we talk to peers and colleagues in our group itself, how do we, you know, when we have to communicate about SOA, somebody is adopting SOA, what does it really mean? So we have to break it down. So this model or a picture which you see is a step towards that to be able to classify exactly what is being done or is being attempted in a particular case. So we start with business services, reusable business services. This is the first step which most people would do, you know, where you would start service enabling your applications as we call it. You take up the application and here the application could be a legacy application or an application which has already been in use. It has been in use and continues to be in use. You are adding a service interface to that. And then you make it more business-like, of course. So for an example, suppose it's a financial domain or let us take, which most of you might be familiar with, the whole application kind of scenario. So there, what are the set of services so you would want to calculate, you know, people's income tax, you would want to calculate the total take away. You may want a service to, you know, give out salary slip, things like that. So all of these are grouped and you would have a business service, you know, carved out of this payroll application. The motivation for that is primarily what the, you know, the benefit what the companies get out of this is that this service can now become a reusable entity which can be consumed in multiple applications. Later on I have a small example which I will try to illustrate this aspect of reusable business services. But the point is the motivation more is to be able to use the data and the functionality which is already available and to make it available for more people to consume, more applications to consume, okay? So that's the reduced operating cost value proposition for the business services. You move on to the right, the service-oriented integration. Once you build services, what do you do next? So we build applications where we can consume them. But that's a simple kind of point-to-point calling of a service. You have scenarios where you may want to use the same service by multiple applications. That's one. Second scenario is the application which you are trying to build, which will consume services, could be calling multiple services out of, and these services could be coming out of different applications. So they have heard about ESBs, Enterprise Service Bus. Okay, so there's a notion of or a requirement where you may want to call multiple services from multiple applications and using multiple protocols. Till date, you must have heard about so over HTTP as the mechanism or as the method to invoke a service. But then once you have a service, people say, why should we get constrained by being able to be called over by SOAP over HTTP alone? Can I call it in a different method? Can I call it in a with a different transport? So what's an example? You could have in companies, they have these queuing systems. So can I call the service using my queuing system? So you have SOAP over JMS kind of scenario. Or can I make a simple XML call still and be able to get the service? So now things are from the puristic approach where you have SOAP over HTTP. You may also want the same service to be called by multiple protocols. So ESB enterprise service bus is a concept and now it is there are implementations also available which allow you to achieve this. And service oriented integration is about integration. You're not doing or creating an integration using a ESB. Now what's new here is previously also we had application integration, EAI, many of you must have heard enterprise application integration. So that was prevalent. So what is different here? Here the whole idea is you do your integrations with standards. So you would use web services standard, use the JMS standard, you would use the HTTP standard unlike in EAI tools or products where they have their own proprietary protocols to achieve the integration. So that's the difference and in terms of benefit for the organizations, again we say it helps to reduce the operating cost. The reason is because of standardization there is a competition and then the EAI tools the way the price points or the levels at which they were priced. We find that the ESBs are much more cost effective and you could achieve more or less many of the features which were provided by the ESBs, by the EAI tools. So in that sense, now we see a trend whereby new integrations which are being built are built using the service integration model or the service integration route. The overall as they call it the total cost of ownership for the enterprise comes down because the product itself is less costlier. And then the maintenance revenues and all that which they have to pay that gets reduced in comparison with the EAI tools, right? Any questions till now? So the question is the rules keep changing and then how can the old service serve the purpose? Now having recognized that the rules change so what people say is the service is one aspect which will which will which will get impacted by this and how do you reduce the impact is within the application itself. What you do is you try to use, you try to abstract these rules in a different way. So as to see that the service is less impacted. And one of the solutions is as you see in the fourth box foundation for BPM. Now business process management is an area which actually tries to tackle that much more efficiently and in a much more better manner where they have kept provisions for this change aspect which will come into the picture, okay? So my answer would be that you know there then instead of looking at the service we may have to look at the application which is combining the service to try to get some abstraction for the changes, right? Any other question? Okay, so we move on to the composite applications. What are composite applications? Once we have service again I go back to the simple principle where you have a service and then you make a simple application which will consume the service but then you can extend the same idea where you now kind of instead of one service you build the application by having a large collection of services and where are these services coming from they need not come from one application now they can come from multiple applications within your company they can be services which are hosted by third-party people I mean available outside your enterprise you can combine mix them together and then build nice set of applications. So today what is happening is you know against this what used to happen earlier so that then you get the better picture of the difference or what this brings to the table is earlier you would be restricted to one application and then you would use that application's user interface to communicate with the application, okay? So if I had let me give an example of say leave an attendance okay typical ways we use one application to post our leaves then you know or we send an email to our manager and say we want to leave and he approves it but then when he has to kind of worry about what impact is going to happen if you are going to leave okay then he would go into the project management say software and try to see okay where are you allocated so he has to open yet another application okay and then you know multiple such things come into the picture and then you switch between applications and of course you are doing your job and finally you give your approval. Imagine a scenario if you are able to on the same user interface able to view first get the request of the employee get the project information also and then you have some way to communicate to your employee back saying approved or disapproved all that together won't it be a convenience you are now not you know moving around into multiple applications this all get merged into one application okay so that is the concept of the you know value which the composite applications bring and this is a very small example which I give people are now talking of you know bigger examples and in the companies where you know you have to collaborate with multiple people I receive an application I you know I need somebody else's input I have to forward it somewhere then he kind of responds and then I get it back then I want to you know work with yet some other application based on that input and finally I want to post it into a transactional system where I actually you know the application would persist the data now all such things can be very neatly done by what is generally termed as composite applications okay so the word comes from the English meaning of composite the compose part where you are now able to compose services number one make a bigger service you can compose at the application level so the consumption of the service also you can you know have composition in the picture wherein you will compose multiple services and then make an application right this is a slightly newer concept people have been also doing when you talk of integrations also this has been in the background but with composite applications it has come to the surface so to speak now it is becoming more apparent we talk about it little more but then the idea is finally yes it's a integration but then it's slightly done in a different way to achieve composite applications you may use the service oriented integration infrastructure as well but that's not a necessity okay you may call the services directly and still achieve it will depend on your case how how these services are going to be called and how many consumers are going to be there right and lastly at the enterprise level we see that people are also moving towards service oriented architecture in preparation to what we call as the business process management just to give you a background about what is different or what is business process management here what people are saying is now you look at the whole activity which a which a company does in terms of a process getting executed across departments okay when you say that what that means is there's a lot of interaction between systems first of all there's a lot of interaction between people of different departments and applications of different departments so suppose if you are talking of you know situation of accepting purchase orders where for a customer what you would do is you would have a website or a portal or a standard application where you would accept your orders but then that order information as a process within the company which in within sale the manufacturing company actually has to go through many steps okay so somewhere it has to be you know you have to check the inventory if you have fine otherwise you have to worry about what I'm going to do for this particular order you have to check whether this customer has enough credit otherwise you have to ask for advance payments if there are depending on the terms we you have then finally you get kind of reach a place where you want to give a order acceptance to the customer okay I will deliver and then value additions you may want to do you may want to give a commitment as to I will deliver on certain date and of course you want to mean that and you want to maintain that so you have a lot of other connections to different other systems which you want to do so if you I'm just trying to illustrate a small process but there are a lot of complexities now here to do each of this work you have to talk to different systems right now in the example which I gave so there is a web application there is a inventory system there is a you know available to promise kind of system which will do look at you know when the production will happen and when we will be able to ship okay there's a shipping system which might also be in the picture so all this have to be tied together and then we serve the customer in the front and we are able to give some notification to them now what people says in business process management is now because of lot of you know competition in the market and we want to be you know in the business we want to be very agile so we want to be able to change the process much faster it is not that at the click of the button process is going to change but then if any changes we want to do we have to be able to do them really quickly because the history says that the IT systems become a bottleneck in you know affecting these changes because when you want to change you have to do changes at the application level really you know we follow this the whole software development lifecycle we understand the requirements want to make the changes then test it out roll it out and things that that has to be quickened or made faster so how do you do that so one of the ways being suggested is you model the processes so this is the change or this is how it's going to be different you have the process in terms of a process model okay that model you now have tools which will help you to you know create executable process model one of the outputs or the standard way of the output which is given is BPL which you have kind of done sometime ago so BPL is the execution part so it executes in what we call as the orchestration server or the BPL server at that point you are actually going out to different systems and executing the various BPL entities or activities which are you know in the BPL which you have deployed there the connectivity is again through services and that's where SOA comes okay so that's why we say so when the intention is to go for business process management we say we see that people first want to establish a foundation and SOA is a good foundation to have so that then all the benefits of SOA also are accrued and then you will have a successful BPM in you know roll out okay so these are four you know four different ways or reasons why kind of we say that the people adopt SOA they are not very kind of mutually exclusive but then if we at a point at any point of time we want to look at or take a snapshot of the kind of activities which will go on at a customer's place then it will be much easier to classify you know because there is some connotation behind it when we say business services it would require simple set of applications which you service enable and maybe in terms of infrastructure you require application server to host the services if the application doesn't have if you move on to the service oriented integration then it calls for having a ESB kind of product to be installed and then a lot of services there and they are all connected so there's a different set of things which happen when you have service oriented integration when you talk of composite applications the assumption is you have all these services ready and now you are going to build these applications or using these services and as a top-top foundation for BPM you also will be investing in BPM tools and things like that it as part of your SOA initiatives one other thing I've used the word journey so that you know I want to give you a picture that never in a customer's place again that it's a single or a you know one short initiative that you do something and we have implemented SOA that's not the case it is actually now probably you will see that the lot of things which go into having a large-scale SOA in an enterprise you would want to build a foundation of services you will build simple as well as composite applications over it and then if the need arises you may have ESB kind of infrastructure also in place and that can go on gradually okay so in a sense it's a SOA journey which which which a customer actually undertakes and it is not that you you know like somewhere I read that you know they wanted to explain so they say so is not a product that you just take it in the market and install it it's not like that so it's a journey right any questions yes okay what are the features which the ESB provides number one is the ESB allows you to be accessed using multiple protocols okay standard way if you do or the ways which you have been taught right now probably you would think that only it is a soap over HTTP is the way to call services but then in an enterprise context you have applications we don't have soap support or you may have a queuing system message queues okay and you want to utilize because you are all your other legacy application is running that way and then you also want to use this new service so it is like protocol conversion if you want to do if I have to say it in a different way ESB allows you to do that okay so you can call this same service using multiple or a different protocols that is one of the fundamental features of a ESB next is people said okay I'm not I want to be able to you know call not exactly with the syntax which the WSDL of the ESB is providing I want to do it in a different way either there are some limitations or some other reasons so you could put some intermediate logic in the ESB that's called mediation whereby the call which you make from the application is not necessarily exactly in keeping with the WSDL okay so the the syntax of your soap call if I have to say that kind of gets converted so this mediation in between which can be achieved now ESB is first a concept so these are couple of features which ESB concept would provide but now people are actually giving you ESB product so it is available from various vendors so definitely they will add something more to be differentiate their product right otherwise what is the difference for people to choose their product so then they will have for an example I'll give you one example people say content based routing if you want so if you have multiple services and you want to you know for an example very simple example if a request if it's a multinational company and if it's a simple you know messages being exchanged with the French customer you want the French reply to come and with the English customer you want English reply and you may host two different services for that and then which service you will target will be handled by the ESB you are not going to say in your application that go hit the English service or go hit the French service so that kind of routing based on the content okay here the content was it will somehow detect that it has come from a French national okay so these are couple of the features which the ESB provides and overall the the main purpose is to be able to achieve integration to be able to call the services and on the other side to be used by certain applications any other question right but interoperability is more coming due to the this soap and such kind of web service standards which you are using but ESB anyway supports all this kind of yeah any other question so that's the background this picture tries to give you just this snapshot as to or an indicative you know idea as to kind of investments which would be required when you want to kind have a each type of adoption so business services is minimal investment the flexibility which you achieve is also limited service oriented integration you know demands little more so we talked about the ESB to be implemented composite applications still require much higher investment in terms of development costs you may have a ESB also installed but the kind of flexibility which it provides is much higher no any changes which you want to make you just have to make small changes in composite yes yes yes yes yes yes yeah right so now yeah if you break it up slightly more now the two things so we even assume that the services are there already now you will have to build build certain applications on top of that and when you say composite applications now till now I have you know not gone too much into details but you can have multiple types of composition okay in the sense there is static composition so I have one application and I would call multiple services but then the extent of complexity can also increase you may have the BPL kind of engine also incorporated in that and have better or more complex composition done okay there are you know examples where you can have all this kind of orchestration behind the scene and you could just expose your applications they are all examples of still composite applications here the composition is not static but a dynamic composition so in such cases you know the cost is going to increase much more okay and one more thing is you know this is just an indicative figure so you know if you if you kind of you know if we I cannot kind of defend in all cases that composite applications will cost more but generally this is what we see that if you want to have a case of composite applications there is much more investment but then as I said if you have a plain static composition kind of a requirement it may be on par or might be lesser than the service oriented integration also but that I would say is a one-off case see today the composition let us say the concept is kind of setting in today there are platforms to enable composition at least couple of composition environments which I have kind of looked at is one is from Microsoft now today their SharePoint Microsoft SharePoint server so today the recent version they call it Moss Microsoft Office SharePoint server 2007 I think that is the name Moss 2007 now that today is kind of repackaged or is being talked of in terms of a composition framework okay so they have kind of if you go to Microsoft site and look at what they call as office business applications okay so there's a site called OBA central I won't take time here well on that but so they have given you different layers where the composition can be you know achieved so they classify five layers I think they talk from collaboration layer process layer services layer data layer you know and and each layer they've given examples or they talk of how composition can be achieved second is SAP the ERP company so they are also now coming out with you know integrated set for composition so I think they call it net viewer composition environment okay where with the ERP kind of tools how do you build a composite application and in fact they may not have used because the net viewer composition environment but in the SAP world they have a set of applications called do it applications which are nothing but the composite applications you know the implementation of composite applications okay do a DUET okay and again that may have been the code name or you know the earlier name before release so the release product may not be called do it but in on the internet if you search for do it I'm sure you will get more details about that so today these kind of environments are coming okay and then there's a whole stack which will allow you to build composite applications yeah yeah the end users perspective the benefit is the convenience that in particular case of composite application he will be you know not required to jump on to different applications number one okay because all what you could do you can do in say one screen or couple of screens but they would all be one integrated desktop application for him or it could be a web application also need not be desktop application so it's a single unified interface if I if I have to say into different applications number one second is you know if you look at and this is actually a situation which happens if you talk of people who are doing clerical work saying warehouses or in the shop floors and manufacturing companies they have ERPs so SAP or the barn or that kind of environment you need to actually train them to use those applications pertaining to their job function okay he may want to check the inventory so he has to have access to SAP system so and when you want to do check the inventory there is a particular way in the SAP system where you have to go and you know press multiple options and then you would land up there then you have to train him then you may have to train him to get the report of how many items have been produced or you know in his shift today whatever he did in terms of he will kind of fill in how many items I did and then he may want to get a report back these are small functionality but then it's all in the SAP system it has to get posted in the transactional system and hence he's given the SAP user interface for an example that can be done away probably you may have a simple application where he just feeds in this number where we will have to take I mean application developers will have to take care how you would go and connect to SAP so we will use SAP services we may use a ESB and all that behind the scene to push the data into SAP but that way we have done away with the SAP interface for the end user I talked about the example for the project manager who is approving leave that's a very simple example which I to illustrate but then similarly if many of your day-to-day jobs are getting what say for an example that thought comes into my mind portals why are they becoming you know much more accepted because that's a window to many applications right you need not go on to various different sites and things like that or various applications in your company you can do sitting with one portal personalized for you in such way composite applications also and in fact I would put portal also as an example of composite application here if it is actually being implemented in a service oriented way I hope you get the picture it's the user convenience if I do very put it very simply it's the user convenience which the composite applications bring to the table now what I'm going to talk about is couple of case studies of how we have worked with our customers here I'll try to bring about you know what is what are people doing and how it is being done at different customers so this is a sample of that so what this picture tries to show in the gray is this is the how the existing application was structured with one of our customers on the left side where you see you know standard three tier architecture presentation business logic and the database nothing great there but it was used being used by you know 55,000 it's a big company so 55,000 users were using it so and a lot of and this application pertain to using you know all the kind of IT services or facilities which they wanted to use so if they wanted email connection or if they wanted you know additional software to be loaded they all could get communicated you would subscribe to that service and it would be kind of handled by the IT departments and they would be built okay this is a simple that kind of application which we are talking of the traditional way the application when it was developed was that the billing information used to get transferred to the SAP system which had the financial information almost you know as a bad job once in a month so all year how much of the service you have consumed or you know what expenditure my team had as a department head if I wanted I would have to wait for the report which would come out from a SAP system after a month or maybe later on so we tried to show them I mean we were actually maintaining this application but we wanted to show them the benefit of web services what it could do so that that will kind of act as a impetus for them to look at services SOA and so on we developed a simple set of web services for them and then tried to you know there's a picture of how each one or one is done but try to show that the same information now which the application was capturing earlier it was not available much easily to be you know taken out now can be done using web services so here we have a picture where these are all the new things we kind of try to do it for them more to show so we develop the services of course the services are not visible at the user interface level but then we use the services and build some of these rich GUI kind of applications you know this is just try to show you you know you're getting this information and now I've been able to present it in a much more better manner in terms of pie charts and histograms and things like that also you could use the same information or you could call the services from a mobile platform also so these are the things which you must have learned that about interoperability using services so different kinds of applications on a different platform can call them okay and even mobile platform is one of the examples so one of the things again in adoption now is customers are averse because when it is a new technology or a new wave they would want to they're not very sure whether we should go for it or not so one of the things which we do is what we call as proof of concept so POC stands for proof of concept as you do prototyping it's a similar thing but maybe the scale is a little larger okay so when you're unsure about things because it costs also there is effort to build a POC also but when you're unsure POC is a good way to kind of validate what you want to do so you could build a small case build a POC make a simple service make a simple application try it out and then you have the confidence that it all works you also know what is the kind of infrastructure it will require whether we have you know in terms of development capabilities in house to do it or we have to take help from somebody so proof of concept is also one one important you know mechanism to kind of get on to your SOA journey this is yet another example where this customer is a very old cost you know they have been in business for about 100 years so and they are into farm equipment now you know they have lot of customer information with them and they have now started new businesses so they have farm equipment but then they started to build much more sophisticated equipment for farmers themselves or they start moved into financing and leasing so when they wanted customer information you know it was very hard to get because this was only in one kind of application which captured so one of the things which again here we were maintaining their application so we said why not use web services you web service enable your customer registry that way now the customer information can be extracted out by any other kind of application also you look at the you know infrastructure they had earlier DB2 on mainframe you know and then they had earlier you know cobalt programs running there so that's indicated in the blue box then slowly over years they kind of have web applications also wherein they introduce a Java layer and then you know JSP and serverless kind of environment they had wherein they at least could give the customer information over the web but then still if you wanted a real-time you know information about the or the applications actually to have this information it was still not possible so web service was one way wherein in the business layer we kind of introduced we did the service enabling where which again you would have learned we would all just Java APIs to build the services and then expose it as a service and then they are they are on their own now to use the services by different applications so what the message here again is there are many opportunities also existing in the current applications which you have to now go back and kind of look at which you could reuse in newer applications you could make new applications just by doing a little bit of more work on top of your existing applications which you already have the third flavor of how people have been you know adopting services this is a case where kind of we engaged with a software provider company actually and they were working with a you know life insurance LIC kind of company this is a Danish customer who we were working with where they said we want to migrate the whole application number one so they again had you know cobalt based programs on mainframe where they were having a lot of difficulties you know maintaining the code because they don't find programmers there and then the cost of ownership of a mainframe kind of system is very high so one is they wanted to re-engineer and report the application onto a G2 platform but then they took this opportunity to also have service interfaces there okay and this was a very unique case for us where you know there was no user interface for this application they said okay you just give us service interfaces you build this whole you migrate this code port it on to J2E but then give only service interfaces we realize the fact that you know testing the service interfaces was going for a real difficult challenge for us okay we had to bring build our own frameworks but again the message here is there are some kind of customer who are actually based on total cost of ownership and such considerations are putting the legacy applications on to newer platforms and at that point of time they are looking at also service enabling their you know their applications and then you know and that's part of their SOA journey