CRN Interview: Byron Sebastian, BEA

Technical Editor Mario Morejon recently met with Byron Sebastian, vice president and general manager AT BEA Systems' WebLogic Workshop and Portal Group, who offered advice on overcoming some of today's technical hurdles when building Web services and a service-oriented architecture (SOA)

CRN: What should solution providers do when wrapping Web services around legacy applications that either have poor interfaces or were never designed to work with other applications?

SEBASTIAN: The first thing [they] need to understand is that service-oriented architectures are not a cure for all your architectural issues, and it might not make sense to wrap everything as a Web service. Mission-critical, monolithic applications are important but do not need to communicate with other applications that might not [be appropriate] as Web services. To [BEA], the value of [the] SOA is in combining different types of applications built by different teams. If you need to streamline a process by combining applications into one large application, then SOA makes sense.

CRN: If you decide not to wrap your applications as Web services, then is re-engineering a better approach?

SEBASTIAN: Web services' wrapping business logic is missing the point. Those systems change over time. You want to be able to isolate those systems from the people consuming your Web services. If you simply provide a wrapper around that logic, then you haven't gained anything. When you change that logic, the wrapper is going to have to change as well, so the method of communication must be decoupled from the private implementation. The key value of SOA is that it allows the interface of your implementation to be loosely coupled. It is a layer between the services interface and the implementation. If the mapping between the application and the interface of your implementation is designed properly, then when changes are made the service can remain the same.

id
unit-1659132512259
type
Sponsored post

CRN: If you do not re-engineer your applications, would you then agree that bridging logic is required in these legacy applications?

SEBASTIAN: [BEA] sees lots of customers [with] a mapping layer between their Web services interface and their implementations. For example, the internal representation of your application might be a C class, but a trading partner might have a different implementation of a purchase order, so mapping is essential to [different] logic. Typically, connecting all your services does not add a lot of value. You would want to build some intelligence for how they are connected together, build some validation of data that is being passed back and forth, or orchestrate some of the processes. We see people build a loosely coupled services layer around their existing systems, and build some new Web services with some logic designed to make their enterprise more efficient.

CRN: What cultural changes should take place in enterprises for SOA to be widely adopted, to have the success of HTTP, for instance? How do you recommend solution providers convince their customers?

SEBASTIAN: The key is that this is a very different architecture. There are a lot of new challenges around programming using XML interfaces and interoperating across multiple systems. The successful enterprises and solution providers I've seen have adopted an overall vision for where they want to go with Web services, and they have adopted a central architectural strategy around it. They start big, but then they work very small, with proof of concepts. In my experience, you need to give your architects and developers hands-on experience of what it means to develop interoperable systems and what it means to develop a smart mapping layer between the service and the implementation.

CRN: Where is the metadata standard used in Workshop's code generator in the review process and have you seen any vendor adopt it yet?

SEBASTIAN: The key JSR [Java Specification Request] for using metadata in Java is JSR 175. Sun [Microsystems] is leading it because [BEA] saw this being important to the Java community. Sun and our partners happen to believe in it and have their own vision of where they wanted to take it. The spec for JSR 175 is under review right now, and it is relatively late in the process. I don't know if anyone has adopted this standard.

CRN: What can Workshop users expect next year from your development team?

SEBASTIAN: As part of Workshop and as part of what [BEA] is trying to do here by sort of redefining development and development environments for the enterprise %85 we have a project called Daytona that's focused on a number of things. It's focused on providing new capabilities as part of the platform. It's also focused on building a community of solution providers [and] ISVs for extending the platform. That's a key part of Workshop that it is completely extensible. [Daytona] will make richer information, data and samples available to developers. This is an overall initiative that the public will be hearing about in the next three to six months. [Daytona] is going to make it much easier to deploy applications, which [BEA] thinks is a very important part of the overall mission of making enterprise computing much easier. [Daytona] will be focused on a lot of open standards and portability..