Saturday, January 28, 2006

Sonic Synergy TechDays Cologne

I'm just back from the presentation of Sonic's new product suite (Sonic Workbench 7.0) which took place in Cologne 26/27 January). Here's a summary of what's the new product features and some critical comments (in italics).


Whitepapers


SOA Maturity Model

  • 5-step layered pyramid, similar to CMMI
  • ESB covers levels 2-3
  • Levels 4-5 are addressed through acquisitions:
    • Apama ESP & Dashboard,
    • Actional Looking Glas & SOAPStation.

Architecture/Positioning

ESB vs WS*: How relevant is ESB in the context of maturing WS*-standards?

Sonic Aussagen und meine Kommentare (kursiv):

  • WS* is spaghetti
    • , because of direct WS-endpoint to endpoint communication.
  • WS* RM is not HA: Persistence necessary for WS-RM is only happening at the broker (that implements the WS-RM endpoint). A WS* system is required to provide persistence at every WS-endpoint. This means the system is much more brittle (and not easily HA-capable), because two service endpoints must be online simultaneously for an exchange.
    Hmm …. the WS-RM implementations could do store-and-forward, transparent to the communicating services. It might even be possible to have a transparent message broker in-between, provided by the WS-RM implementation.
  • Event Stream Processing: Since all service traffic (queues) are visible within the ESB mediation is facilitated and can be operated upon. Event Stream Processing. Example Application: fraud detection in credit card transaction processing.
  • Another USP would be the capability of ESB to mediate between different incompatible WS*-Standards
  • Simplified Keystore Management: Since all services/clients communicate via the ESB broker, keystores need only be managed once and not for every consumer/service pair! However, every Sonic service container still needs to have a keystore to communicate with the MQ broker over SSL!
  • Simplified Authentication/authorization: Since auth happens at the broker, it is easier to configure/adjust access rights. Disadvantage: agreement is necessary, which might be difficult in a corporate setting with many different stakeholders[tri1]
  • Dynamic Message Routing/CBR/Itineraries: Dispatching from a virtual endpoint to a target service based e.g. on message criteria, dynamic environment characteristics (load, etc), or according to changed business requirements. This allows “virtual service endpoints” that are dynamically dispatched to actual service instances.
    In WS* this would probably be done via an intermediary “Routing” service.
  • BUT: vendor lock-in because of proprietary wire protocol and non-portable service APIs

Sonic Deployment Model (SDM)

  • Version 1.1 works with Sonic 6.1.1; Version 1.5 for Sonic 7 (Feb 2006)
  • Planned features in later versions:
    • Export of service/process documentation
  • Model-driven Deployment
  • Not free to use!
  • Queue reference file: allows reuse of queue sets in different broker/cluster configurations.
  • Config.properties overrides settings in default.properties (located in SDM-Core directory)
  • cfgFile=Configuration.xml: wie gehabt, um service properties zu setzen. Aber keine default/specific Struktur, um gering abweichende Service Konfigurationen je Deployment-Umgebung zu realisieren. Das ganze File muss jeweils benutzt warden??
  • Access the Container’s Logs: Managed Objects\Containers\ctInc\????
  • Startup is automatical after deployment; manual startup later via “startcontainer /w ”
  • cleanInstallation ist notwendig, wenn noch keine Sonic Software installiert wurde.
  • updateInstallation am laufenden Container möglich – minimum downtime when deploying new services, settings, etc….

Sonic 7 Features

  • Beta end Feb, available April; Tonight first pre-beta Release
  • No JBI yet
  • Everything except from O-Server will be in pure Java (this includes configuration, etc.). This means support for MacOS.
  • Web Services Support:
    • Sonic 7 supports WS-Policy, WS-Security, WS-Reliable Messaging and WS-Addressing on both on-ramps and off-ramps.
    • Automatic way to expose ESB Services as WS-Endpoints
    • WS-endpoints exposed by SonicMQ, serve up WSDL
    • Is ESB an anachronism in a WS* world where endpoints natively support these standards?. See section “Architecture/Positioning”
  • SOA Suite includes O-Server/C-Server in addition to ESB
  • CAA is still not capable to fail over ESB containers. ESB containers must consist of stateless services and be replicated on both active and backup machines for ESB services to work in a CAA environment.

Sonic 7 Tooling

  • Focus on Tooling, followed later by an update of the backends; in the moment the servers have only minor differences compared to Sonic 6, but better configuration, manageability, faster configuration & service implementation.
  • Unified plugins for Eclipse to do Deployment, Design and Testing: One-button deployment, etc ….
    • JMS Test Client now integrated into Eclipse and capable to produce and consume multipart messages.
    • Graphical Debugging of processes
    • Debugging view of multipart messages
  • Common Look & Feel Graphical Process Editor for Itineraries AND Orchestration Processes
    • However, no migration support ESBP à OServer
    • Need a BIG screen!
    • Still no drag-and-drop reconfiguration of processes!
    • Still no support for multiple successive decision steps
  • Actional provides a unified view across multiple Orchestration Server instances.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)