IBM's Approach to SOA Governance
Upcoming SlideShare
Loading in...5
×
 

IBM's Approach to SOA Governance

on

  • 427 views

 

Statistics

Views

Total Views
427
Views on SlideShare
427
Embed Views
0

Actions

Likes
0
Downloads
5
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

IBM's Approach to SOA Governance IBM's Approach to SOA Governance Document Transcript

  • This Presentation Courtesy of the International SOA Symposium October 7-8, 2008 Amsterdam Arena www.soasymposium.com info@soasymposium.com Founding Sponsors Platinum Sponsors Gold Sponsors Silver Sponsors SOA Symposium October 7-8, 2008, Amsterdam Implementing Service Models with Java André Tost (andretost@us.ibm.com) Senior Technical Staff Member, SOA Technology IBM Software Services for WebSphere © 2008 IBM Corporation 1
  • SOA Symposium Agenda  Service Models – Utility Services – Entity Services – Task Services  Service Composition  Backup: Service Orientation Principles with Java Web Services – If time permits  Summary 3 Implementing Service Models in Java © 2008 IBM Corporation SOA Symposium Intro (and shameless plug)  The content of this presentation is extracted from content of the forthcoming book “SOA in Java”, which is part of the Prentice Hall Service-Oriented Computing Series from Thomas Erl  It doesn‟t cover the entire book, but only content that is related to Service Models  We assume that your implementation and deployment platform is Java – Well, if this surprises you, you obviously didn‟t read the title of this presentation!  We assume Java 5  We used Glassfish for creation of examples  However, I will not show a lot of actual Java code. I expect you know how to write Java. We will focus on architectural and design aspects, testing, packaging considerations and other best practices. 4 Implementing Service Models in Java © 2008 IBM Corporation 2
  • SOA Symposium Service Models 5 Implementing Service Models in Java © 2008 IBM Corporation SOA Symposium Service Models  To give structure to our service-oriented environment, we create layers of functionality – High level business processes are represented in the Process Layer – Traditional IT systems are in the Application Layer – The Service Interface Layer allows functionality from the Application Layer to be leveraged in the Process Layer  The Service Interface Layer can be further decomposed into three layers – Orchestration Service Layer – Business Service Layer – Application Service Layer  All of these layers can be sorted into a service layer „stack‟ – Shows dependencies and relationships between different parts of a solution – These parts can be developed top-down, bottom-up, or both 6 Implementing Service Models in Java © 2008 IBM Corporation 3
  • SOA Symposium Service Models 7 Implementing Service Models in Java © 2008 IBM Corporation SOA Symposium Service Models  We can associate different service models with these layers – Different types of services exist at different levels in the resulting „stack‟ – All are part of the service portfolio for an enterprise – Service models allow classifying and structuring service portfolio  Utility Services – In the Application Services layer – Offer technical functionality  Entity Services – In the Business Services layer – Offer access to data  Task Services – In the Business Services layer – Represent activities within a business process  We will not cover logic existing in the other layers in this session  We will focus on aspects of developing these service models in Java 8 Implementing Service Models in Java © 2008 IBM Corporation 4
  • SOA Symposium Service Models: Utility Services 9 Implementing Service Models in Java © 2008 IBM Corporation SOA Symposium Utility Services – Architectural Considerations  Utility Services are used by services in the Business Services layer – Not the other way around – They might be invoked from within an ESB, making them totally transparent to the Business Services  They are usually not identified in the process and domain decomposition phase of the SOA analysis and design process  Utility service identification is triggered by, for example: – Non-functional requirements (NFR) – „Wrapping‟ of existing non-SOA technology – Existing Java standards 10 Implementing Service Models in Java © 2008 IBM Corporation 5
  • SOA Symposium Utility Services – Architectural Considerations  Various ways exist for invoking Utility Services – Local versus remote – Call-by-value versus call-by-reference  Performance aspects – Mainly through serialization – Different serialization options exist – XML, binary  Concurrency aspects – Multiple clients accessing the service implementation – Must be thread safe – Java EE application servers handle this automatically 11 Implementing Service Models in Java © 2008 IBM Corporation SOA Symposium Utility Services - Types  Omni utility services – Very generic in nature – E.g. eventing, security, logging – Typically use JAX-WS Provider  Resource utility services – Encapsulate resources like messaging, data, network, etc – i.e. acts as façade – Use existing standard Java APIs – May want to add transfer objects to reduce “chattiness”  Micro utility services – Fine grained – E.g. encryption/decryption, mathematical calculations, transformation – Typically not accessed remotely – No Web services  Wrapper utility services – Also called “connector services” or “adapter services” – JCA is the prime standard leveraged by these services 12 Implementing Service Models in Java © 2008 IBM Corporation 6
  • SOA Symposium Utility Services – Design and Implementation  Utility Services are highly reusable across many business domains – Should have generic interfaces – XML: <xsd:any/> or <xsd:anyType/> – Remote Java: java.io.Serializable, e.g. String – Local Java: java.lang.Object – Make sure implementation supports multi-threading – Use synchronized where appropriate – Avoid using instance-level state  Use of Java editions – Java SE supports several relevant APIs for Utility Services – Security (JAAS), Management (JMX), Transformation (JAXP), Logging, Persistence (JDBC) – Java EE adds an additional rich set of APIs that are relevant – Messaging (JMS), Transformation (JAXB), Transactions (JTA), Registry (JNDI, JAXR), Legacy Integration (JCA) – Leveraging EJB ensures high degree of autonomy and scalability  Open Source Frameworks can help creating Utility Services – Spring – Hibernate – Commons Logging – … 13 Implementing Service Models in Java © 2008 IBM Corporation SOA Symposium Utility Services – Design and Implementation  Utility Services as Web Services – Don‟t use <xsd:string> as type for XML documents – Will be encoded, thus increasing the size of the message – Use <xsd:any/> instead – JAX-WS supports „provider style‟ service implementation – Implement javax.xml.ws.Provider – No parsing or serialization – XML message is directly passed to the implementation – Use SAAJ to parse message content @ServiceMode(value=Service.Mode.MESSAGE) @WebServiceProvider() public class GenericProviderImpl implements javax.xml.ws.Provider<javax.xml.soap.SOAPMessage> { public SOAPMessage invoke(SOAPMessage message) { // read and process SOAPMessage... } } 14 Implementing Service Models in Java © 2008 IBM Corporation 7
  • SOA Symposium Utility Services – Testing and Packaging  Testing – Use JUnit – High degree of reuse requires thorough testing – NFR may not always be known in advance – Make services as autonomous as possible  Packaging – Java logic can be packaged in JAR, WAR or EAR – Depends on the deployment environment – Java EE or Java SE etc 15 Implementing Service Models in Java © 2008 IBM Corporation SOA Symposium Service Models: Entity Services 16 Implementing Service Models in Java © 2008 IBM Corporation 8
  • SOA Symposium Entity Services – Architectural Considerations  Entity Services are used by higher-level Task Services and Process Services  Typically support an enterprise canonical model – Addressing inconsistencies in data used across many applications – One version of the “truth” – Provide uniform view of domain-specific views of data  Domain entities versus message entities – Domain entities represent enterprise data model – Message entities are driven by processes‟ needs for information – They are the information that flows between activities within the process – Offer a “shallow” view of the enterprise data  Require Data Aggregation – Encapsulated by the Implementation – Must consider ownership 17 Implementing Service Models in Java © 2008 IBM Corporation SOA Symposium Entity Services – Architectural Considerations  Access mode – Defines whether or not data is accessed exclusively – Defines whether data can be accessed by other users/applications while it is being changed – Service Data Objects offer “disconnected data access” in Java – Data is retrieved by consumer for work – No physical locks are held on the data source – Changes are made within a separate transaction – Conflicts can be resolved in different ways (raise exception, overwrite, etc) – This is also called “optimistic locking” – See http://www.osoa.org/display/Main/Service+Data+Objects+Specifications  Change notifications – Support notifying clients of updates made to data – Not usually supported 18 Implementing Service Models in Java © 2008 IBM Corporation 9
  • SOA Symposium Entity Services – Design and Implementation  Do not expose underlying physical data model – It may change  Exposed is a view of the data driven by business needs  Entity Services are stateless – Use underlying technology to store the data – No operations named load(), save(), etc  Avoid technical terms in interface and operation names – Should always be business relevant – Avoid exposing implementation details (e.g. “queryCustomerTable”)  Use existing persistence frameworks to map domain entities into Java – JPA, EJB3 – Hibernate  Put message entities and domain entities into separate packages 19 Implementing Service Models in Java © 2008 IBM Corporation SOA Symposium Entity Services – Design and Implementation  Message entities can be viewed as shallow wrappers around domain entities – Carry only the attributes that are relevant to the consumer – Don‟t include full object graph  For consumers with widely differing requirements for attributes, use generic types  For Java SE implementation, you can use JDBC – But you must handle transactions, scrolling, partial loading, etc  Better to use JPA – It is the underlying mechanism for EJB3 Entity beans – But it works in Java SE, too – Also supported (and heavily influenced by) Hibernate  For Java EE implementation, create stateless session bean as façade over Entity beans 20 Implementing Service Models in Java © 2008 IBM Corporation 10
  • SOA Symposium Entity Services – Design and Implementation  Entity Services are most likely always exposed as Web services – High degree of reuse across business domains – Single access point for information  Data model can start out as XML Schema or as Java – Tooling (wsgen, wsimport, ….) can generate one from the other – Full XML Schema set now supported by JAXB  Testing – Entity services can be used in different contexts, all of which have to be tested – Synchronous, “online” – Asynchronous, “batch” – High degree of concurrency – Test optimistic locking – Performance-critical – Especially when aggregating from multiple sources  Packaging – Domain entities and message entities go into different packages – Put domain entities into Utility JAR for reuse – In Java EE, one enterprise application per Entity service 21 Implementing Service Models in Java © 2008 IBM Corporation SOA Symposium Service Models: Task Services 22 Implementing Service Models in Java © 2008 IBM Corporation 11
  • SOA Symposium Task Services – Architectural Considerations  Task Services stem from decomposition of business processes into activities – Often domain-specific or even process-specific – Less reusable  “Top-down” design  They often use Entity Services – Entity Services are often “bottom-up”  Contain pure business logic – Technology agnostic  Act as controllers – Expose coarse grained interface – Invoke finer grained (Entity) service interfaces – Might be co-located with these services to improve performance 23 Implementing Service Models in Java © 2008 IBM Corporation SOA Symposium Task Services – Architectural Considerations  Task service versus Process service – Task service invokes a sequence of lower level services – In plain Java – A task service represents an activity within a business process – The business process is implemented as an orchestration, using a higher level of abstraction, like WS-BPEL – Task services are short running, process services are long running – Task services have no human interaction  Task services are stateless – But they may have to retain state across invocations of aggregated services – Can usually use local heap space 24 Implementing Service Models in Java © 2008 IBM Corporation 12
  • SOA Symposium Task Services – Design and Implementation  Task service identification through process decomposition often leads to one operation per service  Try to group similar operations and reduce number of distinct services – Services are governed, maintained and versioned as a unit  Use namespaces as a way to distinguish between services in different layers  Messages are specific to the context of the business process – May not always follow canonical model  Implementation has to catch exceptions and error conditions from lower level technology and translate them into business level faults – Pay as much attention to modeling faults as to modeling the rest of the messages  Implementation should not directly use low level Java APIs – Should use Entity and Utility services – For example, do not use JavaMail, use the “Email” service – Might lead to the need for additional services 25 Implementing Service Models in Java © 2008 IBM Corporation SOA Symposium Task Services – Design and Implementation  Implementation as stateless session EJB allows access from a variety of clients – Note that WS clients do not automatically carry context, like an EJB client does – Security, transactions – Might have to leverage advanced WS-* specifications  Task services have many dependencies on other services – Challenging for unit testing – Create stubs for all invoked services – Might want to replace service proxies with local objects 26 Implementing Service Models in Java © 2008 IBM Corporation 13
  • SOA Symposium Service Composition 27 Implementing Service Models in Java © 2008 IBM Corporation SOA Symposium Service Composition – Terminology  Service Composition (or Aggregation) means that a service invokes other, existing services to implement its logic  The ability of services to be composed into a new service is one of the core principles of SOA – Allows building solutions quickly – Allows adapting existing solutions to new market demands quickly  In our definition, Composition is different than Orchestration – Orchestration is one way of composing services among others – Orchestration is often done to implement a business process – Orchestration often uses BPEL – We will focus on Java-based composition here 28 Implementing Service Models in Java © 2008 IBM Corporation 14
  • SOA Symposium Service Composition - Terminology  Services play different roles in compositions  Composition Controller invokes other services – Controller acts as „parent‟ – May have to store state across invocations – Utilizes different message exchange patterns for invocations  Composition Member is invoked as part of a composition – Member acts as „child‟ – Completely decoupled from controller‟s consumer – Can be controller for its own composition – Called “sub-controllers” 29 Implementing Service Models in Java © 2008 IBM Corporation SOA Symposium Service Composition and Service Models  Task Services are typical Composition Controllers – Can be members, too  Task Services are typical Composition Sub-controllers  Entity Services are typical Composition Members – Can be controllers, too  Utility Services are Composition Members 30 Implementing Service Models in Java © 2008 IBM Corporation 15
  • SOA Symposium Service Composition – Design and Implementation  Members are not aware of their controllers – This would create an unwanted degree of coupling  Controllers are aware of their members, of course – Identifying suitable members is part of the design process for a service  Usage of a service as a composition member must be subject to appropriate governance processes – SLAs must be put in place  Used protocols imply certain Qualities of Service – HTTP is not reliable – JMS supports transactional message delivery  May require support for additional standards – WS-ReliableMessaging – WS-AtomicTransaction – These are supported by the underlying runtime and do not have any impact on the service logic 31 Implementing Service Models in Java © 2008 IBM Corporation SOA Symposium Service Composition – Design and Implementation  Endpoint lookup – Composition member endpoints should not be hardcoded into the controller – javax.xml.ws.Service interface offers various ways of resolving this at runtime – addPort() creates a new port with new address – create() creates a Service instance from existing WSDL (including endpoint address) – Use createDispatch() method to implement completely dynamic invocation – Addresses should be looked up in a registry – Controller should cache member endpoint addresses  Error handling – Controllers should not copy all Fault messages from members into its own contract – Again, unwanted coupling and exposure of implementation details – Catch all exceptions in downstream invocations and convert to exceptions that are appropriate to the functional context of the controller – Including “unmodeled” faults, i.e. RuntimeException or WebServiceException (JAX-WS) – i.e. avoid relying on unmodeled fault handling – Propagates implementation details to consumer that it cannot handle  Tracing – Add „correlators‟ to each message to allow identifying it across member invocations – Do not make this part of the service contract – Use JAX-WS handlers instead 32 Implementing Service Models in Java © 2008 IBM Corporation 16
  • SOA Symposium Service Composition - Packaging  If members are Web services, use wsimport to generate client packages for each composition member – Creates required utility classes and interfaces – Can easily be packaged into a utility JAR file  If members are Java EE services (i.e. remote EJB), use client EJB bindings – Can also be packaged as utility JAR file – Use annotations in implementation logic to reference remote EJB  Package utility JAR files with EAR for composition controller  Very fine grained composition members (Utility services) may directly be included with controller logic – Cannot be called efficiently over a network – Creates a coupling between controller and member, e.g. member implementation cannot be changed without impacting the controller 33 Implementing Service Models in Java © 2008 IBM Corporation SOA Symposium Summary 34 Implementing Service Models in Java © 2008 IBM Corporation 17
  • SOA Symposium Summary  Service Models allow structuring services into different categories, according to their characteristics – Utility Services are highly reusable, often technical in nature – Entity Services offer consistent access to data, are also reusable – Task Services represent activities within a business process, coarse grained, less reusable  Java and especially Java EE offer predefined APIs and mechanisms to implement these services – JAXB to describe XML-based data – JAX-WS has a statically defined and a generic programming model to provide and invoke Web services – Many lower level APIs for Utility Services, e.g. JavaMail – JDBC, JPA and EJB3 for Entity Services  Composition is a core capability of SOA – Includes orchestration, which is done in BPEL – Introduces new roles: composition controller and composition member – Different Service Models apply to different composition roles 35 Implementing Service Models in Java © 2008 IBM Corporation SOA Symposium Thai Traditional Chinese Russian Gracias Spanish Thank English You Merci French Obrigado Brazilian Portuguese Arabic Grazie Danke Italian German Simplified Chinese Japanese 36 36 Implementing Service Models in Java © 2008 IBM Corporation 18
  • SOA Symposium Backup: Service-Orientation Principles with Java Web Services 37 Implementing Service Models in Java © 2008 IBM Corporation SOA Symposium Service-Orientation Principles with Java Web Services  Service Reusability – Agnostic functional context – Highly generic service logic – Generic and extensible contract – Concurrent access to service logic  Standardized Service Contract Design – Top-down versus bottom-up design – Java2WSDL and WSDL2Java mapping – Use of industry standards  Service Loose Coupling – Separation of contract and implementation – Functional context with no dependency on outside – Minimal requirements for consumer  Service Abstraction – Abstracting technology details – Hiding service details – Document constraints 38 Implementing Service Models in Java © 2008 IBM Corporation 19
  • SOA Symposium Service-Orientation Principles with Java Web Services  Service Composability – Composition of members versus composition of controllers – Highly efficient runtime environment – Flexible service contract – Standards-based runtime  Service Autonomy – Well-defined functional boundary – Control over runtime environment – High concurrency  Service Statelessness  Service Discoverability – Design time discoverability – Runtime discoverability – Service registries 39 Implementing Service Models in Java © 2008 IBM Corporation 20