WebSphere Application Server Notes for presentation 02_WID.ppt

Transcription

1 WebSphere Application Server Notes for presentation 02_WID.ppt Note for slide 3 MODEL: Business service policy definition Enables business functions and processes to be expressed as discrete business policies Allows domain-specific SOA meta-models for the industry to be associated to policies to refine business policy definitions Allows for flexibility in the definition of business services to subscribers based on global policies or entity attributes such as role, department, group and organization ASSEMBLE: Composite business service assembly Enables associating reusable semantic and subscriber policies to create multiple, dynamic executions of the same business service Provides tooling that enables taking a Business Function Definition and describing it as a business service independent of underlying IT assets Allows for layering of composite business services at both an atomic or composite level Composite Business Application many Composite Business Services many Business Services many atomic and composite IT services Persists business service definitions and allows for the hierarchical variations of a business service to be assembled dynamically at run-time DEPLOY: Industry-specific semantic mediation & intelligent routing Based on industry domain and semantic models, preloaded industry standards are configured for a client s interpretation of the standard plus addition of their own custom/local standards Enables service routing that addresses the context and meaning of the business service and not just the content of the message/information payload Architects and developers create metadata driven (as opposed to hard coded) mediations using common services and policies that are driven by domain specific semantics Enables dynamic service matching and policy-based service behavior adaptation in run-time by associating of all the constituent aspects of a business service: People (consumers, groups and entities) Process (variations on the component IT services implementations for a business definition/flow) Page 1 of 9

2 Information (speaks the domain and the data language of the standards installed) Technology (end-point awareness will be better achieved when integrated with WSRR) Business Services Catalog extends the business-level Concepts within WebSphere Service Registry and Repository MANAGE: Business service metering & utilization Logs the key Business performance indicators within each business service at run-time (irrespective of whether process or transaction based measurements) Enables metering through persistence of KPIs from multiple perspectives for the same business service (i.e. claim can be metered based on line of business, type of claim and channel) As new Business KPIs are defined, metering can easily commence from the point of definition and deployment (i.e. once deployed the new KPI starts tracking) GOVERN: Business service lifecycle management Allows for flexibility in management of business services around the business service lifecycle: Planning simulation capabilities Publish maintains available for use policies Discover able to discover services (expected to merge into WSRR functionality) Versioning - allows for businesses to react to changes (i.e., market pressures new products, new routes to market, regulations, etc.) with versions of business functions This allows for organic growth of business services within a client environment instead of requiring a big bang roll out of services Includes user-friendly visual tooling for viewing relationships and associations of constituent IT services or lower-level services Note for slide 5 WBI Server V6 is built on robust J2EE Runtime provided by WebSphere Application Server. This runtime also offers Qualities of Service that WBIS exploits clustering, failover, scalability, security, J2EE also includes a built-in messaging provider, pure Java based JMS implementation which can be configured to connect to an existing MQSeries network to MQ it looks just like another queue manager thus enabling interoperability with every MQ-based application. Also in the infrastructure is the Common Event Infrastructure which is the foundation for monitoring applications. IBM uses this infrastructure throughout its product portfolio and Monitoring Products from Tivoli as well as WebSphere (WBI Monitor) exploit it. The event definition (CBE Common Business Event) is being standardized through the OASIS standards body so that other companies as well as customers can use the same infrastructure to monitor their environment. Page 2 of 9

3 On top of this infrastructure we implement a layer called the SOA Core. IBM will use this layer in WBIServer v6 and other future software offerings. To do integration in an SOA properly it is necessary to have a single invocation model and a single data model. Service Component Architecture is this invocation model every integration component is described through an interface. These services can then be assembled in a Component Assembly editor thus enabling a very flexible and encapsulated solution. Business Objects are the universal data description. They are being used as data going in and out of services and are based on the Service Data Object (SDO) standard. On top of this SOA Core WBI Server implements a number of components/services that can be used in an integration solution. Finally transformation happens quite frequently in any given integration project. WBI Server supports 4 kinds of mediations: Maps: These transform one kind of business object into another Relationships: Key management for same objects in different data stores (e.g. a customer record has a different identifier in SAP then in Siebel) Interface Mediation: to translate between semantically identical but syntactically different services e.g. updatecustomer (Customer) to updatecustomerinsap (SAPCustomer). Selector: This allows the invocation of a different component (with the same interface) based on business rules. Of course it still includes the business process engine that WBISF included. It has been updated to support the full WS-BPEL 1.1 specification as well as most of the WS-BPEL 2.0 draft items. Human Tasks have been greatly improved over WMQWF and WBISF. We now have a separate component the Human Task Manager that deals with Human Tasks. Note that previously we had to extend the WS- BPEL specification to do human tasks now as far as a business process is concerned, a human task is just another component. BTW: the SCA architecture allows replacing a human task (for approval for example) with a business rule for example without changing anything else in the entire solution. This is an extremely powerful and valuable benefit. Additionally we now support Originating Tasks (e.g. have a list of possible tasks on someone s desktop when they start a new task and fill in a new form a service gets invoked this could be a business process). And finally we have purely human tasks which allows for AdHoc Staff flows a functionality we never had before that had been highly requested. Business State Machines are another way of modeling a business process. There are some processes that are highly event driven e.g. an order could be cancelled at any point during the order process. It has been very difficult to model these kinds of processes in a traditional, sequential business process. Therefore we have another service where UML state machine diagrams can be used to describe such event driven business processes. Note that under the covers these are still being implemented as WS-BPEL flows. We are including Business Rules capabilities in WBIS v6. This includes Rule Sets (If/Then rules) as well as Decision tables. We also include a web client where the parameters of these rules can be changed by a business user we allow a natural language specification of these rules (e.g. If the car is size <xxx> then the prices is <yyy>). So the business person doesn t have to understand the language that the rules are Page 3 of 9

