The Web Service Framework: J2EE

Transcription

1 The Web Service Framework: J2EE Manuel Berger, Nina Forst, Martin Reingruber 1 Matr.no.: , skyllas@gmx.at 2 Matr.no.: , nina.forst@gmx.at 3 Matr.no.: , mreingruber@gmx.at Abstract. As business workflows on the internet are getting more and more important there is a hype in developing web services. To keep up simplicity of realising web services on the internet there exists numerous standards and technologies, like UDDI, SOAP or WSDL, which also support software engineers in the development process. For a professional web service development, there are general frameworks which include the above mentioned standards and technologies as well as they give approaches for an efficient implementation. The frameworks can be applied regardless to its platform. This paper concentrates on the development of Web Services in J2EE (Java 2 Enterprise Edition) according to the mentioned general Frameworks. J2EE provides a lot of tools and APIs (Application Programming Interfaces) for the implementation of new Web Services as well as upgrading of existing applications. Our goal is to outline the conformity and differences between J2EE and the general frameworks. Introduction Novel communication services, which rest upon internet standards and web technologies, are known as web services. They are distributed and re-usable software components with the possibilitiy to provide and execute software functionality on the internet. Web Services are accessible via interfaces, apply to standard internet technologies and are independent concerning platform and programming language. Web Services profit by the following technologies SOAP, WSDL and UDDI, which are defined by the World Wide Web Consortium (W3C) and based on XML. Thanks to its concepts Web Services represent a modern technology to describe, publish, determine, invoke and execute digital services.[1], [2] A Web Service consists of the implementation and the description of the offered services. The Web Service Description Language (WSDL) is used as description language. The descriptions of the services are published either by the provider itselfs or through a registry. Thanks to the publishing the Web Service is can be accessed and investigated by the public. The standard for such registries is given by Universal Description, Discovery and Integration (UDDI). The Web Service access as soon as the data exchange happens via the Simple Object Access Protocol (SOAP).[3]

2 2 Manuel Berger, Nina Forst, Martin Reingruber There is a huge discussion about implementing Web Services, because developers divide themselves into two groups. On the one hand there are developers, which are convinced of microsoft and use.net for realising the Web Services. On the other hand the developers agree with Sun s and IBM s shared visions for Web Services and bank on J2EE. But there are also other famous platforms and technologies to realise Web Services like these from BEA and SAP. In this paper there is only a focus on J2EE, while the other technologies will be discussed in the papers The.Web Service Framework:.NET and The Web Service Framework: Open Source and other Frameworks. Overview J2EE The Java 2 Platform, Enterprise Edition (J2EE) profits by many features of the J2SE (Java 2 Platform, Standard Edition) and it represents an extensive and standardized framework for developing and deploying server-sided enterprise applications and Web Services. J2EE provides a component model 1, API s and numerous container services 2 personating a specification. J2EE itself does not represent a technology; furthermore it is a collection of different standards and specifications. Thanks to numerous tests to achieve a Java compatible Enterprise Edition certification, there will be a guarantee, that commercial J2EE implementations of trading partners (i.e. IBM, BEA, Oracle ) are compatible to the J2EE reference. [8], [9], [13] In other words, the J2EE platform ( in the world of software, a platform is a combination of hardware and software necessary to run applications. In this article, the word platform also implies that third-party developers can provide applications for that platform [14]) supports and provides distributed multi-tier applications, whose central elements are represented by component modellsmodels. The advantage of J2EE for the developer exists in the usage of component models like EJB (Enterprise Java Beans), Servlets or JSP (Java Server Pages), which reduces the development effort dramatically.[13] For this paper the technology of Web Services is very important, which is supported by Java API s of Version 1.4. Therefore Java API s were deployed to support communication via SOAP and to guarantee access to Web Service registries. 1 A component model allows creating re-usable software modules so called components. It should ease the recurrent implementation and form a framework for distributed systems 2 Containers represent an interface between a component and its functionality, which is platform specific and supports the component. They act as services for unchanging requirements.

3 The Web Service Framework: J2EE 3 Figure 1: J2EE Overview[5] Multi-tier architecture As shown in Figure 2 J2EE supports a multi-tier architecture. The specification defines the following tiers: client tier, middle tier (business and web tier) and EIS tier: Figure 2: J2EE Tiers[5]

4 4 Manuel Berger, Nina Forst, Martin Reingruber The client tier is sometimes called Front-end and it provides the (graphical) user interface (GUI or UI). It supports different kinds of clients like web browser, applets which task is to present output and accept input. The middle tier is composed of one or more middle-tier modules, which provides the programming environment. It implements business logic through Enterprise Java Beans (EJB) in the business tier and supports client services through Java Server Pages (JSP) in the web tier. The web tier and business tier together form the J2EE Server3 Machine. The EIS (enterprise information system) tier manages critical data and supports access to existing systems like RDBMS, ERP or legacy systems via API s.[4], [9] As shown in the following figure, the client tier is responsible for the presentation layer. Thanks to the containers, the middle tier supports both presentation layer through web containers and business logic through EJB containers. Finally the EIS tier represents the data layer.[13] Figure 3: Presentation, Business Logic, Data[5] Components and containers The server-sided component model conduces between the environment (container) and the server-object (component) itself. A container goes into action at the middle tier and includes services that always exist on every J2EE platform. Containers offer services to components and manage them. The components achieve access to various technologies and APIs of J2EE thanks to Container Service APIs. The interface between components and container is realised by this means, that components can use the extern APIs as if the container itself would implement them. 3 The J2EE server represents the runtime environment of a J2EE product and it provides web containers and EJB containers.

