1. Enterprise Integration
Adam Rybicki
I am no EI expert!

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

3. 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

4. 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

5. 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.

6. 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.

7. 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

8. 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.

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

10. 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.

11. 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

12. 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

13. 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:

14. 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.

15. 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:

16. 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?

17. 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

18. 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.

19. 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

20. 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!