May 2004 - Posts
Cape Clear announces another product for advanced Web Services potentialities.
Cape Clear announces the Business Integration Suite for BEA WebLogic, an Enterprise Service Bus (ESB) built around Web Services standards
Cape Clear Software's Business Integration Suite is a tried-and-tested Enterprise Service Bus (ESB). An ESB is defined by Gartner Group as a lightweight, Web Services-centric platform that offers a straightforward means to implement a robust, distributed Service-Oriented Architecture (SOA) approach to integration and messaging.
The ESB tier complements the WebLogic Application Server tier of the enterprise architecture by enabling already-defined EJB applications to be automatically re-purposed as Web Services. These services can then be published to, and consumed by, a wide variety of clients-not just Java. Presenting EJBs as Web Services means that they can readily be composed into composite applications and workflows with other services that may not be EJBs. Construction, integration, and use of these services does not require any EJB or server programming expertise-it is as simple, intuitive, and graphical as building Web pages. Therefore, significant additional service value (and new Web Services) can be added without incurring the cost and complexity of programming and delivering these exclusively on an EJB platform.
Exposes EJB using Web Services interfaces is an powerful technological choice that adds potentialities to the WebLogic Web Services platform. However this is just a tiny technological aspect in the SOA world. When I think in SOA I focus in more in some key theoretical aspect that in technological aspects. Anyway I really think that ESB is a great work of Cape Clear.
WS-MessageDelivery has been submitted to W3C by Hitachi, IONA, Nokia, Oracle, SeeBeyond, Sonic Software, and Sun Microsystems.
WS-MessageDelivery specification defines a mechanism to reference Web services (WSRef), essential abstract message delivery properties (AMDP), a SOAP binding for those properties, and the relationship of those properties to WSDL definitions and message exchange patterns. These properties enable SOAP messages to be transport independent - extending messaging capability to use separate transport protocol sessions or even using different transport protocols within the context of a message exchange pattern (MEP). Message delivery details are surfaced to the application layer, extending SOAP processors to use a wider range of message patterns and transport protocols to accomplish a Web service interaction. The abstract message delivery properties include web service references, message identification and message references. This specification outlines in detail how to build message exchange patterns consistent with WSDL 1.1 or WSDL 2.0 using the definitions in the specification. The semantics and mapping for the Callback Pattern, a commonly used message exchange pattern as a composite pattern, is defined. The Web service References (WSRef), Abstract Message Delivery Properties and a SOAP binding are designed for interoperability and extensibility.
WSE 2.0 announced at TechEd today. You can explore an interesting article here.
My last article is about Reliable Messaging in Indigo and J2EE. The article is segmented in three main parts. The first part cover the main concepts of the WS-ReliableMessaging Standard. Next we cover the main aspects of how to develop reliable Web Services using Indigo, using the high-level layer (DialogPorts) and the low-level layer (DialogChannel). Finally we shows how to develop reliable Web Services in the J2EE environments using WASP and its Sequence API.
We hope the you enjoy this article. Please send me your comments to gsusmrv@fastmail.fm or put it here.
TMC posts an interesting guide bout the SOA concepts.
The Middleware Company is introducing SOA Blueprints, an effort done in conjunction with BEA Systems to create best practices for developing applications using service-oriented architectures. SOA Blueprints contains an open specification, third-party expert involvement, and upcoming implementations using multiple technologies.
A timeline of the WSA specifications has been posted here
A new step of Systinet in the SOA world.
Systinet announce the immediate availability of Systinet Gateway 1.0, Systinet UDDI Registry 5.0 and Systinet Server for Java 5.0 (formerly WASP Server for Java) and C++ 5.0. Systinet Gateway 1.0 "extends and bridges proprietary message-oriented middleware (MOM) products, like TIBCO Rendezous, IBM WebSphereMQ (formerly MQ Series), SonicMQ and any other JMS-based solutions". The new 5.0 release of Systinet Server for Java fully supports reliable messaging using the WS-ReliableMessaging standard.
In a recent post I make reference to an interesting Skonnard's article about routing SOAP messages. Following this line I spent a few hours in this morning making test about the routing features in Indigo. Routing messages between services in Indigo is very simple. You only need to program a router (a simple application) and add the routing policy. A router acts on a Indigo port. A router can act over a message content and using a SOAP role in the message (Indigo also have a powerful mechanism to filter messages). Exist a RuleManager which is responsible manages all the rules.
Well I don't pretend give a Indigo routing tutorial right now, but take a look and tell me if isn't amazingly simple.
A router looks like a typical Indigo host application:
class MainRouter
{
[STAThread]
static void Main(string[] args)
{
ServiceEnvironment environment = ServiceEnvironment.Load();
environment.Open();
Console.WriteLine("Press enter to stop the services...");
Console.ReadLine();
environment.Close();
}
} |
In the router's configuration file we configure a RuleManager:
<ruleManager>
<ruleStore>
<fileStore>
<fileName>Router.exe.routes</fileName>
</fileStore>
</ruleStore>
<allowRemoteUpdates>false</allowRemoteUpdates>
<enforceRemoteSecurity>true</enforceRemoteSecurity>
</ruleManager> |
And the .routes file look like this:
<routes>
<router id="http://gsus/Indigo/Tests/router">
<priorityRoute url="soap.tcp://localhost:46000/Broker/">
<routingPolicyTtl>10</routingPolicyTtl>
<priorityDestination>
<sendTo>soap.tcp://localhost:46001/TestService</sendTo>
</priorityDestination>
</priorityRoute>
</router>
</routes> |
Of course the routing rule can be much more complex.
And then you can begin to send messages to the router represented by the Broker port and these messages will be routing to the TestService service.
FITECH Labs has released xTier.
xTier™ Service Oriented Middleware (SOM) provides a loosely-coupled set of pre-built services, for both Java/J2EE and .NET. These services extend the utility of J2EE and .NET by providing reusable infrastructure-level "building blocks" which are not part of the J2EE and .NET specifications and are often created and recreated for many development projects.
A recently published profile of Cape Clear Software by Gartner Group has declared that Cape Clear can become a leader in the emerging market for Enterprise Service Bus (ESB) integration. CapeClear provides a suite of integration products based of ESB concepts.
More Posts
Next page »