5 The Web Service Framework: J2EE 5 A component is the tiniest software-unit, which offers services to its environment. It can be connected with other components and configured via GUI-elements. Since one component for its own is not executable, some components together will be integrated in a container. In fact the underlying functionality of a system is realised by the components. The component implements only the underlying business logic. Anything else, like the communication between component and client resp. server will be provided by the container. This simplifies the development of components dramatically, since the focus is on the implementation of business logic.[9] Applet Container and Application Client Container Application clients and applets are client components like GUI programs or GUI components of java programs. The application client will be executed on the desktop, while the applet will be executed in a web browser. If the browser includes java applets, he acts as an applet container and communicates via http. An applet container deals with the execution of applets and he consists of a web browser and a java plugin. The application client container is written in java code and can offer a more specific user interface. He communicates via http with the web container or via RMI/IIOP 4 with the EJB container.[15] Figure 4: J2EE Containers[5] Web Components and Web Container Web components normally form user interfaces for web-based applications. J2EE specifies Servlets and Java Server Pages (JSP) as web components. Servlets are programs that receive requests, generate dynamic responses and send them back via HTML or XML. They enlarge the functionality of a web server and can use the services of an EJB container. 4 RMI-IIOP: Java Remote Method Invocation over the Internet Inter-ORB-Protocol is a mechanism of J2EE, which is responsible for network activity. RMI-IIOP is compatible to CORBA and uses both RMI-API and its own API.

6 6 Manuel Berger, Nina Forst, Martin Reingruber Java Server Pages is a technology that allows the deployment of dynamic content for web clients, that means an html page generated with JSP can be read with html on any device or platform. JSP contain java code which is ingrained in html or XML and describes dynamic content. The JSP engine interprets a JSP page and creates a Servlet, which will be executed. The assignment of JSPs and Servlets is the processing of http requests. Since these requests are normally triggered by a user, they dispose of presentation logic, as shown in Figure 3.The Web Container runs on a J2EE Server and it is responsible for the execution of JSPs and Servlets.[4], [15] Enterprise Java Beans and EJB Container The EJB container represents the heart of the J2EE architecture and he is responsible for the execution of EJBs at J2EE application. EJBs and their container also run on a J2EE Server. Business components are represented by Enterprise JavaBeans (EJB) components, which support a standardized, server sided component model. EJB consitute a technology for the development and deployment of business logic components that are reverted by clients. EJBs present the components, that are responsible for a stateful, remote and secure business logic layer. There are three different types of EJBs: Session Beans, Entity Beans and Message-driven Beans.[4], [15], [11] Session Beans Thanks to Session Beans the business logic will be executed on the server and they are suitable, because a new bean will be construed for every client. Session Beans cover client specific information and they are not persistent, this means if the communication between server and client is finished, the instance of the container will be destroyed. If there is a server crash, information will be lost. For instance an EJB could exist within a Web Server, which sends html sites to a browser, thereby the bean protocols the path of the user through the sites. After a certain duration or if the user leaves the site, the Session Bean will be destroyed. But the Session Bean is able to save data to a data base. There are also Stateless Session Beans, which are less in common. Stateless Session Beans can receive a request and send back the response, but cannot remember the status of a previous request. They do not cover client specific information, could even be associated with more clients and are anonymous.[4], [15] Entity Beans Entity Beans are suited for the handling of permanent data of applications, because they are persistent. This Bean does not create its own instance for every client; it has one instance for all clients together. They represent data in RDBMS, that means it involve persistence and survive after server crashes. Entity Beans are used within transactions and every EJB has its own unique identity in a container. Relating to Entity Beans this identity is persistent and can be compared to primary keys of RDBMS.[4], [15]

