Enterprise Integration Adam Rybicki arybicki@unicon.net I am no EI expert!

Agenda Introduction History Current Trends Java Standards and Tools What Are Sakai Developers Doing? What Should We Do?

History Proprietary EAI solutions popular in mid- 90’s Their value proposition: provide pre-built connectors to most common enterprise systems Custom connectors expensive to build Locked to specific programming language (often C or C++) Security, if any, seemed like an after- thought

Enterprise Integration Enterprise integration is not synonymous with Web application integration Service-Oriented Architectures (SOA) Usually Web Services Easily Accessible Interface Definitions Discoverable Standards should make enterprise integration easier There are too many standards to choose from

Enterprise Integration Challenges Communication Connectivity Transformation Service-Oriented Architecture Portability Security Communication: Services need to communicate reliably with each other over the network. A reliable, scalable, robust, and location-independent communications system dramatically reduces the development time for distributed systems while increasing reliability. Connectivity: To extract data from a service, one first needs to be able to easily connect to that service. Absent any standards, this has been difficult. Transformation: Data produced by a given service is typically not easily understood by another service; to make the data digestible by another service, it first needs to be suitably transformed. Service-Oriented Architecture (SOA): Distributed enterprise systems span multiple nodes and operating systems, and typically consist of a set of independently running services loosely bound to each other via event-driven messages. This SOA for application composition allows incremental, dynamic extensibility and greatly reduces costs of maintenance and Total Cost of Ownership (TCO). Portability: Most enterprises have a variety of computer systems, ranging from thin-clients and Windows desktop PCs to higher-end Unix servers and mainframe systems. Portability and ease of communication between different operating environments remain concerns for enterprise solutions. Security: Finally, all connectivity to and communication between enterprise services need to be secure at levels satisfactory to the enterprise. Since distributed applications span different departments and locations within and outside the firewall, security is highly important.

Standards Messaging: JMS Web Services: XML, SOAP, WSDL, UDDI Transformation: XSLT, Xquery Service-Oriented Architecture (SOA): based of the above standards; loosely-coupled Portability: Java, HTTP, XML, SOAP on Windows, Unix, mainframes Security: SSL, certificates, signatures, SAML plus all of the WS-* security standards These are today’s standards as applicable to solve the challenges listed on the previous slide.

Service Oriented Architecture Portals Desktop Applications Web Applications Composite Applications Client Applications WSDL XML JBI ESB BPEL Services Core applications are existing enterprise applications. They could be ERPs. Services should be easily accessible. Most commonly they will be Web Services, but they could also be other technologies based on standards that let you define their interfaces easily. Web Services EJBs Messages The layer above the services could be an enterprise service bus. Client applications could be Desktop applications, but more commonly could be Web or Portal applications. What’s not shown is that the core enterprise applications may also use the SOA to integrate with their peers. JDBC CORBA EJB Web Services Messages Core Enterprise Applications

Enterprise Service Bus Not necessarily a message bus Evolved from MOM, Integration Brokers, Application Servers, XML, JMS, E- Commerce, and Web Services ESB provides the backbone for building an enterprise SOA-based integration environment ESB is not just an abstract pattern. It is a product category with a distinct definition and many vendor offerings.

New Java-Specific Standards EJB 3.0 JBI (JSR 208) BPELJ JDBC 4.0

EJB 3.0 Simplifies the EJB programming model Eliminates the requirements for Home, Remote interfaces and deployment descriptor Allow transaction demarkation with annotations Remove the requirement to implement boilerplate methods (ejbCreate(), ejbActicate(), ejbRemove(), ...) Continue support for 2.1 and older 3.0 is all about the ease of development. Clearly EJB spec needs to do this to survive.

JBI (JSR 208) Java Business Integration Standardizes the Enterprise Application Integration APIs Prevents vendor lock-in with EAI and B2B applications Helps with building SOAs (what doesn’t?) Too new to know its potential for success

