I am currently trying to implement a web-service assignment given by my college.
My Assignment is..,
Consider a case where we have two web Services- an airline service and
a travel agent and the travel agent is searching for an airline.
Implement this scenario using Web Services and Data base.
For that as a newbie I tried to follow the steps given in this link.
I opened the Netbeans beta 2, and exactly followed the steps as given in that link.
But while trying the steps,
Deploying and Testing the Web Service, I tried to run the CalculatorWSApplication, I noticed that javax.ejb.Stateless is undefined.
And I have three questions,
I have a basic knowledge of , JSP, HTML, WEBSERVICE. Please give me some basic idea/basic schema of the assignment such that I could proceed with the next steps and implementation.
How could I get rid-off from the missing ejb file.
Generally .java files will refer to the libraries present in jre and why in this program, CalculatorWS.java refers in this path C:\users\MuthuGanapathy\.netbeans\7.0beta2\var\cache\index\s3\java\14\gensrc\javax\
Let me try to answer your questions:
First of all: You don't really need knowledge of JSP and HTML for creating WebServices. If you are interested in additional knowledge rather have a look in subjects like SOAP, WSDL or XML (on which SOAP and WSDL files are based). You can find good informations at w3schools.
As said in your assignments requirement you'll have combine your service with a database, therefore you'll have to face the fact that WebServices aren't able to send every kind of data. For example, if you intend to use some kind of JPA you wont be able to send entities between Client and Server via WebService easily (though its possible).
For the reason of that my approach would be to send simple datatypes between client and server and, on server side, build my complex objects.
This would force me to code at least 3 classes (one for each webservice and one for communication with the database).
Airline WS:
#WebService
public class Airline {
#WebMethod
public String stuffToDo {
// do your stuff
persistOrSelect(complexObject);
return "success";
}
private boolean persistOrSelectData(Object complex) {
// Database stuff here
DBdao.doStuff(complex);
return true;
}
}
TravelAgent WS:
// same structure as shown above
DB class:
public class DBdao {
public static doStuff(Object complex) {
// get DB connection and INSERT, SELECT, UPDATE
}
}
In this scenario you didn't even have to use a class out of the javax.ejb package but I understand that this could be necessary :).
I don't really use Netbeans and therefore I can only speculate. I think that your problems 2.) and 3.) relate to each other.
The javax.* package normally is located in your JDK and should be specified in your IDE inside the server library/target runtime your using.
Do you have assigned the server library to your project?
Have you tried to point your Netbeans installation to your JDK path as shown here and here?
It could also be possible that your project do not have a reference to the Java System library.
Last but not least:
There are several ways for testing your webservice:
You use Netbeans therfore I assume that you deploy your project on an Glassfish server.
After deployment you can navigate to your project inside the admin gui and click the link pointing to view endpoints. In the next window your able to either follow a link pointing to the generated WSDL or to a tester
You can write your own client by either following the tutorial provided or, for a more general approach you can use this.
Use soapUI for testing (it's available as standalone application or as IDE plugin)
I hope this helpes, have Fun!
Related
I am building webparts and self hosted apps for sharepoint 2013, I want to consume the Query String filters that the user sets up, the process should be as simple as specified here on this microsft site.
Unfortunately I dont get the option to send values to 'my web part' but I do for other stock webparts that come with sharepoint. Which leads me to believe I need to implement IFilter or equivelent in my webpart, I have found information into IFilterConsumer interface and IFilterProvider interface on msdn which seems to be exactly what I need, however the documentation has one snag:
NOTE: This API is now obsolete.
So My question is, what is Microsofts new intended way of doing this with Sharepoint 2013.
Ultimately I need to read query variables in the HostWeb request inside my AppWeb code.
Edit: Apparently IWebPartParameters is the new interface for this.... trying to implement now.
I have also tried whats suggested here:
Passing parameters through sharepoint sitepage to web part Still not working, at the moment I have implemented IWebPartParameters, IWebPart, IWebPartRow and none of my functions that implement these interfaces are being called. I must be missing something in the manifest or features file maybe?
Thanks in advance
Crash
Ok the answer to this question is simple, firstly you can only do this in a dev environment with sharepoint installed, as you need access to the sharepoint.dll.
Then this thread answers the question http://www.manning-sandbox.com/thread.jspa?threadID=19791, with the following code solution which is here http://www.markitup.com/BookCodeSamples/TestingWebPartConnections.zip
I'm looking for a design pattern to solve an architectual issue I'm having.
I use some webservices that are kinda the same but not exactly. For each new version of the webservices there might be a few more methods available, but for the most part they are basically the same.
I want to write an abstractionlayer that works regardless of which version of the webservices I'm communicating with. Obviously if I'm using a method that only exists in the newer versions of the webservices I will get some sort of error, but that is OK. I can handle those.
The reason I want this abstraction layer is to avoid a tight coupling between my application and the version of the webservices it is communicating with.
What are my options when it comes to design patterns for my abstraction layer? I see there is one pattern called Adapter, and another one called Bridge. Will any of those do in this situation? Any help is appreciated!
Edit - for clarity here is a drawing.
Sometimes I want my application to talk to webservices version 1, and other times I want it to use webservices version 2. It depends on who is using the client application.
The client application shouldn't relly know or care which version it is talking to. The only exception is that if it uses a method that is only available in some of the versions I need to handle that gracefully (tell the user that they have installed an old version of the webservices).
That would be a factory. You could even use a builtin ChannelFactory or come up with your own. Anyway, a facttory lets you change the implementation without changing client's contract.
I will suggest to use the FACADE pattern. You may go through the following link to understand more about it.
http://javapapers.com/design-patterns/facade-design-pattern/
Facade is to provide the abstraction and a seamless layer for clients to interact. It hides all the internal complexities, as in your case client need to find the correct version of web service it can interact with. Lets assume you have different version of webservices, and input json/xml structures have changed in different versions. Facade will accept the client call, it will validate the input against different version of web services and then call the correct web service version. If you don't have facade layer then client will have to struggle to find the correct webservice version and it will have to send multiple calls before reaching the correct web service.
okay this might be a pretty lame and basic question but its stuck in my head since i never had chance to work on web-services.
We can get the same "text bases" response(xml, json etc) from our server by very basic/simple implementations (lets say servlet) then why do someone has to develop a web-service.
What is the exception thing a web-service gives over simple http response?
At a basic level, you are quite correct, from a low level point of view, it's just text (XML) on a socket.
For simple web services, a servlet is adequate (I'm writing one of these as we speak).
When talking about something like SOAP and WSS-* web services, however, there is a lot of boiler plate processing and features available from the standards that web service toolkits expose as higher level transactions.
A simple example is data marshaling. If you treat it purely as XML, then your service basically gets to process the XML by hand -- parse it, evaluate it, populate your internal models, etc.
Contrast this to something like this from Java EE:
#WebService
public Person getPerson(String personId) {
Person p;
...
return p;
}
The web service stack will convert your Person object in to a SOAP compliant XML blob. It will also produce a WSDL that you can use to create client code (on many platforms: .NET, PHP, etc.) to make the web service code.
In the end, your client and server have only a few lines of code, while the frameworks do all of the grunt work parsing, marshaling, and publishing for you.
So, the value of the WS stack is that it handles much of the bureaucracy of writing WSS compliant web services.
It's no panacea, but for many modern implementations, SOAP <-> SOAP remote processing can be a, mostly, cross platform, drag and drop affair.
It depends. If your web service needs to answer a simple yes/no question like "does this username exist?", then return yes, no, 0, 1, etc may be enough. If you have one that returns all the faculty attributes, XML or JSON may be appropriate because of the structured nature. It's a little less prone to parsing errors than trying to parse plain text.
The situation:
We have a library project that houses much of our code for the various integrations we work on. Many of the integrations consume web service apis, and my supervisor doesn't want 5 gazillion web service references added to the project.
What we generally do, then, is add a reference to a new project and copy the References.vb to the solution and just call the generated code. Not terribly convenient if changes are made to the service, but it works.
Recently, I ran into a problem where we have to use 3 web services for the same integration. 2 of these contain the same class definitions, however, they're in different namespaces because they belong to different services. This became a problem for me because one of the services searches a user based on user ID, and the other pulls back blocks of users. Both return an object, or list of, that is exactly the same semantically. And I need to process the data the same, whether it came from one service or the other.
My solution, was to strip out the duplicated classes in the service and replace them with classes inherited from common base classes. This allowed me to work with both objects as if they were the same, however, it required modifying the generated web service proxy. Therefore this change will need to be made every time I need to regenerate the proxy.
I'm curious what you all might think a better solution to this would be.
You're going to regret playing games with copying Reference.vb and editing generated files.
Switch to WCF and you'll be able to tell it you want to reuse the types, instead of having multiple types that are more or less the same.
BTW, they would be "less" the same if not all of the web references are updated at the same time after a server change.
The other option would be to build an abstraction layer over top of the web service pre-generated proxies, such that when you make to the calls to the abstraction layer you can always use the same objects, as they are squeezed into (and out of) the web service proxies in the abstraction layer. This would also allow for unit testing :)
I think you really should be looking at WCF for 3.5+, but for .NET 2.0 look at something like WSCF (Web Services Contract First), which defines the contracts in XML and generates a set of libraries reusable across services. E.g You define a MyComany.WS.Common namespace and use that namespace in multiple projects. The code generation then builds a shared library of types which get used across all the web-services. We use this extensively in our .NET 2 solutions and it's great. We had to do some additional work around the code generation to get it to fit into our build process, but once that was done we never looked back.
We're migrating to .NET 3.5 over time, so the WSCF will become obsolete
Heres the link to the thinktecture site for WSCF.
wsdl.exe using the /sharetypes switch allows the same types to be used across multiple service definitions, provided the wire signatures are not correct. I was unable to use it in my situation, though, because the various wsdl contracts were carelessly namespaced.
I have a list of webservices from a Flex project. I am trying to load the project on a new machine and it has forgotten all the web services from the list.
I copied over the original settings file to :
"myproject-web\.settings\webservices.xml"
This contains quite a lot of webservices and I don't want to have to reimport them all. This would involve deleting all the generated code and going through one by one and adding them.
The problem is that when I go to 'Data > Manage Web Services' I don't see any of these items.
So i tried the obvious :
add a new webservice
check that the webservices.xml file was modified. in fact the new service is appended to the contents of that file
close and reopen Flex Builder
the list only contains the one new service I added and not the old ones.
How can I 'trick' Flexbuilder into recognizing the other web services in the list. It must be storing a list somewhere else.
Note: This is the same question here from months ago, but no answer.
I ran into this problem too. What I had to do was copy the wsdl.xml file from the workspace's .metadata.plugins\com.adobe.flexbuilder.webservices folder from one computer to the other.
Personally this feels like the wrong place for this since the information about what web services are being used is part of the project not the workspace. If you examine the content of that file it even has your project name in it so it knows it is project specific data. Perhaps it is here because it is a limitation of eclipse, but I suspect not. Perhaps Adobe should consider modifying the eclipse plug-in to store this data somewhere in the project files.