4 implemented in. For more complex rules requirements we still have partnerships with major rule vendors like ilog So you see that WBI Server V6 includes all the functions and services necessary in any given integration solution. Notes for slide 7 MyValueImpl.info example <sca:info name="service/myvalue/myvalueimpl xmlns:xsi=" xmlns:java=" xmlns:wsdl=" xmlns:sca=" xmlns:quote=" > <ports> </port> <port name="myvalue" > <interface xsi:type="java:javainterface" interface="service.myvalue.myvalue" /> </ports> <references> <reference name="customerinfo"> <interface xsi:type="java:javainterface interface="service.customerinfo.customerinfo " /> </reference> <reference name="stockquote" > <interface xsi:type="wsdl:wsdlporttype porttype="quote:stockquote" /> </reference> </references> <implementation xsi:type= "java:javaimplementation javaclass="service.myvalue.myvalueimpl"/> </sca:info> Note for slide 8 Sample MyValueModule SCA composite file example <sca:composite... > <component name="myvalueinst1" implementation="service/myvalue/myvalueimpl.java"> </component> Page 4 of 9

5 </sca:composite> Note for slide 9 Sample MyValueModule SCA composite file example with import/export <sca:composite... > <export name="myvalue target="myvalueinst1 binding="service/myvalue/myvaluebinding.wsdl" /> <component name="myvalueinst1 implementation="service/myvalue/myvalueimpl.java"> </component> <import name="customerinfo" > <interface xsi:type="java:javainterface interface="service.customerinfo.customerinfo" /> </import> <module>com.enterprisex.customerinfomodule</module> <export>customerinfo</export> <import name="stockquote binding="service/stockquote/stockquotebinding.wsdl" > </import> <interface xsi:type="wsdl:wsdlporttype" porttype="quote:stockquote"/> <address> </sca:composite> Note for slide 10 Sample below illustrate static and dynamic service invocation, respectively. For simplicity these samples use the same Customer type for input and output. On input, this sample service only requires the customerid to be set on the Customer SDO. On output, the returned Customer SDO contains the complete customer information corresponding to the customerid that was provided on input. #################### ServiceManager servicemanager = ServiceManager.INSTANCE; DataFactory datafactory = DataFactory.INSTANCE; Customer customer = (Customer)dataFactory.create(service.customerinfo.Customer.class); customer.setcustomerid("12345"); Page 5 of 9

6 CustomerInfo customerinfo = (CustomerInfo)serviceManager.locateService("customerInfo"); customer = customerinfo.getcustomerinfo(customer); = customer.getfirstname(); = customer.getlastname(); ############ ServiceManager servicemanager = ServiceManager.INSTANCE; DataFactory datafactory = DataFactory.INSTANCE; DataObject customer = datafactory.create(" "Customer"); customer.setstring("customerid", "12345"); SCAService customerinfo = (SCAService)serviceManager.locateService("customerInfo"); customer = customerinfo.invoke("getcustomerinfo", customer); = customer.getstring("firstname"); = customer.getstring("lastname"); Note for slide 11 A component consists of an implementation, which is hidden when using WebSphere Integration Developer's tools, one or more interfaces, which defines its inputs, outputs and faults, and zero or more references. A reference identifies the interface of another service or component that this component requires or consumes. An interface may be defined in one of two languages: a WSDL port type or Java. An interface supports synchronous and asynchronous interaction styles. A component's implementation can be in various languages. The recommended interface type is WSDL and our tutorials and samples consistently use the WSDL interface type. A Java interface, however, is supported and used mostly in the case when a stateless session EJB is imported (discussed later in imports and exports). Should you develop a top-down Java component, that is, define a component and add the Java implementation later, you should still use a WSDL interface. You cannot mix WSDL-interface-based components with Java-interface-based components. When working with this component, as shown below, you effectively only see the component itself. A reference to this component from another component would be revealed visually by a line to its interface. A reference from this component would be revealed by a line from its reference point to the interface of other component. A reference represents a service that this component consumes. By naming a reference and only specifying its interface, it allows the component implementation author to defer binding that reference to an actual service Page 6 of 9

