By the end of January, BEA expects to deliver a test version of a product code-named Quicksilver, which will combine standards-based integration software and Web services management tools.

BEA is marketing WebLogic Platform as an important building block for a services-oriented architecture, or SOA, a way of designing and running applications that allows companies to use a single program in different scenarios. For example, a company could develop an application for checking the status of a purchase order. A number of different programs, such as a manufacturing system or a customer service application, could tap into that purchase order program, potentially saving development time.

Industry analysts predict that corporate customers will move to a services-oriented architecture over the next few years. Competition among potential providers of SOA infrastructure software has heated up among IBM, Microsoft, Oracle and SAP, as well as smaller specialized companies. Open-source application server providers, notably JBoss, are also challenging BEA's business, according to analysts.

A major improvement in the core WebLogic software is Quicksilver, which provides a way to send data via messages between applications using standard protocols. Web services applications, considered the foundation of modern services-oriented architectures, are designed for sending messages between systems, rather than hard-coding connections.

BEA's existing integration software, called WebLogic Integration, will be upgraded in the Diamond release with support for the Business Process Execution Language (BPEL).

Will Quicksilver shine for BEA?

The application server will also add features to ensure that individual programs, or "services," do not suffer outages, Viarengo said. With BEA's next application server, customers will be able to test new programs and install patches across a cluster of servers without having to restart the server software, he said.

I'm sure this will work just as well as hot-deployment. yecht.

Your point is?

Never had any problems with "Hot Deployement". Use it all the time.

A major improvement in the core WebLogic software is Quicksilver, which provides a way to send data via messages between applications using standard protocols.

Which "standard protocol(s)"?

.V

What is the differnce between JMS and QuickSilver???

While not being the definitive expert on QuickSilver, I think I can mention a couple of things that makes it different from JMS.

First of all QuickSilver will be able to manage web service endpoints. This includes routing and filtering of messages to and from web services that are registered in QuickSilver. It's important to mention here that web services don't imply SOAP over HTTP, it can be JMS based services as well. QuickSilver aims to provide transparency to the specific transport protocol that is being used.

Think of this: Containers that host managed services will increasingly be required to control and monitor the messages that flow to and from these services. Today they mainly control and monitor the deployment of the service. I.e. they provide clustering, reliability, monitoring etc. of the service instance (I freely use 'service' instead of 'application' here). Furthermore the containers will be required to work together in a global address space (or at least federated) so that services can truly be deployed anywhere and still find out how to exchange message with each other. All this requires additional capabilities in the containers. QuickSilver is an effort in this area.

Jesper Joergensen
BEA Product Marketing

While not being the definitive expert on QuickSilver, I think I can mention a couple of things that makes it different from JMS.First of all QuickSilver will be able to manage web service endpoints. This includes routing and filtering of messages to and from web services that are registered in QuickSilver. It's important to mention here that web services don't imply SOAP over HTTP, it can be JMS based services as well. QuickSilver aims to provide transparency to the specific transport protocol that is being used.Think of this: Containers that host managed services will increasingly be required to control and monitor the messages that flow to and from these services. Today they mainly control and monitor the deployment of the service. I.e. they provide clustering, reliability, monitoring etc. of the service instance (I freely use 'service' instead of 'application' here). Furthermore the containers will be required to work together in a global address space (or at least federated) so that services can truly be deployed anywhere and still find out how to exchange message with each other. All this requires additional capabilities in the containers. QuickSilver is an effort in this area.Jesper JoergensenBEA Product Marketing

What a great idea! We've been shipping the above-described product since March 2002. ;-)

http://www.sonicsoftware.com/products/sonic_esb/technical_overview/index.ssp

Gordon Van Huizen
Sonic Software

Indeed, this functionality exists in other products on the market out there. Hats off to the early movers in this space!

However, ahead of us still lies the task of converging the mindshare of application development and application servers with that of MOM and message based systems in general. It is my impression that most people have either one of the two backgrounds and it is still very much two different ways of thinking.

I come from the application server / app dev side of things so I still have something to learn about the message based world. But it is clear at this point that a message oriented approach is key to succeeding with SOA. J2EE has the foundation for this in JMS, but as the success of early movers like Sonic have proven, there is much more to it than just the transport layer.

Jesper

First of all QuickSilver will be able to manage web service endpoints. This includes routing and filtering of messages to and from web services that are registered in QuickSilver. ....