7 The Web Service Framework: J2EE 7 There are bean-managed EJB, which concede the persistence to the component developer. He is responsible for the connection of a database and management of saving the data. On the other side with container-managed EJB the developer only has to define which data to save and the container takes care of the rest. Message-driven Beans Message-driven Beans allow the processing of asynchronous messages. The main difference to entity and session beans is that clients do not access to message-driven beans via direct interfaces, they access via messages that can be handled by the beans. This enables clients to leave messages in queues and proceed without waiting for a response. The EJB server executes all queuing requests and responses via JMS to the client as soon as the job is finished. [15] Message-driven Beans are associated with one specific client and they can access data. They are not persistent, stateless and support transactions. If there is a server or container crash, the container has to create a new Message-driven Bean and continue its assignments. The Web Services Stack Framework The process of developing software has changed numerously over the past years. A research-group from the University of Durham, Keele University, believes that in the future there will be a separation of ownership and usage. This means, that one software service consists of several other services provided by different organizations. It can be assembled to meet special requirements and the configuration happens at the time of delivery. There will not be existing problems like restrictions in its usage or lacking development. A change in the business context will affect the behaviour of a set of services, but that shall be handled without user interaction. To offer such services it is essential to know the capabilities of the services for one specific problem. The benefit for provider within this new service model is that there will be a dynamic creation and development of new services that make use of existing ones. The Pennine Group added an additional layer in their service model as shown in Figure 5 - the so called Service Technology Layer presents the accumulation of small services to a bigger one (as described above). [27] Figure 5: Service Technology Layer

8 8 Manuel Berger, Nina Forst, Martin Reingruber Conceivably there has to be some standardization to make sure that these services are compatible. The current Web Service paradigm satisfies a lot of requirements, but some further development has to take place to fit into the idea of the Service Technology Layer. Therefore the research group proposes a stack framework (Figure 10) that shows the existing standards in the context of this new framework. Because of different standardization organizations and firms there are different standards describing the same context. For this reason the Stack Framework consists of layers, where these standards are positioned and where the standards according to their usage in the concerning layer can be looked up. Each layer uses the services of the level below it. [27] The network layer is very important and consists of the underlying internet protocols like http. XML-based messaging means that XML is used to communicate documents and procedure calls using p.ex. SOAP uses the underlying network layer. The Service Description offers information about the functionality, the interface and the implementation of Web Services. Non-functional description adds further information which is not necessary for the technical implementation (e.g. costs, legal factors, geographical location ) but can be very important for other decisions. The Conversation layer defines the correct sequence of message-exchange of Web services. If methods of more than one Web service are used, the Choreography layer will coordinate the invocation of the different methods. The transaction layer controls all steps and reports either a successfully transaction or failure, which will result in a roll back. To build a Web service consisting of other Web services, it is advisable to use some of the standards mentioned in the Business Process/Workflow layer. The contract layer is necessary to automate electronic business. It includes constraints and information about terms, conditions and negotiable parameters. The Discovery layer supports the publication of details of the Web services, so they can be found easily. [27] Technologies and Standards for Web Services in J2EE The building of Web Services had a great influence concerning the development of J2EE 1.4. The Java Community does not aim to make its own standards but provides APIs that support most industrial standards defined by Organizations like OASIS, W3C [22] The list below shows a summary of standards that can be used together with a Web Service that is developed in J2EE. Below the figure there are explanations of the most important APIs. As the APIs appear several times, we explain their functionality and history of origin in the end of this chapter. The development of Java APIs is assisted by the Java Community Process. There are so called Java Specification Requests, where proposed and final descriptions of the Java platform can be found. It is a long way from an idea to an approved API, which can be seen in the different drafts and the progress of the specifications. The final release that is approved by most of the members of this Java Community Process will be published by Sun Microsystems as a standard of the concerning platform. [28] The following figure shows how the Web-Service APIs work together.

9 The Web Service Framework: J2EE 9 Figure 6: Web Service API connections[29] JAVA APIs for Web-Services Java API for XML Registries (JAXR) Web Services need access to a XML-registry like UDDI, ebxml-registry or another industry standard that is specified by accepted organizations (e.g. ebxml.org, OA- SIS, W3C ). A registry allows organizations to publish, discover and utilize Web Services but these registries are very different, so developers must know details about each of them. Therefore JAXR provide access to different kinds of XML-registries so the developer does not need special information about each registry and clients will be portable across different registries. The JAXR information model is based on the ebxml-registry and has some extensions to meet the requirements of UDDI. This is due to the more generic and extensible structure of ebxml-registry than that of UDDI. ebxml provides more information and is designed for a successful collaboration of businesses. The ebxml-registry contains the Collaboration-Protocol Profile (CPP) which gives information about the provider of the Web service and the way he communicates with others [26]. The Collaboration-Protocol Agreement (CPA) is also stored in the registry. This is an agreement between two parties in collaboration and describes the valid, enforceable interaction. Figure 7 shows the employment of JAXR, which provides the abstraction through the JAXR-provider. The Client uses the JAXR API to access the registry via the JAXR-provider.

