| QUESTION & ANSWER |
BEA's Carges on portals, Ajax |
 |
By Michael Meehan, News Writer
04 Oct 2005 | SearchWebServices.com |
|
|
Before becoming chief technology officer at BEA Systems Inc., Mark Carges headed up BEA's Enterprise Framework Division -- including integration and portal products -- and was one of the original architects for the Tuxedo transaction system.
part 2 | part 3What is the importance of portals to the application layer and how has that relationship changed, thanks to service-oriented architecture?
Mark Carges: Initial portals were about connecting the user interface and what you wanted to see directly to the back-end applications. If I was building a customer self-service portal, I would connect back to the customer systems whether it was the mainframe that had the customer data or the order systems, so I could see what orders I have or the trouble tickets. But what is happening and what's evolved is these portals and these systems of information with SOA are requiring that all of the different services be available and then brought out to the portals in ways that require more of a loosely coupled model. Rather than tying to the portals directly to the back-end systems, I'd like to tie them to maybe my service infrastructure or my bus technology, which knows how to get to that infrastructure so I don't have to worry about it.
As a portal developer, I want to think about the different processes that I want access to, the different services I want access to, and then I'll use my service infrastructure to make sure I'm brokering and getting out to those. I've inserted something now in the middle between the portal and all of the different business processes. What that does is create sort of a different architectural approach and a different set of tools required, because now I'm not trying to do integration with my portal and tie a string from my portlet right back to the system of record. Then I'm trying to say what process do I want to bring in here, how do I get access to that process and what tools do I use to configure that?
What we're doing with the WebLogic portal, as well as with our service infrastructure, AquaLogic and Plumtree, is looking at that process end-to-end and being able to provide that infrastructure to get to the back-end apps, provide the different kinds of tools required to build out a sort of a process-centric portal. I can build out collaborations very simply. I can still give developers that fine-grained control.
Does the Plumtree acquisition help you to better access .NET back ends?
Carges: It's not so much that Plumtree gets us to .NET back ends better, because today we can do that with WebLogic, as well largely because of the interoperability afforded by Web services. Many customers want to run their portal environments in .NET infrastructures or maybe have Visual Studio developers building many of the things that show up in the portals. That's where it really comes in. Plumtree has the tools and technology that run natively in .NET environments.
So a customer might have all these services in the back office running on various packaged apps or mainframes or whatever it might be, but on the front end what I really want to use is a lot of the .NET technologies. That's where Plumtree helps. If they say they're doing things in Java and using that infrastructure, WebLogic can do that very well, but if they say, 'Well, we're doing a lot of front end stuff in .NET,' then WebLogic doesn't play there. I'm talking about someplace where over half of their deployments are on .NET, meaning their portal server runs on .NET and a lot of where the information is coming from could be a mix of .NET and Java, but it's hosting the portal in a .NET environment.
How big an impact do you see Ajax having on making these New Age services and applications pop for the end user?
Carges: I think the importance will increase in the near term because of the kind of experience the user will get where direct input will have direct change. It's immediate, no flicker, no delay going back to the server. They'll feel an experience that's different and then what will happen is, of course, their expectations will move to that level. Right now they interact with a portal. They know they fill out a bunch of stuff. It's like the old 3270 synchronous terminal. That's sort of what it is today. You fill out a form, you hit enter, it goes to the mainframe, it comes back. Filling out forms in portals is a similar experience today.
What Ajax does is help bring a lot of the ability for not only the instantaneous response, but you can also get things like interportlet communication happening where you start doing something in one portal and it affects another portlet on the same screen. That just helps give a better experience overall. You can use that when you're reaching out to your customers. Your customers will want to interact more with your portals. They'll feel it's a better experience, they can do things faster, more efficiently. It's one of those inexorable make it better, faster, simpler. Ajax is going to help do that. Anything to make the client experience richer.
Can we expect to see BEA adding lots of Ajax functionality to its portal and developer tool kits over the next six months?
Carges: The version of WebLogic portal that will be coming out early next year -- we're actually showing some of those capabilities sort of in pre-alpha stage in the demo area [at last week's BEAWorld conference]. I know just seeing some of the things that the folks at Plumtree have done, they've started down a similar path for the same reasons. When you're talking about your user interaction technology, Ajax is available to make that experience much richer and we're excited about that.
|
|
|
|