7 until later. At that later time, the integration specialist will do so by wiring from the reference to the interface of another component or import. This loose coupling, which allows for deferred binding and the re-use of implementations, is one of the key reasons for using WebSphere Integration Developer's Service Component Architecture. A component may also have properties and qualifiers. A qualifier is a quality of service (QoS) directive on interfaces and references for the run time. Note for slide 12 SDO type definition as XML documents <?xml version="1.0" encoding="utf-8"?> <schema xmlns=" targetnamespace=" > <element name="customer" type="customer"></element> <complextype name="customer"> <sequence> <element name="customerid" type="string"></element> <element name="firstname" type="string"></element> <element name="lastname" type="string"></element> <element name="stocksymbol" type="string"></element> <element name="stockquantity" type="int"></element> </sequence> </complextype> </schema> SDO type definition as Java public interface Customer { public String getcustomerid(); public void setcustomerid(string customerid); public String getfirstname(); public void setfirstname(string firstname); public String getlastname(); public void setlastname(string lastname); public String getstocksymbol(); Page 7 of 9

8 public void setstocksymbol(string stocksymbol); public int getstockquantity(); public void setstockquantity(int stockquantity); } Note for slide 13 DMS = Data Meditator Service DAS = Data Access Service The client is responsible only to understand the APIs of the service and the DataObjects returned. The client is independent of the technology used in the DAS. When a client uses a DAS, the DAS implementation may use JDBC to access the data source and return data objects. The DAS may alternatively use a web service to invoke another service that performs JDBC database access service. Note for slide 14 An SDO DataGraph must be populated from a data source or a service. The SDO component that populates a DataGraph is called a data mediator service (DMS) or a data access service (DAS). A DMS also propagates changes to the in-memory DataGraph back to the originating data source. Because the DataGraph is disconnected from the data source, it is possible that another application will update the data (in the data source) that was used to populate a DataGraph before the application requests the DMS to propagate the application s changes back to the data source. To handle such potential update conflicts, a DMS typically implements some form of optimistic concurrency control and throws an exception to the application when a data collision occurs. At that point, it is the application s responsibility to recover from the collision, for example by re-reading the data and restarting the transaction. Note for slide 15 WebSphere Integration Developer enables the simple creation of business objects using the business object editor. Business objects are one of the primary building blocks of any business integration solution. They are containers for application data that represent business functions or elements, such as a customer or an invoice. A business object contains attributes, each of which has a name, a type (scalar type or another business object), a default value (for scalar types) and cardinality. Business objects can extend (define a superset of attributes) other business objects through parent/child relationships, however, a business object can only inherit from a single parent. These objects can also be used in conjunction with each other to perform a desired task. You can create and edit business object using the business object editor. Essentially, business object attributes are the mechanism through which you define what information a business object can hold, and how that information should be accessible. Business object attributes are used to define the content of a business object. Each attribute has a name, type, cardinality, and other optional properties. Once a business object has been created, its attributes can be created or changed in the business object editor. A business object is simply a container for the data specified in its attributes. An empty business object without attributes is essentially useless as it does not have the means to actually hold any data without attributes. Page 8 of 9

9 Note for slide 16 Components are business services that operate on business data. The WebSphere Integration Developer tools generate implementations that the assembly editor can use for components. For example, the implementations include business processes, state machines, human tasks, and so forth. The structure of the component is simple; it has the following parts: An implementation Optionally, one or more interfaces Optionally, one or more partner references Components are reusable; that is, you can invoke their services from other components or from clients through stand-alone references. You can also export their services, allowing them to be called from other applications. The components generated by WebSphere Integration Developer tools and used by the assembly editor are Service Components Architecture (SCA) components. SCA defines a technology-independent format for describing component implementations, so that assembling components to build an application do not require knowledge of the language and technology of the implementation of the component Components are assembled in the module, which is a basic unit of deployment in the WebSphere Process Server. The module assembly contains a diagram (referred to as the assembly diagram) of the integrated business application, consisting of components and the wires that connect them. You use the assembly editor to visually compose the integrated application by using elements that you drag from the palette or from the tree in the Business Integration view. An export is a published interface from a component or import to offer its business service to the outside world, for example, as a Web service. Exports have interfaces that are the same as or a subset of the interfaces of the component or import that they are associated with so that the published service can be called. An export dragged from another module into an assembly diagram will automatically create an import. To share the interfaces between modules, put the interfaces into a library. Then, for both modules, add a dependency on the library to use its resources. See related tasks for more information on dependencies. Applications that are not defined as SCA components (for example, JavaServer Pages) can still invoke SCA components; they do so through the use of stand-alone references. Stand-alone references contain partner references that identify the components to call. On their own, stand-alone references do not have any implementation or interface Page 9 of 9