10 10 Manuel Berger, Nina Forst, Martin Reingruber Figure 7: JAXR Overview The final release of the JSR#93, which defines JAXR, dates the 11 June 2002 and has been accompanied by well-known experts under the specification lead of Farrukh Najmi from Sun Microsystems, Inc. Advantages of JAXR are rich metadata capabilities for classification and association as well as rich query capabilities. JAXR, which mainly compounds of the packages javax.xml.registry.infomodel and javax.xml.registry, works together with other Java APIs that are designed for Web Service development. [24] Java Architecture for XML Binding (JAXB) Java and XML work close together and there are different possibilities to access a XML Document from java applications. One way to do this is through parsers that are based on the Simple API for XML (SAX) or the Document Object Model (DOM). A parser scans the XML-Document and returns the information about the xml-events to the java application either in a sequence (SAX) or as a tree of objects (DOM). The advantage of JAXB, that offers the same functionality is, that the developer does not need any knowledge about XML or XML processing. [18] Therefore a parser is not necessary. JAXB, which comprises three packages viz javax.xml.bind, javax.xml.bind.util, javax.xml.bind.helper, works the way shown in Figure 8. [1] Figure 8: JAXB Overview[30]

11 The Web Service Framework: J2EE 11 After binding the schema, which is required and must be conform to the W3C specification, the binding compiler generates a set of interfaces and classes that response to the schema. The unmarshalling process creates a tree of content objects, which are instances of the mentioned classes that can be used immediately in the application. This is the way a XML-Document can be used in Java applications. The other way round is the building of XML-Documents what is easier with JAXB than with DOM. The first step - binding the schema - is the same process one performs when a document is unmarshalled. Using the schema the structure of the XML-Document will be created before the application provides the data that is filled in. The result is a XML- Document that has been created by the Java application. Summarizing, the main advantages of JAXB is that it simplifies the access to an XML-Document from a Java application. It uses memory efficiently, it is very flexible concerning sources, SAX & DOM events, etc., and its binding behaviour can be customized in many different ways. Also the fact that knowledge about XML is hardly needed is a great advantage for developers. [21] JAX-RPC JAX-RPC stands for Java API for XML-based RPC and is one of the most important API for developing Web-Services. Thanks to this API it is possible to create Web- Services that use remote procedure calls (RPC) and XML. The RPC-mechanism is used when clients want to execute procedures on other systems. The most important thing of JAX-RPC is the interoperability across clients and servers. If a client is written in a language other than the Java programming language JAX-RPC makes it possible to access a Web-Service developed and deployed on the Java platform. On the other hand a client which is written in the Java programming language can communicate with a Web-Service that was developed and deployed using some other platform. The reason why this interoperability is possible is the support for SOAP and WSDL. SOAP messages are very complex, but JAX-RPC hides this complexity from the application developer. The developer only specifies the remote procedures by defining methods in an interface. He also codes one or more classes that implement those methods. The client programs are also easy to code. It represents an alleviation of JAX-RPC that the developer does not generate or parse the SOAP messages, because this function assumes the JAX-RPC runtime system. It converts the API calls and responses to and from SOAP messages. These calls and responses are transmitted as SOAP messages (XML files) over HTTP.[22]

12 12 Manuel Berger, Nina Forst, Martin Reingruber Figure 9: JAX-RPC Overview[31] RPC Call on the client: 1. A client application makes an RPC call on a local object called a stub. 2. The stub converts the RPC call to JAX-RPC runtime system requests. 3. The JAX-RPC runtime system maps the requests to a SOAP message and transmits it as part of an HTTP request. RPC response on the client: 10. The JAX-RPC runtime system extracts the SOAP message and maps it to a response on the stub. 11. The stub returns the response to the client application. 12. The client application gets (and processes) the response. RPC Call on the the server: 4. The JAX-RPC runtime system extracts the SOAP message from the HTTP request, and maps it to a method call on a local object called a tie. 5. The tie invokes the method call on the Web service. 6. The Web service processes the request. RPC response on the server: 7. The Web service returns the response. 8. The tie converts the response to JAX- RPC runtime system requests. 9. The JAX-RPC runtime system maps the response to a SOAP message and transmits it as part of an HTTP request. The Use of JAX-RPC First of all it is important to search for Web-Services. JAXR offers an easy way to search for Web-Services, which generally register themselves with a business registry and store documents, including their WSDL descriptions in its repository. After the search of a business registry there are several WSDL documents, one for each of the Web-Service that was searched. These WSDL documents can be used to look up what the services offer and how to contact them.

