I had the pleasure to participate in Keynote SOA panel discussion at BEAWorld 2005 in Santa Clara. If you’re interested in watching the entire keynote, it’s available online here. To get to the good part, skip ahead to around 2:38:00. We had a general idea on the topic we were going to discuss and so I have put down some thoughts about the questions and topics in general. Given that we didn’t have a lot of time during the keynote, I didn’t get an opportunity to make all my points. And so here are the additional thoughts I probably would have convened, had we had more time.

1.What are some of the challenges that developers face in implementing Service-Oriented Architecture?

There are a lot of challenges facing developers and organizations that are in the process of implementing Service-Oriented Architecture. Being a technical person, the technology part is easy and most developers and architects in the audience would agree. One of the biggest challenges a lot of SOA efforts run into is the lack of business alignment. If your business partners are not involved and you treat this as just an IT project, your chances of success are fairly limited. The biggest benefit of an SOA is that it allows a business to be agile and nimble and respond quickly to changes in market condition, mergers and acquisitions, competitive landscape and regulatory or compliance changes. So SOA’s should be seen as business drivers and not just a technology project. Another big challenge a lot of IT organizations face is that they need to shift from creating implementation-specific functionality or silos and move to creating standards-based services.

Another challenge is the upfront costs – Organizations will have to invest in tools training, process and organization changes. Part of the organizational change is the whole governance effort. If your organization has dedicated line-of-business development teams, you will need some new organizations structure to provide technical leadership to bring these teams together and focus on the global business issues. Governance is usually the part that makes or breaks a SOA effort. Different development teams aligned with their individual lines of business have their own set of priorities and deadlines. They usually need to be convinced that the bigger picture view of the Enterprise is just as important as building or leveraging services is in the overall interest of the business. There isn’t a tried and true approach to getting SOA in your organization. In my case, I went to my CIO and his management team about 3.5 years ago and they gave me their blessing to move forward. But working for a Financial Services company also meant that IT-spend was really tight due to the horrible market conditions. So I took the approach of starting small and creating 1 simple service that became our killer-app. I implemented something we internally call the ‘Security Framework’ – The Security Framework was written in Java with an stateless EJB as a façade and you can could call the EJB directly or call the Web Service or use the Axis and WebLogic client I had created. The Security Framework taped into most of the authentication stores inside our network and so applications that were using the service could switch their authentication from a database model to Active Directory without any coding changes. If we implemented another authentication mechanism, the service would code that and not require all the clients to do anything. The service also offered roles or authorization and auditing functionality and so the developers were compliant with our internal authentication, authorization and auditing standards as they use this centralized service. Since then, our SOA effort has blossomed and we have a lot more services but we are not at a place where we need an ESB – We are in the early exploratory phase of the ESB to see if we need any of the services provided by a service bus.

Another big challenge is that there are very few mature SOA methodologies available today and so organizations will end up spending time developing their own methodology.

The operational aspect of software deployment also ends up becoming a challenge for a lot of organizations. With services acting as ‘black-boxes’ with many consumers, upgrades, back fixes, new features, versionining etc become big issue and best-practices haven’t emerged yet. For example, we virtualize our servers and individual WebLogic instances with a service-name that points to a hardware load balancer (F5 Networks BIG-IP). So a WebLogic instance running on Server A (or a cluster) listening on port 8000 could have a name like p-securityapp-v2 and another WebLogic instance running on the same server listening on port 8001 could have a name p-securityapp-v3. As long as client(s) externalize the URI of the service in a property file or some other store/resource, they can upgrade to v3 of the service by just changing the property file (and testing). So we can move our services from server A to server B and all we have to do is change the load-balancers’ configuration and everyone is automatically using the new instance. In our organization, we encourage people to upgrade and use the latest version of the service but the old service never goes away. Not the best solution but it’s easy to convince people to use something if they know that they will not be forced to change something in the middle of a development cycle for another effort.

The second part of the operational aspect is monitoring – There are very few tools on the market today that will allow you to monitor your services and surface the information to a business dashboard or console. I am looking forward to checking out the pavilion to see what people have been working on and how they can help Enterprises better monitor and track issues.

2.What are the advantages for developers in implementing SOA?

There are several advantages for developers in implementing SOA and one of the biggest one is that SOA allows the developer to focus on the business logic and implement functionality without having to worry about the other details they typically focus on. As services have a well-defined interface that is independent of the implementation, developers are free to implement their code in any programming language and so people that feel comfortable with Java can stick to Java and people that feel comfortable with .NET can stick with .NET. Vendors may not like the idea of mixed or heterogeneous environments, but they are a reality for most of the organizations and having a Java-only or a .NET only solutions or standard doesn’t make sense. Besides, it’s ludicrous to think that one vendor’s stack will solve all your problems. Having multiple vendor stacks keeps them honest and gives you options.

Another great benefit is almost a side effect but having a well-defined contract enforces good design practices.

Developers can decrease development times by using pre-built, reusable services as building blocks and create loosely coupled systems that are flexible and can adapt to changing business conditions. It’s great to be able to leverage components that are deployed, documented, tested and certified internally as you don’t have to reinvent the wheel. Instead, you can spend the time saved on other efforts for the business.

As an aside, there is also an industry effort called SOA Blueprints that is designed to help organizations build applications using service-oriented architecture (SOA). SOA Blueprints creates a common vocabulary to discuss SOA in an architecturally neutral way allowing comparable implementations to be crafted using different technology sets including J2EE, .NET and Web Services.

3.BEA sees great synergy in blending open source solutions with commercial technologies. Can you explain situations where you may have successfully used an open source framework in combination with WebLogic Server?

I see great value in blending of open-source and commercial solutions as a lot of great innovation is coming out of the open-source community and the ability to pick the best-of-breed components and deploying them inside WebLogic is very powerful. We’ve had great success in blending WebLogic and JRockit with open-source solutions like Struts, Spring, iBATIS, AXIS, log4J and many other great tools. Let’s take the example of Spring, which is a very popular Java/J2EE application framework built on the idea of Inversion-of-Control. Spring offers great data access and transaction management capabilities that allow you to implement your data-access layer using JDBC, iBATIS, Hibernate or JDO in a standardized way. All of our data-access components use Spring’s DAO framework with iBATIS under the covers. In this scenario, we are using the robust connection pooling and transactional capabilities of WebLogic while using that simplified POJO based programming model of Spring that eliminates unnecessary complexity often associated with J2EE.

Struts is also a great example of how we leverage this MVC-framework on top of WebLogic. Our web applications are built using Struts, which has become the de facto standard for UI development. All of our Struts application are deployed inside WebLogic and leverage our services-tier that’s based on EJB’s and Web Services. Another framework we’ve had great success with for external integration is the Apache Axis product that is an implementation of SOAP. Using Apache Axis, we’ve been able to leverage Web Services deployed inside WebLogic from Tomcat, JBoss and command-line or batch applications.

BEAWorld, SOA, AquaLogic, Spring, Struts, AXIS, WebLogic