Rachel Reinitz and Andre Tost have kicked off a new developerWorks series on WebSphere ESB with an article describing the relationship between the product and the Service Integration Bus. In my mind, it’s a shame the article doesn’t talk more about about the SIBus Web services support. The following phrase sums up the key difference: “WebSphere ESB is built with the strategic SCA/SDO programming model”.
Archive for the ‘WebSphere’ Category
WebSphere ESB vs SIBus
Thursday, October 26th, 2006Feature Pack for Web Services Beta
Thursday, October 19th, 2006WebSphere Application Server has introduced a new strategy for releasing additional functionality on top of existing versions, to be known as feature packs. There is now a beta of the WebSphere Application Server Version 6.1 Feature Pack for Web Services available. This feature pack will eventually deliver support for a raft of new Web service standards (WS-Reliable Messaging, WS-Addressing, MTOM and WS-Secure Conversations) along with updating the supported levels of existing standards (JAX-WS 2.0, JAXB 2.0, SAAJ 1.3 and StAX 1.0). The new Web services standards introduced form the basis of the RAMP Profile (Reliable Asynchronous Messaging Profile).
Advanced XSLT for WebSphere ESB
Thursday, October 19th, 2006There is an interesting developerWorks article which looks at some advanced aspects of using XSLT with WebSphere ESB, particularly focusing on mapping element arrays in business objects.
Message Broker nodes for Service Registry and Repository
Thursday, October 19th, 2006Yesterday saw the publication of a developerWorks article describing the SRRetrieveITService and SRRetrieveEntity WebSphere Message Broker nodes provided in IA9L SupportPac for integration with WebSphere Service Registry and Repository. The first of these nodes retrieves a service endpoint based on a specified port type. The example shows how this can be used with the HTTP input node to dynamically locate and invoke a service. The second node can be used to retrieve the metadata for an arbitrary entity stored in the Registry and Repository. This could be used, for example, to retrieve policy data relating to the service to be invoked.
developerWorks deluge
Wednesday, October 18th, 2006I’ve only just got round to reading last week’s developerWorks newsletter and it contains a positive plethora of interesting articles following the SOA launch.
Missing messages
Monday, October 16th, 2006Responding to Srinivas’ comment requesting more on debugging, I thought I’d post on one common question when using the service integration bus: where has my message gone? By this I mean the case when a message has been sent but not received by the consumer.
WebSphere MQ Servers
Thursday, October 12th, 2006The final major piece of functionality that I shall cover in this series of posts looking at deliverables made by Hursley in to WebSphere Application Version 6.1 is WebSphere MQ Servers. In Version 6.0 of the Application Server, WebSphere MQ could either be accessed directly from an application using the WebSphere MQ JMS provider or via the service integration bus by using a foreign bus and WebSphere MQ link. In Version 6.1, it is possible to add a WebSphere MQ queue manager, running on z/OS and at Version 6 (CSD 1 or greater), directly as a member of the bus.
WebSphere ESB 6.0.2
Wednesday, October 11th, 2006As Adrian notes, WebSphere Enterprise Service Bus Version 6.0.2 has now been announced for release around the end of the year. As I hinted in an earlier entry , this will include a new mediation primitive to provide integration with WebSphere Service Registry and Repository to enable the dynamic selection of endpoints at runtime. There should also be less need to use WebSphere Integration Developer to make pre-deployment modifications with the ability to alter endpoints and mediation primitive properties administratively.
One particularly welcome piece of functionality is the extension of the JMS bindings to support WebSphere MQ in addition to the default messaging provider. This, along with the WebSphere MQ bindings, means it is possible to connect directly to WebSphere MQ without first going through the service integration bus. This is important given the current complexity of configuring a highly available WebSphere MQ link on the bus. It also fits with a message that I have been trying to give to WebSphere Applications Server customers: only go through the service integration bus to reach WebSphere MQ if it adds value to your solution.
RSS - Posts