13 The Web Service Framework: J2EE 13 There is also other important use of the WSDL documents, the use as a basis for creating stubs. Stubs are the low-level classes which are needed by a client to communicate with a remote service. To generate stubs there is a tool in JAX-RPC called wscompile which uses a WSDL document to create a stub. On the other side JAX- RPC has another tool, called wsdeploy, which generates ties. Ties are the low-level classes that the server needs to communicate with a remote client. The JAX-RPC runtime system uses this stubs and ties behind the scenes. First of all the runtime system converts the client s remote method call into a SOAP message and sends it to the service as an HTTP request. On the server side, the JAX-RPC runtime system receives the request, translates the SOAP message into a method call, and invokes it. Before the runtime system return the result to the client the Web-Service must have processed the request. The following figure illustrates what happens when a JAX- RPC client invokes a remote method through a stub. [23] Because of its easy use, JAX-RPC is the main Web services API for both client and server applications. SAAJ SAAJ stands for SOAP with Attachments API for Java and is a lower-level alternative for SOAP messaging. This API is used for the SOAP messaging that goes behind the scenes in JAX-RPC and JAXR. A developer can also use this API when he wants to write SOAP messages directly rather than using JAX-RPC. A SAAJ client sends a point-to-point message directly to a Web-Service that is implemented for requestresponse messaging, so SAAJ is a standalone client. These request-response messages are synchronous, that means that a request is sent and its response is received in the same operation. [22] JAXP The Java API for XML Processing is used to process XML data very easily. JAXP supports the parser standards SAX (Simple API for XML Parsing) and DOM (Document Object Model). So the developer can choose if he wants to parse the data as a stream of events or to build a tree-structured representation of it. In the latest version of JAXP the API also supports the XSLT standard (XML Stylesheet Language Transformations). XSLT gives the developer the control over the presentation of the data and makes it possible to convert the data to other XML documents or to other formats, such as HTML. The Java API for XML Processing also provides namespace support. An important thing of JAXP is the pluggability layer, which allows using any XML compliant parser from within the application. The plug ability layer makes it possible to plug in an implementation of the SAX or DOM APIs and it also allows plugging in an XSL processor. [22]

14 14 Manuel Berger, Nina Forst, Martin Reingruber JAXM JAXM is the Java API for XML-based messaging. XML-based messaging means, that a client sends a XML document to a server for processing. The focus of JAXM is on B2B (business-to-business) messaging (e.g. purchase orders). By contrast to JAX- RPC, where a client calls a specific method on the server, a messaging client does not call a specific method. So it is not necessary that a client knows what program process the request on the server side. JAXM supports SOAP, which means that documents and responses are SOAP messages, but it also supports the ebxml Message Service Specification. As JAX-RPC, the Java API for XML-based messaging hides the complexity of SOAP. The developer does not need to code a SOAP request, he just codes the request in the Java programming language and JAXM converts the request to a SOAP message and then transports it to the server. On the other side the server converts the SOAP message and then processes it and transports it back to the client. [23] As the J2EE version 1.4 is specially designed to support the Development of Web Service, you will find the supported standards on the following pages: Supported Web-Services Standards in J2EE Network WSDL-based: HTTP will be realized through JAX-RPC Semantic-based: HTTP will be realized through JAX-RPC ebxml-based: : HTTP will be realized through JAX-RPC XML-based messaging WSDL-based: SOAP will be realized through JAX-RPC, JAXM and SAAJ Semantic-based: SOAP will be realized through JAX-RPC, JAXM and SAAJ ebxml-based: SOAP will be realized through JAX-RPC, JAXM and SAAJ. ebxml messaging will be realised through JAXM

15 The Web Service Framework: J2EE 15 Service description WSDL-based: WSDL will be realized through JAX-RPC. Semantic-based: WSDL will be realized through JAX-RPC. For DAML-S service grounding and RDF there is no support in J2EE. The standards are explained in the glossary. ebxml-based: ebxml will be realized through JAXR Nonfunctional description WSDL-based: in J2EE there is no support for WSEL, WSCI. The standards are explained in the glossary. Semantic-based: in J2EE there is no support for DAML-S service profile, DAML-S service grounding. The standards are explained in the glossary. ebxml-based: ebxml will be realized through JAXR. Conversations WSDL-based: in J2EE there is no support for CS-WS, WSCL and WSCI. The standards are explained in the glossary. Semantic-based: in J2EE there is no support for DAML-S service profile and DAML-S service model. The standards are explained in the glossary. ebxml-based: in J2EE there is no support for ebxml BPSS. The standard is explained in the glossary.

16 16 Manuel Berger, Nina Forst, Martin Reingruber Choreography WSDL-based: in J2EE there is no support for WS-Coordination and WSCI. The standards are explained in the glossary. Semantic-based: in J2EE there is no support for DAML-S service model. The standard is explained in the glossary. ebxml-based: in J2EE there is no support ebxml BPSS. The standard is explained in the glossary Transactions WSDL-based: in J2EE there is no support for WS-Transaction and BTP. The standards are explained in the glossary. Semantic-based: none ebxml-based: in J2EE there is no support for BTP. The standard is explained in the glossary Business process/workflow WSDL-based: in J2EE there is no support for BPEL4WS and BPML. The standards are explained in the glossary. Semantic-based: in J2EE there is no support for DAML-S service model. The standard is explained in the glossary. ebxml-based: in J2EE there is no support for BPML. The standard is explained in the glossary.

17 The Web Service Framework: J2EE 17 Contracts WSDL-based: none Semantic-based: none ebxml-based: ebxml CPA will be realized through JAXR Discovery WSDL-based: UDDI will be realized through JAXR. Semantic-based: UDDI and ebxml registries will be realized through JAXR. ebxml-based: ebxml registries will be realized through JAXR Appliance of the Web Services Stack Framework in J2EE The Web-Services Stack Framework showed the different standards of Web- Services, but in J2EE there is only support for some of these standards. Now we want to demonstrate which of these standards are supported in J2EE. The following figures show this comparison. The last graphic demonstrates that a developer only needs some APIs to develop a Web-Service with J2EE. These APIs offer the functionality that is necessary for a Web Service and alleviate the work for the developers. The specifications of these Web Services APIs are mentioned above.

