1 / 36

Model-Driven Integration Strategies

Model-Driven Integration Strategies. Joe Berkovitz Chief Architect, Allurent Inc. This talk is about…. Modelling : describing software abstractly Integration : hooking up disparate components Strategy : an overarching approach to a problem

ardelle
Download Presentation

Model-Driven Integration Strategies

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Model-Driven Integration Strategies Joe Berkovitz Chief Architect, Allurent Inc.

  2. This talk is about… • Modelling: describing software abstractly • Integration: hooking up disparate components • Strategy: an overarching approach to a problem • Model-Driven Integration Strategy:An approach that uses abstract descriptions to drive the hookup of disparate components

  3. Who… • …is using SOAP web services? • …is using HTTP/XML services? • …is using RemoteObject • …is using Flex Data Services? • …is using Flash Remoting? • …is using Cairngorm? • …is using custom transport/serialization?

  4. Who hates writing burdensome,repetitive, error-prone code?

  5. The Integration Problem • Many strongly-related components and assets • Value Objects • Services with VO params that return more VOs • Multiple language bindings for VOs, Services • VO Serializers and Deserializers • User Documentation • Metadata

  6. The Integration Problem • Many languages in play • ActionScript 2 • ActionScript 3 • MXML • Java • C# • XSD • WSDL

  7. The Integration Problem • Many transport technologies • SOAP Web Services • Axis • .NET • REST Web Services • XMLRPC • Flash Remoting • Flex Data Management Services • Random Custom Stuff

  8. My real (ugly) world Flex Client Documentation Value Objects Views Controller Process Support Catalog Service Order Service VO, Service Metadata XML Marshaller REST/XML SOAP/XML Catalog Server Commerce Server WSDL REST web services SOAP web services data access layer integration layer Java Model Commerce APIs Catalog DB

  9. Commonalities Flex Client Documentation Value Objects Views Controller Process Support Catalog Service Order Service VO, Service Metadata XML Marshaller Catalog Server Commerce Server WSDL REST web services SOAP web services data access layer integration layer Java Model Commerce APIs Catalog DB

  10. Commonalities (continued) • Many components encode the same information or overlap heavily • Variations: • role • syntax • structure • degree of detail

  11. Transformation Tools • In limited realms, transformation tools are popular • They reduce the number of parallel representations • Example: Axis WSDL2Java (.NET similar) WSDL WSDL2Java Java Model SOAP web services

  12. or….. Java2WSDL! WSDL Java2WSDL Java Model SOAP web services

  13. Existing transformation tools are limited • Axis, .NET stay within their platform boundaries • xdoclet, xdoclet2 rely on annotation of Java classes, interfaces: locks into standard OOP language model • XSLT doesn't work so well for very complex iterative transforms, and has limited programmability (for non-masochists)

  14. Where transformations help • Across technology domains: same concept, different languages/protocols • Within technology domain: interlocking concepts, same language

  15. What Hamachi does • Language-neutral XML model description… • …is parsed according to Metamodel into an in-memory model… • …Generators pass parts of that model… • …to Velocity templates to format them into output files Model Description Hamachi Output Files Output Files templates Output Files Generators Metamodel Generators Generators

  16. Hamachi modules • Different projects need different models, different templates • Hamachi modules package the part that varies: Model Description Hamachi Output Files Output Files templates Output Files Module Generators Metamodel Generators Generators

  17. Harnessing Generation with Hamachi Value Objects Documentation Catalog Service Order Service Process Support VO, Service Metadata Model Description Hamachi WSDL WSDL2Java Java Model SOAP web services

  18. Derived Assets for a Single Object OrderItemSummary.as OrderItemSummary.html OrderService: OrderItemSummaryaddToCart() new ClassDescriptor ("OrderItemSummary") Hamachi <ClientModelType name= "OrderItemSummary"> <complexType name="OrderItemSummary"/> <wsdl:operation name="addToCart"> WSDL2Java OrderItemSummary.java addToCart WS endpoint

  19. What is a metamodel? • Models describe parts of your application • OrderItemSummary is a ClientModelType in the model • OrderItemSummary.price is a Property in the model of type decimal • CatalogService is a ClientService in the model • Metamodels describe parts of your model: • ClientModelType is a Class in the metamodel • ClientModelType.properties is a Property of type PropertyList

  20. Adding an Attribute to the ARC Model

  21. Model-Driven SOAP Support

  22. Why not just use <mx:WebService>? • Operations and request/response not strongly typed • No access to returned SOAP fault information • High overhead from parsing WSDL • Performance penalty for generality of SOAP document type support

  23. Model-Driven MVCS SOAP support Controller Order line item view invoke API to obtain operation change events cause data binding update in view IOrderService: type-safe Service interface execute operation OrderService: Service Implementation populate value object from response create operation OrderItemSummary.as AddToCartOperation: Operation Implementation SOAP Marshaller/ Unmarshaller new ClassDescriptor ("OrderItemSummary") per-class metadata drives XML parsing/ generation SOAP/XML (follows document/literal conventions only)

  24. Model-Driven REST Support

  25. REST: accessing a data web • Each distinct entity is served from a stable URL • All relationships are represented as hyperlinks • A relationship may be: • lazy (only a hyperlink in referent) • eager (target object details included in referent) • anywhere in between • Very suitable for read-only data

  26. REST data web http://example.com/cat/1: <Category uri="/cat/1" name="Widgets"> <products> <Product uri="/product/11" title="Cool Widget"/> <Product uri="/product/12" title="Cooler Widget"/> </products> </Category> http://example.com/product/11: <Product uri="/product/11" title="Cool Widget" price="33.00"> <images> <Asset type="large" href="/images/11large.png"> <Asset type="small" href="/images/11small.png"> </images> </Product> http://example.com/product/12: <Product uri="/product/11" title="Cooler Widget" price="66.00"> <images> <Asset type="large" href="/images/12large.png"> </images> </Product>

  27. Model-Driven MVCS REST support Controller Product display view request entity by URI on behalf of view request for missing property triggers loading change events cause data binding update in view create/populate entity instances ContentService: REST entity cache Product.as Category.as load entities on demand populate objects from XML responses REST Unmarshaller new ClassDescriptor ("Product") per-class metadata drives XML parsing/ generation impl-dependent REST/XML document format

  28. OzoneLayer:model-driven client/client integration

  29. Conventional single-user outliner app Flex Client OutlineView actions data, events IOutlineController OutlineController IOutline modifications Outline

  30. Add OzoneLayer and stir: multiuser outliner Flex Client Flex Client OutlineView OutlineView actions actions data, events data, events IOutlineController IOutlineController OutlineControllerProxy OutlineControllerProxy IOutline IOutline modifications modifications OutlineController OutlineController OutlineProxy OutlineProxy Outline Outline SharedScope SharedScope Flash Media Server (or moral equivalent) Shared Object Services

  31. OzoneLayer: What Hamachi generates Flex Client Flex Client OutlineView OutlineView actions actions data, events data, events IOutlineController IOutlineController OutlineControllerProxy OutlineControllerProxy IOutline IOutline modifications modifications OutlineController OutlineController OutlineProxy OutlineProxy Outline Outline SharedScope SharedScope

  32. Pros + One change in model expresses many in system + Eliminates many tedious, error-prone changes + Enabling technology for custom networking approaches + Change to module can affect the "way it works" with no distrubance to the model

  33. Cons - Longer "curve to liftoff" - More complex system, harder to learn - Models, metamodels not fully standardized

  34. Some caveats • Approaches, not turnkey tools • Not all source code available yet • Limited documentation

More Related