If I want to create application based on webservices that OSB would serve - what should be it's architecture?
ie. if I use Oracle SOA Suite, I create WebServices that will do my bussiness (talk to DB etc.), put them on OSB (Oracle Service BUS). If I'd want to create app (webapp) that will utilize those services, how shoud I create project?
Would it be war with gui and its logic, separate jar for EJB?
Thanks
If I understand the question, you're looking for how to structure a web application that calls OSB web services. This is no different than a web application calling any other web service.
You shouldn't need EJBs for that, rather you can invoke the web services directly from java via JAX-WS or another mechanism.
For guidelines on structuring an application .ear, see
http://java.sun.com/blueprints/code/projectconventions.html
or your application server's documentation.
Related
Bit confused with Spring framework and what capabilities application server provides.
I was reading this answer on same site
There he says,
Additionally App Server have components and features to support
Application level services such as Connection Pooling, Object Pooling,
Transaction Support, Messaging services etc.
That means we can optionally use apis of application server to manage transaction in our web application (inject web application :()and I think spring also provides transaction apis. So whats the difference?
Please, help me to make it clear. Thanks you.
When you use app server resources (transactions, connection pools etc.) directly in your application code, you can only run it when it is deployed on an application server or even worse only on that syme type of application server.
Spring allows you to use those resources and configure your application for different environments. The application can be run on any application server or on a simple Tomcat, or on different servers in the cloud.
Spring also allows you to run your code in tests (unit tests) without the need to start up an application server. This is absolutely needed to write automated tests.
Everything that can be done with an application server, can be done with spring as well.
There is a whole world of spring libraries and framework that provide features that are not available directly on application servers.
I can really recomand to give spring a try.....
I have started to write two web application projects
RESFful API for mobile clients using Spring REST API
GWT WebApp Server for web clients using Servlets
My problem is that both web applications are using the same database and that I think that instead of having two web applications I actually should have started this project using just one web application that handles the requests for web and mobile clients.
The problem I got now is that I don't have any idea how I could "merge" those two guys and whether I should stick to Spring REST API or if I should use RestyGWT.
GWT Server-Project using Servlets
RESTful Server using Spring
All projects (in the middle of a major refactoring mission)
Is there a way that would allow me to launch the web application as a whole and have access to the REST API from my mobile clients and to the Servlets from my web clients?
It depends on your business logic implementation. If you have it in a separate module/package, then it should be easy to merge your two applications.
You will have to rework the mappings in web.xml and how you pass the input/output data to the business logic methods from both the REST implementation and your servlet code.
Personally I will recommend a single approach such as only going with the REST based approach that you already have and migrate your servlet functionality to it.
I've developed a spring integration component that is to sit on a server and process messages coming in over an inbound RMI channel do some processing/filtering and then send out some messages over a different RMI channel.
Currently, for testing, I've been running it using a Main class that just loads the context, which sets up the inbound RMI gateway and it's working fine. But I don't think that this is appropriate for a production environment.
What is the best way to deploy this type of project to a server?
If I were working in a .Net I'd be deploying this type of application as a windows service, is that what I should be doing here?
The application that is sending me data is hosted in Tomcat, would it be a good idea to also run this application within the same Tomcat container (Current requirements are for both components to be on the same machine this may change)? And if so how?
I'm currently looking into Spring Boot, am I on the right path?
I think the best would be Spring Boot, as it's made to easily allow running different types of applications. Also, you don't need Tomcat if you can run the same component with a simple Main and not using UI. Spring Boot, also, has a sample using Spring Integration here, so you should be up and running in no time.
So we've decided to rebuild an application in our business since it's been sitting in Sharepoint for no apparent reason other than to make use of its document indexing feature.
We've decided to create our new app in ASP.NET MVC3 using C#. We're trying to decide on the overall architecture.
I was thinking something like the following:
Core - domain objects (poco's)
Data - Entity Framework (Code First) or nHibernate exposed as Repositories
Service - This layer would encapsulate any business logic and act as a facade. This could be broken down into further modules.
UI (MVC) - Controllers and Views.
This would all be tied together using a DI container such as Autofac.
We also want to be able to write unit tests so we need to be able to mock our service layer and data repositories for testing our controllers etc.
So - does the above sound like a good overall architectural pattern for a pretty standard business application?
The idea being that data, service, ui can reference Core but the UI would only really talk to the service level components and not know about the implementation details of data etc.
My next question is that at some point we're going to want to expose some functionality outside our application i.e. WCF Services/ASP.NET Web API.
What, in your view, would be the best option. Build the service layer in WCF and call this from our Controllers in MVC? If so would this be testable or would we need to write a wrapper around the web service? Could this be time consuming?
OR
Continue writing a service layer (i.e. Service1.CreateObject(object obj);) in C# classes and create a web service as a separate entity exposing just the functionality we need that calls our service layer?
Any thoughts would be really helpful as I don't know what best route would be.
Should we use a WCF service as our service layer facade in nTier application
Depends on if any other application than the MVC application is going to talk to the service.
MVC3 is the only app: You aint gonno need it
Other apps too: Sure. Do it.
What, in your view, would be the best option. Build the service layer in WCF and call this from our Controllers in MVC? If so would this be testable or would we need to write a wrapper around the web service? Could this be time consuming
Don't use the concrete service classes. Use the service interfaces. Problem solved.
My next question is that at some point we're going to want to expose some functionality outside our application i.e. WCF Services/ASP.NET Web API
I hope that you mean the same WCF service.
Continue writing a service layer (i.e. Service1.CreateObject(object obj);) in C# classes and create a web service as a separate entity exposing just the functionality we need that calls our service layer?
ehh. What kind of method is Service1.CreateObject(object obj)? That looks just wrong.
Using WCF Service is the right approach. (As you need to host this as web-api and web-api is over http).
In your mvc application you can consume the service by endpoint url.
Time factor depends on the connectivity between your servers(WebServer for MVC app and the Server to host WCFservices).ideally it should not be a bottle neck.
Still you can do unit testing of MVC code (as service layer call can be mocked.(using Moq/NMock?RhinoMock...))
im trying to understand where WSDL's fit in, in a typical web service backend application. i am coming from a Spring background and in my experience so far, in Spring, each url request gets mapped to a specific controller class via a dispate servlet running in the web container. you can specify which url matches a given controller via xml config or from annotations.
is using a WSDL the same thing as using an xml config file to map url requests to java objects?
Thanks in advance. im moving from Spring to standard j2ee/EJB3.
WSDL is just a description of Web Service interface, most Web Service systems generate those descriptions on fly like for example when you create asmx web services you can generate WSDL on fly by typing http://yourhost/yourwebcontext/yourwebservicename.asmx?wsdl and it will return you the description of that web service. Then you can use a tools that generate stub proxies for coding using those descriptions automatically, for example in Visual Studio when you add an Web Service Reference those operations are done automatically
No, WSDLs are not like a dispatch servlet.
A WSDL file is a description of a web service (SOAP, REST, etc.). A WSDL can (theoretically) be used by anyone to generate executable code which consumes the web service described by that WSDL.
From the WSDL tag info:
"WSDL" stands for "Web Services Description Language." It is an XML language used to describe a web service to code that wishes to consume it. It describes the messages sent and received, the possible faults, and the communication and security requirements.
From WSDL Essentials:
In a nutshell, WSDL represents a contract between the service requestor and the service provider, in much the same way that a Java interface represents a contract between client code and the actual Java object. The crucial difference is that WSDL is platform- and language-independent and is used primarily (although not exclusively) to describe SOAP services.
Using WSDL, a client can locate a web service and invoke any of its publicly available functions. With WSDL-aware tools, you can also automate this process, enabling applications to easily integrate new services with little or no manual code. WSDL therefore represents a cornerstone of the web service architecture, because it provides a common language for describing services and a platform for automatically integrating those services.