18 18 Manuel Berger, Nina Forst, Martin Reingruber Figure 10: Web-Services Stack Framework Figure 11: J2EE Framework At this time in J2EE there is no support for the business process standards, J2EE only provides APIs to implement Web Services. But business integration is getting more and more important, so Sun and other members of the Java technology community started to develop a next-generation Java standards - based on Web-Services technology called JBI (Java Business Integration). JBI will be defined in JSR no In April 2003 there was the proposal to develop the initial core specification for JBI. Afterwards a JCP Expert Group has been formed, which works on JBI. The JBI functionality will complement J2EE and Web Services capabilities, provided by the Web- Services APIs. So called SPIs (system programming interfaces) are used by the Java Business Integration JSR to extend J2EE. These SPIs are used for enabling the creation of a Java business integration environment for specifications such as WSCI, BPEL4WS and the W3C Choreography Working Group.[25]

19 The Web Service Framework: J2EE 19 The Java Web Services Developer Pack To keep the development of Web Services simple Sun Microsystems, Inc. offers a product called Java Web Services Developer Pack in the current version 1.2. It is a toolkit for developing, building, testing and deploying Web Services. This toolkit contains Java technologies that support all important industrial standards and also the Web Services Interoperability Basic Profile (it includes 4 specifications that are XML Schema 1.0, SOAP 1.1, WSDL 1.1, UDDI 2.0). This Profile is provided by the Web Services Interoperability Organization who promotes interoperability among Web Services implementations based upon specifications accepted by the industry. These recommendations that are used to develop Web Services make sure that different implementations work together regardless of the underlying platform, programming language or application. Promoting consistent and reliable interoperability among Web services will increase the growth and acceptance of them. [20] The Web Services Interoperability Organization does not only provide a Basic Profile, it also has some tools for checking the satus of interoperation of the tested Web Service. The Web Services Interoperability Basic Profile comes along with a Supply-chainmanagement-sample. The Java technologies in the Web Services Developer Pack are JAXR, JAX-RPC, SAAJ, JAXB, and JAXP. These contents have been described earlier in this paper. Furthermore there are Java Servlets, Java ServerPages, JavaServer Pages Standard Tag Library (JSTL), JavaServer Face (JSF), which are common server sided appliances. There is also an example concerning the Universal Business language of the OASIS-group that shows how to process a UBL-process using JAXB. Further there are also some useful tools in the Web Services Developer Pack to keep programming and testing as efficient as possible. [19] Summary As we have shown in this paper the development of Web Services is a very complex theme because there are a lot of different standards which are rapidly changing. Nobody will ever know the mightiness of one standard or specification, because the speed of development concerning this topic is enormous, what brings us a lot of new standards in short term. Our goal is to make a framework which shows the supported standards of J2EE and helps to build a Web Service with J2EE. It was also our aim to give a general idea of these standards and their field of application. Thanks to this paper the recipient should get an overview of the architecture of a Web Service in J2EE and an appliance for the developing of them.

20 20 Manuel Berger, Nina Forst, Martin Reingruber Glossary BPML (Business Process Modeling Language) According to Business Process Management Initiative (BPMI) an ebusiness Process between two trading partner consists of three interfaces: one official interface and two private interfaces one interface for each participant. The official interface must be equal for each partner and is described by standards like ebxml The specific private interface on the other hand is described by BPML, therefore BPML defines a XML scheme. The XML scheme is used to describe the process, messages and operations.[40], [44] BPEL4WS (Business Process Execution Language for Web Services) The Business Process Execution Language for Web Services exists thanks to the cooperation of Microsoft, IBM and BEA. The specifications for XLANG and WSFL formed the basis for BPEL4WS. It is a XML-based language, which defines the interaction of business processes within and between trading partners. That way, complex business processes can be described, which could be spread across several trading partners. These business processes can use Web Services, which are provided by other companies. Moreover BPEL4WS supports the communication of business processes within and between trading partners, which are based on different technologies. Thereby companies can execute the same business processes in systems of other providers and ease the exchange of information within and between trading partners. [44] BPSS (Business Process Specification Schema) The Business Process Specification Schema is based on prior UN/CEFACT work and supports the specification of business transactions and the choreography of business collaborations. It is an alternative to ebxml and can describe the internal details of workflows and long-running transactions.[27] Disadvantage: The BPSS can only be used by a maximum of 2 parties BTP (Business Transaction Protocol) The Business Transaction Protocol was developed under the supervision of OASIS by several companies (BEA technologies, Sun ) to manage complex B2B transactions over the internet. It is XML-based and coordinates the participating services. [44]

