1. John can you introduce yourself and tell us what you are working on?
Hi my name is John Crupi, I'm the CTO for Sun's Enterprise Web Service Practice and this is the field customer sales organization focusing on solving customers' problems.
My group focuses primarily on SOA today and SOA is an architectural style and what we are trying to do is leverage the work that we've done in J2E with patterns and apply that into SOA; so everything we do is trying to identify patterns whether in the patterns of the problems that exist, or the patterns in applying solutions; we look at the architecture we're taking the same approach that we did with J2E but on a much larger scale with SOA.
3. What is the typical size of companies that you think are interested in SOA?
Typically medium to very large companies - Fortune 100 Companies - and they are looking at it from all aspects. We work with The Defense Department in the US. Some companies look at it from a project perspective, others organizations - like the US Government - would look at it for creating an infrastructure and providing a set-up of core services to all their members.
4. So service oriented architecture, hype or reality?
A little of both there's a lot of hype behind it. Everywhere any integrated vendor that existed or exists has put some SOA in their tag line now and I think there's a lot of press, there's a lot of hype about it, people get a lot of the analysts' projections. From the last three years you see that they in fact missed and were a little optimistic about who would be on SOA at this point, but there's a lot of reality to it and really the nice part of it is that SOA really encompasses a lot of good architectural practices: strong layering, loose coupling, separation of concerns and what it does, it is really an architectural style that has to be applied to your integration. Where there is a lot of hype is the misconception that it is easy to do and sometimes we need to tell customers that it is not a "buy", it's a "build and buy"; if you are going to buy a product or use an open-source product you have to build the architecture, it's architectural driven and if you don't have the architecture in place there's no product that out of the box will give you SOA today.
SOA is an architectural style, but at the end of the day it has to run on a platform; and you're probably not going to write your own implementation of the UDDI registry or ebXML reg/rep or even write your app server, write your own web service container. You're not going to do that. You're going to use products to do it. Whether it's a vendor or an open-source product, it doesn't matter, but you want to adopt standards to do it. Standards are what really make this ubiquitous and they really get this in tools, get this in products and really force all the vendors and communities to compete on providing the best platform, so you have to create the architecture and eventually you have to chose a platform to run this architecture on.
I think that you're talking more on a grander scale. With SOA we're really looking at the granularity of what we call business services and we get into this debate of how coarse grain, how granular these services are. There are a lot of fights among designers and developers about: that's too fine grain, that's not coarse grain enough, and it's relative. We think that the granularity is at the business level. We're actually spending more time talking about the alignment of the business unit and the IT organization to make SOA successful; that means that the business unit has to drive the requirements, and IT and business have to work together so the granularity of the service is the key to actually start exposing the services for the business. Now because we are working closely with the business unit, and the IT organization is working closely [I've just heard a talk by a consulting company where they trained business analysts. And now they are finding a new breed of business analysts who understand service-oriented architecture. And the difference from a service-oriented approach versus an object-oriented approach is that when we approach service oriented architecture we're looking at business granularity of services, but really the driver for the requirements is process. So when we work with analysts and we're identifying the processes because we like to start SOA and make it incremental just as good practice and we don't go and chose a hundred of use-cases, fifty processes. We actually chose one or two, we identify the core processes then identify the use-cases and it's those business processes that drive how we are going to start exposing the business services and what business services we're going to expose. So from the perspective of the analyst and the analysis and design, you drive them from the business process and the process would help you look the touch points which eventually would start realizing the service level of granularity that you need to expose.
We're talking about architecture here and a lot of SOA, the big A is the architecture. So what we are trying to do is we're taking both from a business perspective, looking at the business requirements and business processes and we're taking it from this perspective: "How are we going to start understanding and modeling the systems that we're designing?" First of all there are some strong architectural principles that have to be in place. We call them big rules and you can choose the ones you want, but we found out that the design and architecture teams that are the most successful are the ones that understand and agree on these principles. We have principles such as business grained services, the granularity of a business concept and business functionality, loosely coupled is a primarily objective, mostly asynchronous We believe that because the way SOA is architected it's not chatty, it's not tightly coupled so you're exchanging business documents and just that level of interaction style lends itself to be more asynchonous for scalability. We believe that XML schema design is essentially your first class citizen in your contract. Instead of defining interfaces like we would, you're essentially defining your contract as business documents and these are most often represented as schemas; so when you're exchanging documents across the wire, you're exchanging really a realization of schemas, whether it's one mega-schema that has all your use-cases and you have to pull out the parts that have been populated or the use-cases are finer grained associated with the schemas at a lower level, it doesn't matter, it's a choice. But you're actually exchanging documents, so these sorts of architectural principles are key to get in place so that you're not arguing about RPC style versus document style.
8. So what place does RPC still have in a SOA?
It think it has some place but in not much of a place. I think we've learnt and you've seen even the naming convention JAXRPC is moving up the chain into more web service and has been renamed JAX-WS (WebService) and the design center is different so the object perspective where we have RPC style, we're talking granular services and we are not so interested in the interface as much as we are in the contract that exists between the documents we're exchanging; so whether I have one operation on my service receive the document and I do content based analysis or I have operations that are relevant to the use-case, it doesn't matter, it's a design choice. But that's the contract and I'm designing and tooling around the document centric exchange versus the RPC centric.
9. What are some success stories around SOA that you've seen? How are people using it?
The areas that we have succeeded with customers is where they have taken a project or an application or small set, and said: "We know that we want to open this up, to internal to build applications and realize these services that we have now as a way to build applications in our organization; so they may have had one monolithic application and now they want to expose it as business services and they've taken it from the approach of "we want to focus on an application and then we want to incrementally show and realize how we can be successful with SOA". We've done this with customers where we've done an assessment to look at the risks and they did a proof of concept; we always recommend this because of the organizational issues that have to be in place in order to realize the right architecture and to get the right requirements, so business and IT have to be aligned like we've said. But we're noticing that in the J2EE days we used to prove out the architecturally significant use-cases so this means that when we were proving out J2EE to customers years ago, we had to prove that J2EE would work, so we would find the architectural issues that were hardest to prove out and prove them. In SOA, where we have been successful with customers is finding the business significant use-cases and what this means it's about 75% technology and architecture and 25% sales and marketing; customers are saying "Let us get these solutions and prove out the solutions using SOA in our system, but also help us in a way where we can demonstrate this to our management to sell it", because we are still in a selling phase. That means that instead of showing "here is J2EE" with session beans and talking to a CICS back end, now we are saying to the customer and management "we were able to issue an equity trade and build this new functionality and it took us three weeks to do and in the past it would have taken us six months", so you have to put it in the jargon of the business and help them essentially selling up their chain, so the business significant use-case and the whole business mindset of all the applications we're doing for customers seems to lend itself to the most success.
10. You described some of the architectures. What could they do they couldn't do before?
In almost 100% of the cases we had systems in the financial space (a very relevant area for customers) where they've had services and applications and they wanted to expose them not just internally but to partners at the same time, so there have been the use-cases and requirements that have said "we're going to open up our services and we may have a trading service or we may have a purchasing service and we're not just opening it up to our other divisions, we're also opening up to our partners and they are going to be equivalent." That is a very good business requirement because maybe the IT organization didn't know that the partners were going to be a part of the solution. Do I have to architect it differently? No. But my systemic requirements and my SLAs (Service Level Agreements) that have to be in place are different, because if I'm opening up services internally, I may have different security, privacy and policy requirements. They are opening up my circle of trust to partners. So where we have been successful is where our customers have actually build applications and had governance in place and build that in to the architecture. The types of applications really cross all different industries there's no industry that would say we're going full force The financial industry seems to be a bit ahead of their industry because they have a basic need to the sharing and service exposure of a SOA. But we've seen it in the pharmaceutical area, we've seen it in the health industry; everybody is looking at the same thing and the business requirements tend to be the same, the granularity of the services tends to be the same, everybody is running into the same problems, typically their organizational problems, making sure that everybody is brought in and aligned; technically it's not that big of a problem, we're relying more on tools and vendors and open-source projects to actually help us with realizing the specs and standards. And this is sort of the secret source: you don't get locked into a vendor's product; you're really adopting a standard. These products have to enable standards.
It's everything. There's no common system or typo system, they are looking at systems that they've had in place for a very long time; they could be CORBA systems, CICS systems, and Proprietary systems. There are a lot of systems in the government that have been built proprietary, especially in the intelligence world where all these different systems (correlation, fusion etc) were build to be "just stand alone systems". Anything that was build to be "stand alone" are those type of systems that are being tackled. One of the tendencies is that we don't rip and replace. We don't take a system and say to the customer "Ok we take your CORBA system and completely rewrite it in Java as part of the SOA". What we are doing is we're leveraging those resources, we call it the resource layer, and we're really identifying what services we are going to expose. For example, if I have a CORBA system or I have some sort of system in place, I'm going to take, identify the service and than wrap it. And typically our customers wrap in Java and there's nothing that says it has to be J2EE, it could be Java, it could be running on a Web container and expose it, whether REST style whether WSDL it doesn't matter. But it's a facade over the services. What we do is we've seen the bad practice where the customers have taken an inventory or check list and said: "Ok here there are all the services that we have today let's just wrap them all and make them all Web services". That's a recipe for failure. We identify the services, the granularity and these services may actually be talking to multiple types of systems that could be completely proprietary. The hard thing about this is to take the system and lop off the head, that essentially if they had an UI and everything was controlled, security management, and to actually break them apart and expose them as services highly complicated, and that is one of the areas that presents huge risks in understanding how actually a system can be exposed as a service. So there's no set recipe, every customer has a whole slew of stuff that need to be exposed and it is really the loose coupling that has to exist. Breaking up the tight coupling is the hard problem.
12. So what are some of the approaches you have seen that work for service composition?
For example RouteOne who is a customer. Somebody has asked us recently: "Do I go and I produce my WSDLs and then give it to the integrator who's defining the BPEL, the business process and then they go and call "I'm a partner so they make calls on me." Or does the business integrator provides the WSDLs that need to be implemented by the various partners. I think it is really just based on business decisions and what has to happen, we can't lock architects into one way. We don't want to say "Ok you're going to do your business process and then you generate the WSDL based on the conversations, and hand that over to your partners." If you have the luxury, that works out well. I think RouteOne was a company that was able to do that .They said "ok here's the WSDLs you'll go and realize, and if you're going to be a partner here's the WSDLs and the schemas as represented". That's a nice case scenario. But the reality may be that you may not have the ability to do that, where the services or the partners may say "here's our URI, that is we registered our WSDLs and this is what we are already exposing. We are not going to change that to accommodate you talking. The transformation has to happen by you. We need these data, we'll send back these data. So when you get into this where's that transformation happening? Is it built in to the system at the edge so that you're sending documents that don't need to be transformed or handled by each party? Or do you have to do a lot of transformation? Basically it happens in both ways.
13. What differentiates service oriented architecture from simply using web services?
I think it's about the architecture in place. SOA does not equal web services, and web services don't equal SOA. We've been trying to do service oriented architecture for a long time, it's about loose coupling, we think asynchronous exchange, it can be synchronous, and it doesn't really matter. We think that web services tend to lend themselves this, because they are based on open standards and it gets into tools, so tools know how to consume from a registry, we get things into standard based registry, we pulll them out, all the work is done. We can have zero deployment and we can literally do that and it's amazing because we can have multiple tools pull this up. I think this is really one of the key elements understanding how web services really leverage. But to put it all together as an over-arching architecture, that's the SOA part. Just because I put a bunch of services there, doesn't mean that I'm creating an architecture around these services. Some services lend themselves to being atomic, maybe Google puts out a service, Amazon where I can go look for a book, do a search and I get it back, but in business where you have to have an architecture and really what puts us all together are the processes that we expose via composite applications is being able to put the exposed services and to be able to orchestrate these services to create a higher value or bigger service in itself. The process layer that we've exposed is itself also a service, but to the user that is consuming it and they don't know that the service is orchestrated with the multiple services, web services underneath. I think it's really a difference of one has really a bigger architecture built around it and one is more of an implementation detail.
14. You were talking about SOA governance these days. Can you provide some clarity?
Probably not because that is an overused terminology; many vendors have SOA already in their header, and now SOA governance seems to be appearing everywhere. I think it's completely overused and diluted, but it's a key element of SOA and the reason is that there are various elements in the lifecycle of SOA that have to exist, that you govern. Some people are saying "governance is in the registry" and of course that's part of governance. So what get into the registry, what schemas can be referenced, what other services can be referenced and dependencies may be part of the overall governance of your design time. Who can access your service? (And I'm not talking about authenticating, I'm talking about authorization to access. Where did those policies exist?) So really at the end of the day SOA governance is around policy as an implementation. The various levels of it in where it exists, I think that first you have to have a SOA governance architecture in place and then to understand what it means. I think it has the start at the design level. How do you put an environment out there for SOA to run on and what is the architectural design governance that you have around SOA that you want to exist? How do I as a developer who would deploy your service, how do I that I'm actually designing a service that adheres to your design governance? And this is a harder problem. Most companies put governance committees in place, you submit something and they review it, they hand you the big document and they go back; that's time consuming, we need to automate that process more, we need to actually put governance into complete lifecycle from the beginning all the way to the end. I'm spending a lot of time focusing more on designing architectural governance, on how we can institute that in policies around that, early in the development and lifecycle phase.
15. What are some mistakes companies are making in applying policy? Can they make too many policies?
I think you have to be careful too about policies. Are you using a proprietary extension of a vendor's registry to do policy or are you using standards based policy, WS policy, XACML, what are you using for the policy grammar? And then it gets into how much policy you are putting in place, there's global policy and there's local policy and it just gets into almost a mind-boggling, area where we are going to focus our policy. I think there has to be a governance architecture and infrastructure in place first and foremost; and then the tacking of various systemic qualities and requirements that you have for say the government has multilevel security as a big requirement. How do you institute policies? Policies are opaque there's a grammar behind them, and they are doing something so. "What role do I have? Do I have this role at this time and can I access this information as a service?" I think there could be such thing as too much policy but I don't see that happening. I see no policy happening. And people wondering how I actually do governance, how I do create policies in a standard way, so I don't get locked in, so I basically get into a proprietary fix essentially.
Yes I think that from the design and development architectural governance we haven't seen much yet. From the governance of registering I've seen that it's being the first foray into governance where customers are being mildly successful, where actually the governance happens when you register and maybe that registering is a test or development service that's being submitted for analysis. It's where you look at and you examine the WSDLs for certain things, you examine the schemas that are referenced, ( I've seen where the policies that exist the schemas must be from these locations or must be registered or approved. That level of policy is working. And we're talking right at the beginning of registering; so also where your schemas are treated as first class citizens, those are the type of governance plans that we see as our most successful right now.
It's your choice. You can use the file system to look it up, if you think that's scalable. If you're going to use a file system you have to ensure that you can get to the file system; the nice thing is the location transparency that you get, the control, the management, the governance that you get when you register with the registry and all, so if you're using a UDDI or ebXML registry it just really lends itself to doing a lot more, because a lot more governance is going to happen when that starting control ends up in the registry. We promote it, but we don't say "You have to use that", but we see that more and more companies are choosing registries as a way to store their interfaces.
18. What should be loosely coupled versus tightly coupled?
It's a great question because in my past talks sometimes people would come up to me and say "I understand the value of loose coupling but why would I want to loosely couple everything?" And that's not what we were saying. We think about loose coupling and eventually somewhere along the line you have to be tightly coupled, somewhere in that in that system it gets tightly coupled. We're just delaying the coupling and we're delaying it for the flexibility that we can achieve. So when we open up these services and these processes the loose coupling means I don't have a strong dependency so now I can build composite applications or build systems that consume services and interact with them. But I'm talking about a different architectural style, an interaction style, I'm sending documents over, I'm not very chatty and I am by no means sending a ton of data through, I'm not streaming data. When it gets past that service that's exposed you're still going to have to be tightly coupled to something. You're not going to loosely couple your database as a web service most likely and you may have a system in place where you may need a strong connection, you need tight coupling. That's where you get the performance that you need, that's where you're tightly coupled and you have a connection based system; those things need to exist. You're exposing a business service, that's where the loose coupling has to happen. That's a misunderstanding sometimes when people hear SOA, they think everything gets loosely coupled and nothing is tightly coupled anymore. But that's not the right interpretation.
19. Any final words for SOA architects?
I think that the one thing you could do and something we've learned is that the more we talk about SOA, the more we institute the business side of SOA. And SOA in our view is more about business than it is technology and you have to get the business unit and the IT aligned to approach SOA together. If the business unit is here and the IT is here and they don't work hand in hand and try to boil the ocean instead of incrementally proving out your SOA, then you're never going to be successful.