JDBC 4.0 4.0 is labeled as an “Ease of Development” release Can use Generics and Annotations SQL 2003-compliant XML data type Connection.isValid() Connection and Statement pooling now a part of the standard Specific SQL exceptions: transient and non-transient (transient might succeed if retried) Non-transient: SQLSyntaxErrorException, SQLInvalidAuthorizationSpecException, SQLIntegrityConstraintViolationException, SQLDataException, SQLNonTransientConnectionException Transient:SQLTimeoutException, SQLTransactionRollbackException, SQLTransientConnectionException

Java Tools Java 5 needed for all standards that require annotations EJBs are much simpler to write: import javax.ejb.*; /** * A stateless session bean requesting that a remote business * interface be generated for it. */ @Stateless @Remote public class HelloWorldBean { public String sayHello() { return "Hello World!!!"; } For more information, read this article: http://www.javaworld.com/javaworld/jw-08-2004/jw-0809-ejb_p.html

Java Tools JBI SDK 1.0 SunSequencingEngine SunSequencngEngine works by accepting an input message and sequentially invoking a series of services. The list of services is described in an XML syntax created by an external tool and deployed to the engine. When the engine receives a service request, it locates the service list corresponding to the service and executes each service in the service list. SunTransformationEngine SunTransformationEngine allows transformation of an XML document input in one format to another format. The transformation is based on a specified style sheet. SunSOAPBinding SunSOAPBinding allows external web services to invoke services in the JBI environment and vice versa. An external web service is likely to use a different message format and/or network protocol from an internal one. These service interactions are made possible via SOAP bindings and WSDL files. SunFileBinding SunFileBinding allows services to communicate with the local file system in which JBI SDK 1.0 is installed. SunSequencngEngine could be seen as an SOA orchestration engine. Sounds awfully similar to BPEL. Maybe it should use BPEL standard? SunTransformationEngine obviously uses XSLT to do data transformation. SunSOAPBinding solves the apparent Java-specific limitation of JBI.

Java Tools Java Web Services Developer Pack 1.6 Develop and deploy using the latest XML and Web services technologies slated for inclusion into Sun's deployment platforms. Enhance Web services performance without revising WSDL files or application code. Create XML and Web service-enabled applications that exploit the enhanced security features. Continue to enjoy Java interoperability and portability across different platforms and devices. Simplify and lower the cost of legacy application integration, data interchange, and publishing in a Web environment. Source: http://java.sun.com/webservices/jwsdp/index.jsp

Java Tools Apache Axis provides a rudimentary WS toolkit The University of Colorado has designed and implementing an SOA Based on WSDL standard Using Glue from webMethods (now replaced with the next generation product called Fabric) Glue simplifies WS programming greatly: no SOAP, WSDL, or XML POJO to WSDL and WSDL to POJO conversions Includes a SOAP server Demo?

Java Tools University of Illinois developed OpenEAI. Focuses on documenting interfaces and information exchange among enterprise applications. Key differentiator: individual enterprise applications only integrate with the ESB, not with each other. Currently JMS-based, but adding WS interface for a future release. There is a commercial company offering support (not Unicon).  Messaging protocol and message format in XML. Examples: Person Query Create Generate Delete Update Course

Conclusions and Recommendations The first priority should be to access enterprise data from the authoritative data source rather than from a replica. This does not mean directly reading from that data source, but rather through an ESB. Integration platform should be independent of the ERP platform vendor. Only platform-independent, standards-based, and vendor- agnostic solutions should be considered. While an EJB-based SOA is still an SOA, it is too difficult to access from .NET or other non-Java applications. Web services based on SOAP and WSDL are proven while JBI, for example, is not. Message-based ESB may be OK, but there should be a WS interface to it, too.

What Is Sakai Doing? Sakai Enterprise Discussion Group dedicated to Enterprise Integration Developing a list of use cases Current Sakai integration priorities: Provision of Sakai Information by Populating a Database Provision of Sakai Information from Live External Information Systems Integration with a Portal Stable, Documented Framework Architecture Data recovery options

What Should We Do? Pick an integration technology to use. (WS, JBI, EJB3, OpenEAI) Define integration data points. Examples: Persons Groups Define a standard method for portlets to integrate their data. Examples: Calendar events Announcements Notifications Define the objects in XML All the integration points should be bi-directional Authentication!