21 The Web Service Framework: J2EE 21 CS-WS (Conversation Support) Conversation Support for Web Services is a set of specifications that proposes and implement a conversational model of component integrating using Web Services. In the conversational model, the interoperability technology consists of two distinct parts: messaging and conversation support. Messaging is the plumbing needed to send and receive electronic communications with others. Conversation support governs the formatting of messages that are to be sent, the parsing of messages that have been received, and the sequencing constraints on the exchange of multiple, correlated messages. [39], [44] DAML-S Service Model (note: latest version is OWL-S 1.0[37]) The Service Model of DAML-S (DARPA Agent Markup Language for Services) describes how a Service does work and what happen when a service is carried out. When an agent is seeking for a service he can go here to take a deeper look into it. In addition of composed services the Service Model gives us detailed information in at least four different ways:fehler! Verweisquelle konnte nicht gefunden werden. - in-depth analysis of what is needed to meet with other services - composition of service descriptions from multiple services - service enactment: coordinate the different services - monitoring the service DAML-S Service Profile (note: latest version is OWL-S 1.0[37]) The Service Profile of DAML-S (DARPA Agent Markup Language for Services) was developed by DARPA (Defense Advanced Research Projects Agency a section of the Department of Defence of United States) is part of the ontology-based language of DAML-S. It shows us what the service requires of the user (agent) and what it provides for it. It has 3 types of information:[38] - Service Description: This description is human readable and gives us a text summary of the Service. - Functionality Description: It tells us what is needed for a successful result. - Functional Attributes: It gives us the information about: geographic scope, service type, quality guarantees DAML-S Service Grounding (note: latest version is OWL-S 1.0[37]) The Service Grounding of DAML-S gives us the information how a service can be accessed by agents or other services. The main information is:[38] - communications protocol - port numbers

22 22 Manuel Berger, Nina Forst, Martin Reingruber - marshalling/serialization techniques ebxml (Electronic Business for Extensible Markup Language) ebxml is a top-down effort to standardize the B2B-integration environment. [36] It is an open interoperable framework of standards which is developed by OASIS due to the growing demand for standardizes B2B integration. ebxml is easier and cheaper to implement than EDI (Electronic Data Interchange) and its propagation is very high in the business world. ebxml CPA (ebxml Collaboration Protocol Agreement) The ebxml CPA is the technical agreement, created automatically or manual, of two business partners how to exchange data based on the ebxml CPP. The defined properties are, for example, contract s duration and transactions agreed security features.[27] By supervising the transactions between services, the processes can be terminated when the CPA is violated. ebxmlcpp (ebxml Collaboration Protocol Profile) The ebxml Collaboration Protocol Profile is a XML document to identify a company. It describes which company supports which business process, message format, communication interface so it contains information about systems of trading partners. Thanks to this information companies can find trading partners with a proper CPP to reach further agreements in order to perform electronic business transactions. [42], [43], [44] ebxml Messaging The ebxml Messaging is the solution of ebxml for XML-based messaging. An ebxml-message is a MIME/Multipart Message; it is build on SOAP by using its header specification extensibility to include authentication and contextual information.[27], [44] ebxmlregistries The ebxml Registry represent a central registration to save all ebxml documents of the companies, so it provides information like business processes documents about potential trading partners in form of a cpp. [42], [43], [44]

23 The Web Service Framework: J2EE 23 Network protocols (http, ftp, smtp) The Hypertext Protocol (http) manages the transfer of websites between servers and clients. For every transmission starts a separate connection. The browser initiates a request and waits for the response of the Web server. The connection will be closed if the all the data (i.e. the requisited site) is transferred. The File Transfer Protocol (ftp) represents a client/server based protocoll for the transfer of files. Data can be uploaded from a client to a server and it can also be downloaded from a server to a client thanks to ftp. The Simple Mail Transfer Protocol (SMTP) is responsible for the transfer of s between servers on the internet. A message consists of data and a header, which contains important information for transfer, like addressee and sender. The data contains normally ASCII-Text and represents the actual message. RDF (Resource Description Framework) RDF is a general framework developed by the W3C (World Wide Web Consortium). It defines concept for meta-data, which is based on the XML-Syntax. The substantial utilisation of RDF is to edit the meta data (like author, language, topic ) of the header of XML-documents systematically i.e. to provide better search engines. With the help of XML-namespaces in this context RDF-schemes, it is possible to describe one resource by different perspectives. These descriptions can be saved as unique record, which is suitable for the automatically processing. [44] SOAP (former: Simple Object Access Protocol) SOAP is a protocol for sending XML-based procedure calls between service provider and service requestor. The SOAP-protocol uses the port 80 (HTTP) to go conform with installed firewalls. It is independent to used platforms and used programming languages. Every SOAP message contains the same elements like envelope header and body.[40], [44] UDDI (Universal Description, Discovery, and Integration) Without a service that publishes and searches for Web Services, the dynamic integration of Web Services in other applications is only possible with human intervention. UDDI provides such a central registry, whose specification describes the structure, data structure and the interfaces of a global Web Services registry. UDDI data contains lists of business services, contact information and how services can be accessed via protocols.[40], [44]