Never quite got this... a contradiction of sorts. A WS clearly identifies an endpoint. The "message" in a WS is more incidental (like calling method parameters as messages). Unlike the message in a JMS system. Even in WS over JMS, the message is just the transport. No place for routing logic as such- as the WS endpoint by itself clearly defines the target. So if Im delivering a WS request to the designated & clearly identified endpoint, where is routing coming into picture? Now, hope this is not a transport level routing? Which is irrelevant to teh app. For app level routing, th erouting rules should be part of teh app flow/logic. Which is possible only in message based systems. WS is an endpoint based system (more like an RPC).

Now in pure message based systems, as in MOMs & Message driven ESBs, routing is an inherent part of the platform. Here the document flows thru the system, and can have rules & smarts setup to "route" the message to the right endpoints.

Think of this: Containers that host managed services will increasingly be required to control and monitor the messages that flow to and from these services.

Not quite sue why monitoring of all activities would not be essential in say just the J2EE context. (Must check out the Stats, Diagnostics, Sniffing & Logging available in Pramati Server).

Furthermore the containers will be required to work together in a global address space (or at least federated) so that services can truly be deployed anywhere and still find out how to exchange message with each other.

Again- is this really new concept? One could conceivably access even an EJB in the global address space. Save the firewall issues. Which again, I guess, is a similar challenge for both an SOA on JMS based transport or an EJB based distributed app environment over extended enterprise/internet.

Cheers,
Ramesh

It's true that WS defines the endpoint very explicitly in its WSDL. But that doesn't prevent anyone from building a routing system that virtualizes the endpoint and inserts routing logic between endpoints. This is what web proxies together with DNS do today for pure HTTP. It seems obvious to add that type of logic to the containers that host web based applications and web services today since they already control other aspects of the application, the transports and the message flow to/from it.

In fact one of the goals in QuickSilver is to treat JMS destinations the same way as WS endpoints. With respect to delivering a message, they are the same. Consider the need for "virtual" endpoints, for example for load balancing and failover. There are also other reasons for virtualizing endpoints. Generally, you want to decouple the deployment decisions from addressing information. It's just like I do with my personal email address. It's just a proxy for whatever email account I decide to use, Yahoo, MSN or whatever. The less those "endpoints" (has to) know about my routing logic the better.

I think it's an interesting comparison that you make between WS and MOM. Again, I am not the expert. But the way I look at it is that these types of systems are converging. It makes sense to apply the message level control that you have in MOM to WS infrastructures. This gives you loose coupling and asynchrony as part of your application model.

Jesper
BEA Product Marketing

Are they talking about jsr-208 (JBI & SPIs compliance) or just another propietary ESB? Adapting to standards will mean WLI apps would be portable to different container implementations?

I should make some feasibility work for an upcoming project that aimed to build a very custom WebLogic based J2EE application that incoroporate tight SAP integration.

I am now making some research around the net and my major concern is the indicated cost of the WL SAP Adapters (somewhere around USD 50k according to some sites).

The problem is that the project is pretty limited on the deployment side eg. the number of expected concurrent users (max 10), and from this point WebLogic Workgroup Edition seems ideal with the price tag of USD 4k. Sadly the total budget is cannot be more than USD 50k for the entire project.

So my question is: Does anyone have relevant experince about the licencing costs of WL SAP Adapters in damn small size projects?

I should make some feasibility work for an upcoming project that aimed to build a very custom WebLogic based J2EE application that incoroporate tight SAP integration.I am now making some research around the net and my major concern is the indicated cost of the WL SAP Adapters (somewhere around USD 50k according to some sites). The problem is that the project is pretty limited on the deployment side eg. the number of expected concurrent users (max 10), and from this point WebLogic Workgroup Edition seems ideal with the price tag of USD 4k. Sadly the total budget is cannot be more than USD 50k for the entire project.So my question is: Does anyone have relevant experince about the licencing costs of WL SAP Adapters in damn small size projects?

You should contact your BEA rep. They can always work with the prices, especially if you explain the situation. If you can find out when the quarter is ending, try contacting them a couple of weeks before the end of the quarter. I've seen other adapters and WLI components that "list" for 20, 30, or 50k sell for well below half the advertised price.

sell for well below half the advertised price

No-one pays list for this kind of stuff. Not even for Weblogic.

Lets hope that it will be easier to upgrade existing WLI 8.1 applications to Quicksilver than it was upgrading from WLI 7 to WLI 8 which was a real mess.

Is this ESB solution going to be based on the specs behind jsr 208 (jbi container, normalized messaging) or we are going to have to wait for the next standard for standarization of EAI using MOM? (Or how portable is the new WLI).