24 24 Manuel Berger, Nina Forst, Martin Reingruber WSCI (Web Service Choreography Interface) The Web Service Choreography Interface (WSCI) is an XML-based interface description language that describes the flow of messages exchanged by a Web Service participating in choreographed interactions with other services. [35] It is based on WSDL and has the following key elements: - Message Choreography: It regulates the order of the transmitted messages and defines the start and the end point of messages. - Transaction boundaries and compensation: The interface describes which operations are performed in a transactional way and offer this to other participants. - Exception handling: It describes how to handle with exceptions when appearing. - Thread management: The interface describes how to manage multiple communications with the same partner or others. - Properties and selectors: This parameters influence the observable behavior of the Web Service. - Connectors: The WSCI interface describes the linkage of the different Web Services. It distinguishes between operations which produce or consume. - Operational context: It is the description of the different behaves of the web service to different message exchanges. - Dynamic participation: The target service can be dynamically selected. WSCL (Web Service Conversation Language) The Web Service Conversation Language was developed by Hewlett-Packard and is used in conjunction with other web service description languages like WSDL. It is XML-based and is used to model interfaces for services for defining the used XMLdocuments and its sequence of data exchange. The maximum of involved services is two and therefore it is not possible to use the Web Service Conversation Language for more than that. WSDL (Web Service Description Language) The Web Service Description Language is an xml-based language to describe and define Services as collections of network endpoints. The abstract definition of endpoints (ports) is separated from the concrete one, this makes it reusable. A WSDLdocument has 6 main elements:[34]

25 The Web Service Framework: J2EE 25 - types: Types provide data type definitions to describe the exchanging messages. Simple data types are provided by XML-schema. - message: A message contains information and data to be sent between client and service. - porttype: Describes the operations between input and output-message. - binding: It defines for every particular porttype the format and used protocol. - port: It defines a concrete endpoint with a single address. - service: A service groups a set of related ports together. Disadvantage: WSDL cannot handle with more than one Web Service (no Choreography) and has no security issue. WSEL (Web Service Endpoint Language) The Web Service Endpoint Language was developed by IBM and describes endpoint properties of Web Services. It is used within IBM s WSFL (Web Service Flow Language)[33]. Properties are non-functional and negotiable elements of Web Service like:[32] - QOS characteristics - Sequencing of operations (open, read/write, close ) - Cost characteristics - Security characteristics WS-Coordination WS-Coordination and WS-Transaction complete BPEL4WS: These two standards help companies to coordinate and integrate different Web Services and business processes across several environments. WS-Coordination helps developers to manage transactions, which are involved with a business process. Business processes can use several Web Services, but every service has to coordinate its activities with the activities of the other services. This requires a specified process to get a consistent total result. WS-Coordination is responsible for the general conditions, that the process succeed. [44]

26 26 Manuel Berger, Nina Forst, Martin Reingruber WS-Transaction Thanks to WS-Transaction companies can monitor the success or failure of every single activity within a business process environment, which is spread over several trading partners. The business process can also react on errors, which occur at run time. The corporate usage of WS-Transaction and WS-Coordination guarantees that all tasks either succeed or fail hereby it is independent if they use different platforms or if they are spread over several trading partners. As Web Services can offer services that take days or weeks, there is a need for transaction surveillance in the loosely coupled environment of the web. [44] References [1] Stal, M.: Web Services: Beyond Component-Based Computing. In: Communications of the ACM [2] Kuschke, M., Wölfel, L.: Web Services kompakt. Spektrum Akademischer Verlag, 2002 [3] Boles D., Schmees M.: Kostenpflichtige Web-Services. In: Wirtschaftsinformatik 2003 Band I [4] Haberer, P.: Enterprise Java Beans. Visited [5] java.sun.com [6] Bücker K.: Datenbankenanbindung und Middleware für Java Applikationen. Visited [7] Berger R., Pirklbauer M., Wollendorfer M.: _Servlets, JSP, Java Beans and EJB s [8] Sun Microsystems, Inc: Designing Web Services. Visited [9] Husemann, M.: Java 2, Enterprise Edition Einführung und Überblick. Visited [10] Visisted [11] [12] Sun Microsystems, Inc: The J2EE 1.3. Tutorial fcs/doc/overview2.html. [13] Sun Microsystems, Inc: The J2EE 1.4. Tutorial [14] Johnson, M.: A walking tour of J2EE. Visited [15] Renz, B.: Softwarearchitektur und Anwendungsentwicklung. Vorlesungsskript [16] Singh I., Stearns B., Johnson M.: Designing Enterprise Applications. Addison-Wesley [17] Sun Microsystems, Inc: Java Architecture for XML Binding Visited [18] W3C - World Wide Web Consortium: XML Technical Documents Visited